Re: Where/how to submit proposed patches to Nanobsd provided files?

On Tue, May 13, 2025, 7:40 AM Karl Denninger <karl@denninger.net> wrote:

> I've put some time in on the "Nanobsd" build process files that do a few
> things:
>
> 1. Support efi dual-boot mode (EFI or not) while keeping an MBR partition
> layout so older devices can still boot the media and also keep the data
> partition.  Basically, set up Partition 4 as an extended "BSD" partition
> with "a" (cfg) and "d" (data, if non-zero size) so they both work.  This
> involved essentially a rewrite of the "legacy" file entirely since the
> partition creation was done through awk basically emitting a script it then
> executed; it was much easier to, due to the different types involved, just
> do "nah", make a calculation for the code segments, subtract off space for
> the EFI partition and cfg area and then use what's left for data.
>
This has already been rewritten to not use the awk script, I thought.
Though maybe just for gpt since very few systems actually require mbr.

> 2. Put the EFI partition in slot 3 thus the "dual image, online update"
> capacity is unperturbed.  Place the loader in
> EFI/BOOT/{architecture-specific-name} as defined in the config file.  This
> is harmless if the machine is CSM boot but if its EFI it will find it and
> boot using it.
>

This is good.

> 3. Update the "updatepx" files distributed to look for an EFI partition on
> the NanoBSD device and, if found, set loader.env which should then cause
> the EFI loader to use the correct load partition since the "active" flag is
> ignored otherwise.
>
Efibootmgr is the new way. When it works, its the most reliable.

There's also a gptboot.efi if you want an on media thing that doesn't
ignore the FreeBSD specific hack/partition flag.

> Should I put these up somewhere for possible review and inclusion?  I use
> this to build bootable sticks or SD cards for firewall appliances that run
> "read-only" and thus are power-fail safe, and have tested against both a
> commodity EFI-boot-only dual-NIC "NUC" style PC and also the older
> pcEngines apu2 series.
>
Yea. I've been busy for a while, but am starting to have time again. I
think i replied to submit a github pull request. I notice those. Anything
else is a huge crap shoot since bz has a terrible code review interface
(and I have too many bugs assigned to me anyway) and phabricator is
terrible for non-committers since there's no oversight. We're getting
better at bugzilla at least.

But I am planning a github run next week online on Discord so if you have
it submitted by Saturday it will be in for sure for that and I might be
able to do a review before it even.

Warner


-- 
> Karl Denninger
> karl@denninger.net
> *The Market Ticker*
> *[S/MIME encrypted email preferred]*
>