Re: NanoBSD on Raspberry Pi3

On 5/11/2023 8:13 pm, Guido Falsi wrote:
> 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 found it a couple of years ago after a lot of searching. No idea where 
I found it even though I normally try to keep notes. It would be nice to 
see some doco on it.
>
>>>
>>> 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.
As I understand it, the RPi firmware requires MBR partitioning. Haven't 
confirmed it recently but it does limit what you can do with nanobsd.
>
>>>
>>>
>>> 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).
Good point. I just like it to look neat and tidy. Probably says more 
about me than anything else.
>
>>
>> It looks like you have that organised properly.
>>
>
> Thanks a lot again for your help! Really appreciated.
>
> Cheers!
>