Date: Tue, 13 May 2025 20:24:26 -0600 From: Warner Losh <imp@bsdimp.com> To: Karl Denninger <karl@denninger.net> Cc: freebsd-embedded <freebsd-embedded@freebsd.org> Subject: Re: Where/how to submit proposed patches to Nanobsd provided files? Message-ID: <CANCZdfqvd%2Bouq=b3Tba-qM2WuzCSeP=f_%2BRMyAMZhLEfiwCt%2Bg@mail.gmail.com> In-Reply-To: <5887b3f9-8820-47fb-8d26-94e184cdafeb@denninger.net>
index | next in thread | previous in thread | raw e-mail
[-- Attachment #1 --]
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]*
>
[-- Attachment #2 --]
<div dir="auto"><div><br><br><div class="gmail_quote gmail_quote_container"><div dir="ltr" class="gmail_attr">On Tue, May 13, 2025, 7:40 AM Karl Denninger <<a href="mailto:karl@denninger.net">karl@denninger.net</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><u></u>
<div>
<p>I've put some time in on the "Nanobsd" build process files that
do a few things:</p>
<p>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.</p></div></blockquote></div></div><div dir="auto">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.</div><div dir="auto"><div class="gmail_quote gmail_quote_container"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><p></p></div></blockquote></div></div><div dir="auto"></div><div dir="auto"><div class="gmail_quote gmail_quote_container"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><p>
</p>
<p>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.</p></div></blockquote></div></div><div dir="auto"><br></div><div dir="auto">This is good.</div><div dir="auto"></div><div dir="auto"><div class="gmail_quote gmail_quote_container"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div>
<p>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.</p></div></blockquote></div></div><div dir="auto">Efibootmgr is the new way. When it works, its the most reliable.</div><div dir="auto"><br></div><div dir="auto">There's also a gptboot.efi if you want an on media thing that doesn't ignore the FreeBSD specific hack/partition flag.</div><div dir="auto"><div class="gmail_quote gmail_quote_container"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div>
<p>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.<br></p></div></blockquote></div></div><div dir="auto">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.</div><div dir="auto"><br></div><div dir="auto">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.</div><div dir="auto"><br></div><div dir="auto">Warner</div><div dir="auto"><br></div><div dir="auto"><br></div><div dir="auto"><div class="gmail_quote gmail_quote_container"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><p>
</p>
<div>-- <br>
Karl Denninger<br>
<a href="mailto:karl@denninger.net" target="_blank" rel="noreferrer">karl@denninger.net</a><br>
<i>The Market Ticker</i><br>
<font size="-2"><i>[S/MIME encrypted email preferred]</i></font></div>
</div>
</blockquote></div></div></div>
home |
help
Want to link to this message? Use this
URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CANCZdfqvd%2Bouq=b3Tba-qM2WuzCSeP=f_%2BRMyAMZhLEfiwCt%2Bg>