Problem booting NanoBSD from USB flash drive

O

OlivierW

Hello,

For years, since FreeBSD 10.x, I have been booting my router with a custom built nanobsd image, from a USB Flash drive.
It has worked fine with a motherboard having an Intel Atom N270 CPU, then until now, with another motherboard having an Intel Atom N2800 CPU.

My nanobsd image is based on FreeBSD 13.2.

Now, I'd like to upgrade my router to a Topton router from Aliexpress. It has an Intel Celeron N5105 CPU. (well, the CPU of this 3 motherboards isn't relevant, it's just to show the approximate generations).

Unfortunately, this new router doesn't boot the nanobsd image: I can see it detects the flash drive in the BIOS, but it doesn't try to boot from it. It doesn't even show it in the "boot selection" popup that I get when pressing F11 during the start.

I tried different flash drives and the USB 2.0 and 3.0 ports of the router: still no luck.
I also tried others images: "debian-live-11.6.0-amd64-xfce.iso" and "pfSense-CE-memstick-2.6.0-RELEASE-amd64.img": they works fine! So the problem isn't hardware related.

I guess it's a problem with the partitions of my nanobsd image, but I'm not sure what to change and how.

My NanoBSD image (doesn't boot):
# gpart show da0 => 63 60437429 da0 MBR (29G) 63 3998673 1 freebsd [active] (1.9G) 3998736 3024 3 freebsd (1.5M) 4001760 56435732 - free - (27G)

The Debian Live image (boots OK):
# gpart show da0 => 63 60437429 da0 MBR (29G) 63 1573 - free - (787K) 1636 10074 2 efi (4.9M) 11710 60425782 - free - (29G)

The pfSense installer (boots OK):
# gpart show da0 => 1 60437491 da0 MBR (29G) 1 131072 1 efi (64M) 131073 1627984 2 freebsd [active] (795M) 1759057 131072 3 fat32 (64M) 1890129 58547363 - free - (28G)


So, it looks like the "efi" partition is missing on my nanobsd image.
I tried to add "NANO_LAYOUT=std-uefi-bios" to my config file, because I found about it in this file: https://github.com/freebsd/freebsd-src/blob/main/tools/tools/nanobsd/embedded/common#L293 but no luck: the new image has the same partition layout.

Do you think the problem comes from this missing partition?
And how can I rebuild the image to include this "efi" partition?

Thanks in advance.
 
It is possible that your new motherboard has UEFI ONLY boot enabled. In that case your assumption about the missing uefi boot loader (and associated efi partition) is right. Can you change the boot mode inside your motherboard to something like BIOS or some kind of compatibility mode?

I have no clue about nanobsd, so unfortunatly I cannot help with this.
 
Thanks steps for your suggestion!

There is a "Legacy BIOS" option and it is activated by default. I have tried to change several options in the BIOS but couldn't make it work, so I put all the options back to default.

If a Debian Live and pfSense install images are working with all the default BIOS options, I guess it would be possible to make my nanobsd works too.
 
OlivierW said:
"NANO_LAYOUT=std-uefi-bios"
Click to expand...
When you compile NanoBSD you have the regular nanobsd.sh to build your image.

But you are showing files from the /nanobsd/embedded/ directory.
This directory has special instructions found inside the README.
This is a work in progress. Generally, to build this you should
cd tools/tools/nanobsd/embedded
sudo sh ../nanobsd.sh -c foo.cfg
Click to expand...
Notice the different build directory.

Make your own amd64.cfg
Code: 
NANO_ARCH=amd64
NANO_KERNEL=GENERIC
NANO_DRIVE=da0
NANO_NAME=amd64usb

. common    # Pull in common definitions, keep last
 
Thanks Phishfry, that's right. I thought files from "embedded" where included by default. Or at least "embedded/common".

Maybe I should override the "create_diskimage" in "legacy.sh" and adapt it with what I can find in "embedded/common" ?

Do you think my problem comes from the missing "efi" partition?
 
Phishfry said:
Dont forget this in your cfg.
I made the amd64.cfg file from i386.cfg
Something I have done in the past.

Also checkout poudriere image
Click to expand...

I'll get back later: as I couldn't make it work with my current configuration, I wanted to try your "amd64.cfg" without anything else, so it's still building world since… a few hours ?

Regarding "poudriere image", the documentation says it's an alpha feature. So I may switch to it when it becomes stable, but until now I have always been happy with "nanobsd.sh".


Phishfry said:
You don't want to know what I think of topcon.
Click to expand...
I know those Topton computers are far from being the best… But right now I need a bit more power than my current Atom N2800 based router and also need AES-NI… Oh, and also I needed two of them for two locations, so I couldn't get better machines with my current budget.
 
I'm hitting the same bugs indicated in this thread: https://forums.freebsd.org/threads/...pecification-while-building-disk-image.80208/

So, thanks ulzeraj for the solutions provided!

But I'm not sure it'll work, gpart says something is corrupt:
# gpart show da0 => 3 582075 da0 GPT (29G) [CORRUPT] 3 81920 1 efi (40M) 81923 123 2 freebsd-boot (62K) 82046 65536 3 freebsd-ufs (32M) 147582 434496 4 freebsd-ufs (212M)

And dmesg says there's a problem with the GPT header when I plug the flash drive in my computer:
ugen3.3: <Kingston DataTraveler 3.0> at usbus3 umass0 on uhub8 umass0: <Kingston DataTraveler 3.0, class 0/0, rev 2.10/0.01, addr 3> on usbus3 umass0: SCSI over Bulk-Only; quirks = 0xc000 umass0:2:0: Attached to scbus2 da0 at umass-sim0 bus 0 scbus2 target 0 lun 0 da0: <Kingston DataTraveler 3.0 > Removable Direct Access SPC-4 SCSI device da0: Serial Number ************************* da0: 40.000MB/s transfers da0: 29510MB (60437492 512 byte sectors) da0: quirks=0x2<NO_6_BYTE> GEOM: da0: the secondary GPT header is not in the last LBA. GEOM: diskid/DISK-****************: the secondary GPT header is not in the last LBA. pid 41749 (bsdisks), jid 0, uid 0: exited on signal 11 (core dumped)

Well, I'll search later during the weekend how to fix that.


Edit, seems fixed with:
# gpart recover da0 da0 recovered # gpart show da0 => 3 60437485 da0 GPT (29G) 3 81920 1 efi (40M) 81923 123 2 freebsd-boot (62K) 82046 65536 3 freebsd-ufs (32M) 147582 434496 4 freebsd-ufs (212M) 582078 59855410 - free - (29G)


Edit2, this image doesn't boot any better than my nanobsd image.
 
Well, things are getting better, in my "amd64.cfg" file, I changed "NANO_LAYOUT=std-uefi-bios" to "NANO_LAYOUT=std-uefi", with the fixes in "embedded/common" found in the other thread and now my router find the USB flash drive and boots from it!

Well, at least it tries to boot it: I see FreeBSD messages on the screen but there are some errors like missing "/boot/lua/loader.lua". I'll investigate, but the file is present in the nanobsd build directory ("/usr/embedded/amd64usb/_.w/boot/lua/").

The partitions are now:
# gpart show da0 => 1 60437491 da0 MBR (29G) 1 81920 1 efi (40M) 81921 65536 2 freebsd [active] (32M) 147457 16 3 freebsd (8.0K) 147473 60290019 - free - (29G)
 
Phishfry, yes, thanks! I'm aware of this options, I am using "-b" which is the same as "-k -w". But it was the first time I was building with the "amd64.cfg", so I built everything cleanly.

I think my problem isn't specifically Lua. In fact, I have checked the others partitions and they are empty… One of the partition should have all the content of "/usr/embedded/amd64usb/_.w/".


While I haven't made progress on my goal, I have improved the code from: https://forums.freebsd.org/threads/...-while-building-disk-image.80208/#post-510312
In this thread, asteriskRoss talks about using mcopy instead of mdconfig.
So that's what I've done, replacing:
dd if=/dev/zero of=${NANO_WORLDDIR}/boot/efiboot.img bs=4k count=10240 mdconfig -a -t vnode -f ${NANO_WORLDDIR}/boot/efiboot.img newfs_msdos -F 32 -c 1 -m 0xf8 /dev/md0 mount -t msdosfs /dev/md0 /mnt mkdir -p /mnt/EFI/BOOT cp ${NANO_WORLDDIR}/boot/loader.efi /mnt/EFI/BOOT/BOOTX64.efi umount /mnt mdconfig -d -u 0

with:
newfs_msdos -C 64m -F 32 -c 1 -m 0xf8 ${NANO_WORLDDIR}/boot/efiboot.img mmd -i ${NANO_WORLDDIR}/boot/efiboot.img ::/efi ::/efi/boot mcopy -i ${NANO_WORLDDIR}/boot/efiboot.img ${NANO_WORLDDIR}/boot/loader.efi ::/efi/boot/BOOTX64.efi
(only for the "std-uefi" option)

If I "mount -t msdos /dev/da0s1 /mnt", I can find the "/efi/bootBOOTX64.efi" file.


So at this point my image is like in my previous post: the USB drive is still recognized by my router but not going forward due to "/boot/lua/loader.lua" missing (well, the whole "/" is missing… The other partition "/dev/da0s2" is completely empty.)
 
There is also an outstanding bug in the nanobsd/custom/ build
Did you find that PR and patch? Its simple and needs fixing.

I meant to nudge imp but never got to it.
 
Phishfry said:
I saw that. You got to keep plucking away at it.

You can use NANO_IMAGES= for number of root partitions. You don't have to use the normal 2 partitions.
Flip-flop they are refered to. Ping/Pong too.
Click to expand...

Yes, I saw the default NANO_IMAGES=2, but I have only one "freebsd" partition with a "decent" size: 32M. The other one is 8.0K.


My partitions are like this:
# gpart show da0 => 1 60437491 da0 MBR (29G) 1 131072 1 efi (64M) 131073 65536 2 freebsd [active] (32M) 196609 16 3 freebsd (8.0K) 196625 60240867 - free - (29G)

# ll /dev/da0* crw-r----- 1 root operator 0x1a5 29 avr. 16:50 /dev/da0 crw-r----- 1 root operator 0x1af 29 avr. 16:54 /dev/da0s1 crw-r----- 1 root operator 0x1a6 29 avr. 16:54 /dev/da0s2 crw-r----- 1 root operator 0x1a7 29 avr. 16:54 /dev/da0s3

If I "mount -t msdos /dev/da0s1 /mnt", I can find my "/efi/boot/BOOTX64.efi" file and the size is ~64M, so i'm sure it's the "efi" partition:
# df -h /mnt/ Filesystem Size Used Avail Capacity Mounted on /dev/da0s1 63M 891K 62M 1% /mnt

I guess everything else should be in "/dev/da0s2", the 32M "freebsd" partition. If I "mount /dev/da0s2 /mnt", I see it's my empty partition:
# df -h /mnt/ Filesystem Size Used Avail Capacity Mounted on /dev/da0s2 31M 16K 29M 0% /mnt

In this partition, I have just manually created "/boot/lua/" and copied "loader.lua" inside. Now the router doesn't complain about the missing "/boot/lua/loader.lua", but of course, there are all the others files which are missing.


Phishfry said:
This looks even newer:

271078 – [nanobsd] embedded/common script does not copy FAT slice recursively

bugs.freebsd.org bugs.freebsd.org
Click to expand...
Thanks! I missed this one, I'll apply this patch and will try again.
Maybe that's why my partition is always empty, instead of having all the FreeBSD files?


Phishfry said:

255639 – [nanobsd] "missing directory in specification" while building disk image

bugs.freebsd.org bugs.freebsd.org
This is the earlier one I was referring to.
Click to expand...
Yes, I saw this one, the missing "certs" files was the error which made me discover the other thread. So, yes, I have applied this patch.

Thanks for your help Phishfry, I'll report back in a few minutes regarding the new patch I have applied.
 
Phishfry said:
This looks even newer:

271078 – [nanobsd] embedded/common script does not copy FAT slice recursively

bugs.freebsd.org bugs.freebsd.org
Click to expand...
Well, in fact when I'm building the image, nanobsd.sh doesn't reach this part of the code: https://github.com/freebsd/freebsd-src/blob/main/tools/tools/nanobsd/embedded/common#L211-L220

"NANO_SLICE_FAT" is defined only for the "std-embedded" layout. And i'm using "std-uefi".
It's defined here: https://github.com/freebsd/freebsd-src/blob/main/tools/tools/nanobsd/embedded/common#L575-L576

So, unfortunately, my partition is still empty.
 
OlivierW said:
Yes, I'll try to find in the log files.
Click to expand...
You can find them under /usr/obj/
All of that is customizable via cfg file.

Note: I only use the /custom builds for embedded arm.
So I have not built on 13.x for amd64 but it should work.
I have not tried any x86 EFI builds yet. (did use poudiere image for EFI)


Got to hit the honeydew list. Good luck. Back later i hope.
 
Thanks Phishfry and good luck with your tasks!

Well, I'm lost in nanobsd's source code and files generated by it…
In "/usr/embedded/images", I have three files which are created each time I'm building an image:
Code: 
# ll -h /usr/embedded/images
total 89218
-rw-r--r--  1 root  wheel   487M 29 avr.  18:52 _.disk.image
-rw-r--r--  1 root  wheel    96M 29 avr.  18:52 _.disk.image.amd64usb
-rw-r--r--  1 root  wheel   415K 29 avr.  18:52 _.disk.image.amd64usb.xz

"_.disk.image" is the partition I am missing… But it's plain, I can't use that on my USB flash drive.
"_.disk.image.amd64usb" is the image I am "dd"ing on my USB drive: it has the partitions I have shared earlier (with the "efi" partition)
"_.disk.image.amd64usb.xz" is the same as previous file, just compressed.


In "/usr/embedded/amd64usb", I can find my 32M "_.s2" partition (but empty) and my 8K "_.s3" partition:
Code: 
# ll -h /usr/embedded/amd64usb
total 442
-rw-r--r--   1 root  wheel    69B 29 avr.  18:48 _.cust.add_etc_make_conf
-rw-r--r--   1 root  wheel   130B 29 avr.  18:48 _.cust.cust_allow_ssh_root
-rw-r--r--   1 root  wheel   192B 29 avr.  18:48 _.cust.cust_comconsole
-rw-r--r--   1 root  wheel   515B 29 avr.  18:48 _.cust.cust_install_files
-rw-r--r--   1 root  wheel   588B 29 avr.  18:48 _.cust.cust_install_machine_files
-rw-r--r--   1 root  wheel   674B 29 avr.  18:48 _.cust.fix_pkg
-rw-r--r--   1 root  wheel    99B 29 avr.  18:48 _.cust.save_build
-rw-r--r--   1 root  wheel   123B 29 avr.  18:48 _.cust.shrink_md_fbsize
-rw-r--r--   1 root  wheel   349B 29 avr.  18:48 _.cust.typical_embedded
-rw-r--r--   1 root  wheel   3,2K 29 avr.  18:52 _.di
-rw-r--r--   1 root  wheel    27B 29 avr.  18:48 _.dl
drwxr-xr-x   2 root  wheel     2B 29 avr.  18:52 _.empty/
-rw-r--r--   1 root  wheel   133K 29 avr.  18:48 _.etc
-rw-r--r--   1 root  wheel   3,6K 29 avr.  18:48 _.ik
-rw-r--r--   1 root  wheel   969K 29 avr.  18:47 _.iw
-rw-r--r--   1 root  wheel    28B 29 avr.  18:48 _.late_cust.product_custom
-rw-r--r--   1 root  wheel    37B 29 avr.  18:48 _.partitioning
-rw-r--r--   1 root  wheel    32M 29 avr.  18:52 _.s2
-rw-r--r--   1 root  wheel   8,0K 29 avr.  18:52 _.s3
drwxr-xr-x  20 root  wheel    26B 29 avr.  18:48 _.w/

And last folder "/usr/embedded/obj", with some log files and others…:
Code: 
# ll -h /usr/embedded/obj
total 6416
-rw-r--r--  1 root  wheel    11M 29 avr.  00:29 _.bk
-rw-r--r--  1 root  wheel    31M 29 avr.  00:17 _.bw
-rw-r--r--  1 root  wheel   277K 29 avr.  18:52 _.cs
-rw-r--r--  1 root  wheel   8,7K 29 avr.  18:52 _.du
-rw-r--r--  1 root  wheel   1,9K 28 avr.  22:35 _.env
-rw-r--r--  1 root  wheel   488K 29 avr.  18:48 _.metalog
-rw-r--r--  1 root  wheel   541K 29 avr.  18:48 _.metalog.pre
drwxr-xr-x  2 root  wheel     2B 29 avr.  14:37 _.mnt/
-rw-r--r--  1 root  wheel   381K 29 avr.  18:52 _.mtree
-rw-r--r--  1 root  wheel   578B 28 avr.  22:35 make.conf.build
-rw-r--r--  1 root  wheel   698B 29 avr.  18:47 make.conf.install
drwxrwxr-x  3 root  wheel     3B 28 avr.  22:35 usr/


The "_.disk.image" is created by "create_code_slice" in "legacy.sh": https://github.com/freebsd/freebsd-src/blob/main/tools/tools/nanobsd/legacy.sh#L97
And that doesn't makes sense! Because this function should be overridden by the empty one from "embedded/common": https://github.com/freebsd/freebsd-src/blob/main/tools/tools/nanobsd/embedded/common#L633-L635


Well, anyways, things should be written in the "_.s3" file.
Here's the complete "_.di" log file:
Code: 
+ export 'MTOOLS_SKIP_CHECK=1'
+ [ -z ]
+ [ -z ]
+ bootmbr='-b /usr/embedded/amd64usb/_.w/boot/boot0sio'
+ bootbsd='-b /usr/embedded/amd64usb/_.w/boot/boot'
+ skiparg=''
+ rm -fr '/usr/embedded/amd64usb/_.s1*'
+ rm -fr /usr/embedded/amd64usb/_.s2
+ rm -fr /usr/embedded/amd64usb/_.s3
+ rm -fr '/usr/embedded/amd64usb/_.s4*'
+ rm -fr '/usr/embedded/amd64usb/_.p1*'
+ rm -fr '/usr/embedded/amd64usb/_.p2*'
+ rm -fr '/usr/embedded/amd64usb/_.p3*'
+ rm -fr '/usr/embedded/amd64usb/_.p4*'
+ rm -fr '/usr/embedded/amd64usb/_.p5*'
+ rm -fr /usr/embedded/amd64usb/_.empty
+ [ -n '' ]
+ [ std-uefi '=' powerpc64-ibm ]
+ [ -z t ]
+ extra='-F /usr/embedded/obj/_.metalog'
+ sz=''
+ eval 'makefs -t ffs -B little' -F /usr/embedded/obj/_.metalog /usr/embedded/amd64usb/_.s3 /usr/embedded/amd64usb/_.w
+ makefs -t ffs -B little -F /usr/embedded/obj/_.metalog /usr/embedded/amd64usb/_.s3 /usr/embedded/amd64usb/_.w
Calculated size of `/usr/embedded/amd64usb/_.s3': 222461952 bytes, 5141 inodes
Extent size set to 32768
/usr/embedded/amd64usb/_.s3: 212.2MB (434496 sectors) block size 32768, fragment size 4096
    using 1 cylinder groups of 212.16MB, 6789 blks, 5632 inodes.
super-block backups (for fsck -b #) at:
 64,
Populating `/usr/embedded/amd64usb/_.s3'
Image `/usr/embedded/amd64usb/_.s3' complete
+ mkimg -s bsd -b /usr/embedded/amd64usb/_.w/boot/boot -p 'freebsd-ufs:=/usr/embedded/amd64usb/_.s3' -o /usr/embedded/amd64usb/_.s3
+ eval 's2=freebsd'
+ s2=freebsd
+ eval 's3=freebsd'
+ s3=freebsd
+ [ -z '' ]
+ echo $'Faking cfg dir, it\'s empty'
Faking cfg dir, it's empty
+ NANO_CFGDIR=/usr/embedded/amd64usb/_.empty
+ mkdir -p /usr/embedded/amd64usb/_.empty
+ eval 'makefs -t ffs -B little' -s 32m /usr/embedded/amd64usb/_.s2 /usr/embedded/amd64usb/_.empty
+ makefs -t ffs -B little -s 32m /usr/embedded/amd64usb/_.s2 /usr/embedded/amd64usb/_.empty
Calculated size of `/usr/embedded/amd64usb/_.s2': 33554432 bytes, 2 inodes
Extent size set to 32768
density reduced from 16777217 to 8192
/usr/embedded/amd64usb/_.s2: 32.0MB (65536 sectors) block size 32768, fragment size 4096
    using 1 cylinder groups of 32.00MB, 1024 blks, 4096 inodes.
super-block backups (for fsck -b #) at:
 64,
Populating `/usr/embedded/amd64usb/_.s2'
Image `/usr/embedded/amd64usb/_.s2' complete
+ [ -n '' ]
+ out=/usr/embedded/images/_.disk.image.amd64usb
+ newfs_msdos -C 64m -F 32 -c 1 -m 0xf8 /usr/embedded/amd64usb/_.w/boot/efiboot.img
/usr/embedded/amd64usb/_.w/boot/efiboot.img: 129022 sectors in 129022 FAT32 clusters (512 bytes/cluster)
BytesPerSec=512 SecPerClust=1 ResSectors=32 FATs=2 Media=0xf8 SecPerTrack=63 Heads=255 HiddenSecs=0 HugeSectors=131072 FATsecs=1008 RootCluster=2 FSInfo=1 Backup=2
+ mmd -i /usr/embedded/amd64usb/_.w/boot/efiboot.img ::/efi ::/efi/boot
+ mcopy -i /usr/embedded/amd64usb/_.w/boot/efiboot.img /usr/embedded/amd64usb/_.w/boot/loader.efi ::/efi/boot/BOOTX64.efi
+ mkimg -a 3 -b /usr/embedded/amd64usb/_.w/boot/boot0sio -s mbr -p 'efi:=/usr/embedded/amd64usb/_.w/boot/efiboot.img' -p 'freebsd:=/usr/embedded/amd64usb/_.s2' -p 'freebsd:=/usr/embedded/amd64usb/_.s3' -o /usr/embedded/images/_.disk.image.amd64usb
+ rm -f /usr/embedded/images/_.disk.image.amd64usb.xz
+ xz -9 --keep /usr/embedded/images/_.disk.image.amd64usb


In this log, there are very interesting lines:
Code: 
Calculated size of `/usr/embedded/amd64usb/_.s3': 222461952 bytes, 5141 inodes
Extent size set to 32768
/usr/embedded/amd64usb/_.s3: 212.2MB (434496 sectors) block size 32768, fragment size 4096
    using 1 cylinder groups of 212.16MB, 6789 blks, 5632 inodes.

So, my "_.s3" file should be 212MB, not 8KB… I still haven't found what is clearing, emptying or corrupting this file. I'll continue to search.


BTW: I'll see later if it was necessary, but I've changed a line: https://github.com/freebsd/freebsd-src/blob/main/tools/tools/nanobsd/embedded/common#L287
The "mkimg" option should be "-a 3" and not "-a 2", to make the third partition active. The second partition is the one for the "/cfg" feature of nanobsd.



Edit: Well, in FreeBSD 13.2 release, the empty "create_code_slice" function doesn't exists, compared to the "main" branch: https://github.com/freebsd/freebsd-src/blob/release/13.2.0/tools/tools/nanobsd/embedded/common


Edit2: I have commented out this two lines: https://github.com/freebsd/freebsd-src/blob/main/tools/tools/nanobsd/embedded/common#L235-L236
Now my _.s3 file stays at 212MB and it is included in my final image! But this two lines probably have a purpose…
 
I still can't make a working image.

I have this three commands which are called in this order:

makefs -t ffs -B little -F /usr/embedded/obj/_.metalog /usr/embedded/amd64usb/_.s3 /usr/embedded/amd64usb/_.w

mkimg -s bsd -b /usr/embedded/amd64usb/_.w/boot/boot -p 'freebsd-ufs:=/usr/embedded/amd64usb/_.s3' -o /usr/embedded/amd64usb/_.s3

mkimg -a 3 -b /usr/embedded/amd64usb/_.w/boot/boot0sio -s mbr -p 'efi:=/usr/embedded/amd64usb/_.w/boot/efiboot.img' -p 'freebsd:=/usr/embedded/amd64usb/_.s2' -p 'freebsd:=/usr/embedded/amd64usb/_.s3' -o /usr/embedded/images/_.disk.image.amd64usb


When the first command is run, it creates my "_.s3" file, of a few hundreds megabytes.
When the second is run, it will corrupt my "_.s3" file, making it a 8KB file.


So, I changed the second command to output in "_.s3a" instead of "_.s3". It's done similarly for others layout with the defined variabled "NANO_SLICE_ROOT" and "NANO_ROOT" (which ended up with the letter "a").
My "_.s3a" is a few KB bigger than the "_.s3", so I guess it would be alright.
And of course, I changed the third command to use my new "_.s3a" file instead of "_.s3"…

Unfortunately, my router will still not boot from it.

Not sure what should be correct:
Code: 
# file /usr/embedded/amd64usb/_.s3
/usr/embedded/amd64usb/_.s3: Unix Fast File system [v1] (little-endian), last mounted on , last written at Sat Apr 29 20:26:50 2023, clean flag 1, number of blocks 73472, number of data blocks 73279, number of cylinder groups 1, block size 32768, fragment size 4096, minimum percentage of free blocks 8, rotational delay 0ms, disk rotational speed 60rps, TIME optimization
Code: 
# file /usr/embedded/amd64usb/_.s3a
/usr/embedded/amd64usb/_.s3a: DOS/MBR boot sector, BSD disklabel


Regarding my previous post, I tested both "mkimg -a 2…" and "mkimg -a 3…" to select the active partition.

Not sure what to try next :-/


Edit: just checked the image "pfSense-CE-memstick-2.6.0-RELEASE-amd64.img" (which works fine), and the large active "freebsd" partition is "DOS/MBR boot sector, BSD disklabel". Like my "_.s3a" file.
So, not sure what it's missing on my side.


Edit2: I have just download "FreeBSD-13.2-RELEASE-amd64-mini-memstick.img" and "dd"ed it on my flash drive: the installer boots fine on my router!
I "just" have to find how to make a nanobsd image boot the same way…
 
When the router boots and stop with the message: "/boot/lua/loader.lua".

With the command "show", I can see "currdev" and "loaddev" are equals to "disk0p2".

So I tried:
Code: 
set currdev=disk0p3
autoboot

and it boots!

Now I have to find why it doesn't try to boot from the correct partition.


Edit: The "mkimg -s bsd …" command ( https://github.com/freebsd/freebsd-src/blob/main/tools/tools/nanobsd/embedded/common#L235-L236 ) may be useless: I can still "boot" with an image built without it. (well, still a manual boot, for now I haven't found how to set "currdev" permanently).
 
Well, finally it's booting without manual action! :D

In my "efi" partition, I needed to create this file: "/efi/freebsd/loader.env" with this content:
rootdev=disk0p3
(Thanks to this thread: https://forums.freebsd.org/threads/loader-efi-in-efi-is-not-able-to-boot-freebsd-13-0.82829/ )

Well, now I have a ton of things to clean. Also, my image is just a simple one using "amd64.cfg", and I feel like I still have a lot of work to make my real image for my router.

I'll see tomorrow if I can find some time to work on this.
 
You must log in or register to reply here.
Back
Top