Re: NanoBSD on Raspberry Pi3

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 <[email protected]>