Re: NanoBSD on Raspberry Pi3

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