Re: NanoBSD on Raspberry Pi3
- Reply: Brian Scott : "Re: NanoBSD on Raspberry Pi3"
- In reply to: Brian Scott : "Re: NanoBSD on Raspberry Pi3"
- Go to: [ bottom of page ] [ top of archives ] [ this month ]
Date: Sun, 05 Nov 2023 09:13:36 UTC
On 05/11/23 04:04, Brian Scott wrote: > > 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 > Thanks a lot! This made it boot successfully! Obviously the boot spilled a bunch of errors, most just because I'm testing not connected to the network and the configuration expects networking to be available, but this is just a test. Really thanks a lot, this piece of information never turned out in any searches I did and I did not notice it in any man page/README etc. In fact I think this should be documented, if it is not already. Do you know if it is already in some manual page or readme or at least the wiki? If not I think it should be described in loader.efi(8), I'd like to propose a patch to this effect. Maybe also add a note in our wiki in the arm and/or uefi pages. Have you got some pointer to some documentation elsewhere about this so I can write an informed paragraph for the man page about this? >> >> 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. Yes this was the key to making it work. Maybe if I used a gpt partition scheme it would have worked OOB, while mbr requires this kind of help. Not sure if it is worth using gpt or could cause even more issues though. >> >> >> 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. Keyboard works fine once kernel starts, looks like a u-boot issue. Not too worried about it though, as long as FreeBSD boots. >> >> 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. Yes I'll adapt my nanobsd update script to take advantage of the .env file and I should be ready to go. I'm actually skipping the grow part, since I'm never writing to the OS partitions, I'm using them like a firmware, only writing to the cfg partition (or the ramdisks obviously). > > It looks like you have that organised properly. > Thanks a lot again for your help! Really appreciated. Cheers! -- Guido Falsi <mad@madpilot.net>