Re: NanoBSD on Raspberry Pi3
- Reply: Guido Falsi : "Re: NanoBSD on Raspberry Pi3"
- In reply to: Guido Falsi : "NanoBSD on Raspberry Pi3"
- Go to: [ bottom of page ] [ top of archives ] [ this month ]
Date: Sun, 05 Nov 2023 03:04:48 UTC
On 5/11/2023 3:50 am, Guido Falsi wrote: > Hi all! > > I am trying to build a NanoBSD image for a spare RPi3. > > I started from an existing configuration I am using for a PCEngine > APU2 board, I use as an internal DNS and DHCP server. I'd like to > replace it. > > I'd also like to be able to upgrade using the altroot partition and > then switching the default one, but am not sure how to do that, maybe > I can play with efi variables, anyway I'm going to investigate this > once I get at least FreeBSD booting. > > Unluckily I am unable to make my image properly boot. One of the keys to doing the dual system in my case has been to create a loader.env file telling the loader which partition to boot. # more EFI/freebsd/loader.env rootdev=disk0s3a > > I have reworked my scripts to replicate how the official release > images are made in structure. (copying a lot from src/release) > > I got t the point where loader_lua.efi (renamed as the standard > `/EFI/BOOT/bootaa64.efi` in the fat partition) loads, looks like it is > scanning disks but then says: > > ERROR: cannot open /boot/lua/loader.lua: no such file or directory. The loader.env should be read by the bootaa64.efi program. > > > It gives me a prompt, but even if I do have a working USB keyboard > plugged in I am unable to interact (maybe this is normal at this stage?) No idea, sorry. > > I guess it is failing to find the root filesystem but I don't know > why. There is a valid root partition. Do I need to put some boot code > in it to make loader recognize it? > > Where could I find some more detailed information about u-boot and > UEFI boot? Maybe I can help by creating some configuration file in the > UEFI partition? > > Thanks in advance for any indication. > > > Output of `gpart show` (fromthe image mounted as md): > > => 63 8617921 md1 MBR (4.1G) > 63 961 - free - (481K) > 1024 65536 1 fat32lba [active] (32M) > 66560 131072 2 freebsd (64M) > 197632 4194304 3 freebsd (2.0G) > 4391936 4194304 4 freebsd (2.0G) > 8586240 31744 - free - (16M) > > => 0 4194304 md1s3 BSD (2.0G) > 0 128 - free - (64K) > 128 4194176 1 freebsd-ufs (2.0G) > > > (it looks quite similar to the official image one, as far as I can see) I'm using: # gpart show => 1 62357503 mmcsd0 MBR (30G) 1 65536 1 fat32lba [active] (32M) 65537 65536 2 freebsd (32M) 131073 31113215 3 freebsd (15G) 31244288 31113216 4 freebsd (15G) => 0 31113215 mmcsd0s3 BSD (15G) 0 16 - free - (8.0K) 16 31113199 1 freebsd-ufs (15G) => 0 31113216 mmcsd0s4 BSD (15G) 0 8192 - free - (4.0M) 8192 31105024 1 freebsd-ufs (15G) And it works really well. This is taken from a running rpi3. I also have the same layout on a pi3 at $work, an original 256MB pi (forever stuck on version13 now), and a 8GB pi4. My modified update script toggles the loader.env file after updating the alternate file system and running the growfs magic on it. It looks like you have that organised properly. > > > Not sure what other information I can share, but I will send anything > that can help shed some light. > > Cheers, Brian