Re: NanoBSD on Raspberry Pi3

On 05/11/23 12:05, Brian Scott wrote:
> 
> On 5/11/2023 8:13 pm, Guido Falsi wrote:
>> On 05/11/23 04:04, Brian Scott wrote:
>>>
>>> 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 created a code review to update loader.env(8) man page. I really did 
the bare minimum there, but it would be better than nothing anyway:

https://reviews.freebsd.org/D42476

>>
>>>>
>>>> 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.

I see. Well I have no special preference for EFI over MBR as long it 
gets the system booting properly, so I'll stay with MBR.

-- 
Guido Falsi <mad@madpilot.net>