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

I'll see if I can get it cleaned up enough to be in a "consider this" 
sort of state by the weekend. It works at present but the legacy file, 
in particular, I duplicated and heavily edited then called the 
replacement instead thus its a bit of a mess right now.  This also was 
what generated my bugzilla report on gpart (if you use "-a" to insure 
alignment it can *shrink* the requested partition size which is an 
instant "screw you" if you then try to dd an image you built into that 
space; IMHO it ought to round up rather than consider going the other 
way as legitimate.)

At issue is that I want the same media to work in both a pcEngines 
(which uses CoreBoot and some older versions are rather crusty; there 
ARE reasonably-current versions available and mine have been flashed to 
them, but there's a lot of that older hardware out there that works 
perfectly well and likely is on the much-older revisions -- I have no 
idea if those can boot GPT media or not) and /also /a rather-picky 
EFI-only "cube" (GMKtec "mini PC") that, as it turns out, makes a very 
nice gigabit-level router/firewall as it has an N150 CPU in it, sips 
power and can saturate both 1G interfaces without breaking a sweat plus 
if you want it has WiFi in it too -- and they're cheap on top of it.)  
That second little SOB however goes directly to the BIOS if it doesn't 
like the EFI layout rather than the EFI shell; it ships with Windows on 
it and for this purpose I pull the SSD entirely since I want the 
"power-fail safe" capacity, thus I boot from a USB-key in "nano" mode.  
If you stick the loader in /EFI/FreeBSD it ignores it; it wants it in 
/EFI/BOOT and only there, at least for "first time around" and it will 
not boot a compatibility-mode device at all.  It almost-certainly will 
boot a GPT USB key but since I don't think the older pcEngines firmware 
will I decided to go the MBR route.

Ultimately I intend to put that image up on my server to the public as 
its a nice "set /etc/rc.conf, do save_cfg along with the ipfw parameter 
file and you're done" firewall/router that has Strongswan built into it 
along with a bunch of other useful stuff.  Its the load I've been using 
more or less for the last many years with the idea being that its a 
"pre-built and power-fail-safe" option for anything that runs a 64-bit 
Intel-style processor that can boot FreeBSD.

Where I wound up with works but quite a bit of hair was extracted from 
my head in the process so a bit of cleanup is necessary before I submit 
it... :-)

On 5/13/2025 22:24, Warner Losh wrote:
>
>
> 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]/
>
-- 
Karl Denninger
karl@denninger.net
/The Market Ticker/
/[S/MIME encrypted email preferred]/