From Newsgroup: muc.lists.freebsd.stable

Folks,

I am feeling increasing pain from finding EFI partitions floating
around and containing spurious binaries in /EFI/BOOT/BOOTX64.efi,
where there seems to be no means whatsoever for figuring out what
these binaries do/are at all, or which version of it they would be
and what they can support.

Currently I am in the process of migrating from R.13 to R.14, and
strangely the loader is now in the process of shrinking (from 862720
to 662528), so even "the larger the newer" won't hold.

Question: is there any concept to get some proper version information
into these binaries, from which then some identity and the commit tag
could be retrieved from which they were created?

regards,
PMc


--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-admin@muc.de
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: muc.lists.freebsd.stable

On Wed, Aug 27, 2025 at 10:08:19AM +0200, Peter 'PMc' Much wrote:

I am feeling increasing pain from finding EFI partitions floating
around and containing spurious binaries in /EFI/BOOT/BOOTX64.efi,
where there seems to be no means whatsoever for figuring out what
these binaries do/are at all, or which version of it they would be
and what they can support.

Currently I am in the process of migrating from R.13 to R.14, and
strangely the loader is now in the process of shrinking (from 862720
to 662528), so even "the larger the newer" won't hold.

Question: is there any concept to get some proper version information
into these binaries, from which then some identity and the commit tag
could be retrieved from which they were created?

I asked this same question on the forums:

https://forums.freebsd.org/threads/verify-loader-version.96446/

No one could answer the question "how do you know the bootloader is
authentic and matches the OS".

I was disappointed that the IDS output didn't even cover /boot.

Bootloaders are a critical part of the OS, and I just have to assume
that whatever is in /boot is current with the OS and should be blindly
copied to the EFI partition. I have no way to confirm what version of bootloader I have, or what version is in EFI.

It's very frustrating. Please let me know if you find a solution.

------------------------------------------------------------------
Russell Adams Russell.Adams@AdamsSystems.nl
Principal Consultant Adams Systems Consultancy
https://adamssystems.nl/


--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-admin@muc.de
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: muc.lists.freebsd.stable

27.08.2025 15:08, Peter 'PMc' Much wrote:

I am feeling increasing pain from finding EFI partitions floating
around and containing spurious binaries in /EFI/BOOT/BOOTX64.efi,
where there seems to be no means whatsoever for figuring out what
these binaries do/are at all, or which version of it they would be
and what they can support.

Currently I am in the process of migrating from R.13 to R.14, and
strangely the loader is now in the process of shrinking (from 862720
to 662528), so even "the larger the newer" won't hold.

Question: is there any concept to get some proper version information
into these binaries, from which then some identity and the commit tag
could be retrieved from which they were created?

Maybe:

# strings /boot/loader.efi | fgrep Revision
DFreeBSD/amd64 EFI loader, Revision 3.0



--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-admin@muc.de
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: muc.lists.freebsd.stable

Hi!

Question: is there any concept to get some proper version information
into these binaries, from which then some identity and the commit tag
could be retrieved from which they were created?

Maybe:

# strings /boot/loader.efi | fgrep Revision
DFreeBSD/amd64 EFI loader, Revision 3.0

I tried this:

strings loader.efi | fgrep Revision
11.1:
FreeBSD/amd64 EFI loader, Revision 1.1
12.2:
FreeBSD/amd64 EFI loader, Revision 1.1
13.2:
FreeBSD/amd64 EFI loader, Revision 1.1
14.x/15.x:
FreeBSD/amd64 EFI loader, Revision 3.0

but the size of the file was different in all 1.1 cases.
So I'm not sure it really defines the exact version.
--
pi@FreeBSD.org +49 171 3101372 Now what ?


--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-admin@muc.de
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: muc.lists.freebsd.stable

On Wed, Aug 27, 2025 at 07:59:46PM +0700, Eugene Grosbein wrote:
! 27.08.2025 15:08, Peter 'PMc' Much wrote:
!
! > I am feeling increasing pain from finding EFI partitions floating
! > around and containing spurious binaries in /EFI/BOOT/BOOTX64.efi,
! > where there seems to be no means whatsoever for figuring out what
! > these binaries do/are at all, or which version of it they would be
! > and what they can support.
! >
! > Currently I am in the process of migrating from R.13 to R.14, and
! > strangely the loader is now in the process of shrinking (from 862720
! > to 662528), so even "the larger the newer" won't hold.
! >
! > Question: is there any concept to get some proper version information
! > into these binaries, from which then some identity and the commit tag
! > could be retrieved from which they were created?
!
! Maybe:
!
! # strings /boot/loader.efi | fgrep Revision
! DFreeBSD/amd64 EFI loader, Revision 3.0

Sorry, but not really.

The loader.efi for 13.5 and 14.3 appear to be both "Revision 3.0", and
there is a zfs pool upgrade in between, and we get a warning to upgrade
the loader (I didn't want to test if it harms when we don't).
This revision number does apparently not hold for practical purposes. :(

What I would expect in humble decadence ;) is probably a "version"
command inside the loader cmdline, and (since getting the git
commit-id into the code is quite an amount of pain) at least the
userland version string (which does exist in some header file).

@ Russell Adams: I just decided to share Your frustration.

The problem is not so much the files as they are placed into
/boot. These files are part of userland and therefore in the
responsibility of the local upgrade procedures (however the
site admin decides to do that - I'm building from source, for
instance).

But as soon as the loader is copied into an efi partition, there
is no longer any way to determine what binary that is (except
bytewise comparison).
And when we start juggling with guest images of various releases,
this can become quite interesting, in an unfunny way.

cheerio,
PMc


--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-admin@muc.de
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: muc.lists.freebsd.stable

On 8/27/25 09:03, Kurt Jaeger wrote:

Hi!

Question: is there any concept to get some proper version information
into these binaries, from which then some identity and the commit tag
could be retrieved from which they were created?

Maybe:

# strings /boot/loader.efi | fgrep Revision
DFreeBSD/amd64 EFI loader, Revision 3.0

I tried this:

strings loader.efi | fgrep Revision
11.1:
FreeBSD/amd64 EFI loader, Revision 1.1
12.2:
FreeBSD/amd64 EFI loader, Revision 1.1
13.2:
FreeBSD/amd64 EFI loader, Revision 1.1
14.x/15.x:
FreeBSD/amd64 EFI loader, Revision 3.0

but the size of the file was different in all 1.1 cases.
So I'm not sure it really defines the exact version.

We've historically basically not touched the loader version, but Warner
made the hop away from 1.1 after years and we could probably do a better
job bumping the minor version going forward.


--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-admin@muc.de
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: muc.lists.freebsd.stable

On Wed, Aug 27, 2025 at 04:03:18PM +0200, Kurt Jaeger wrote:

Hi!

Question: is there any concept to get some proper version information into these binaries, from which then some identity and the commit tag could be retrieved from which they were created?

Maybe:

# strings /boot/loader.efi | fgrep Revision
DFreeBSD/amd64 EFI loader, Revision 3.0

I tried this:

strings loader.efi | fgrep Revision
11.1:
FreeBSD/amd64 EFI loader, Revision 1.1
12.2:
FreeBSD/amd64 EFI loader, Revision 1.1
13.2:
FreeBSD/amd64 EFI loader, Revision 1.1
14.x/15.x:
FreeBSD/amd64 EFI loader, Revision 3.0

but the size of the file was different in all 1.1 cases.
So I'm not sure it really defines the exact version.

--
pi@FreeBSD.org +49 171 3101372 Now what ?

This was exactly my experience in the forum post. Multiple versions
had the same "Revision" tag, and there is no way to crossreference
with a specific Freebsd version.

------------------------------------------------------------------
Russell Adams Russell.Adams@AdamsSystems.nl
Principal Consultant Adams Systems Consultancy
https://adamssystems.nl/


--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-admin@muc.de
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: muc.lists.freebsd.stable

--000000000000da6306063d59af12
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Wed, Aug 27, 2025 at 8:12=E2=80=AFAM Russell Adams <Russell.Adams@adamss= ystems.nl>
wrote:

On Wed, Aug 27, 2025 at 04:03:18PM +0200, Kurt Jaeger wrote:

Hi!

Question: is there any concept to get some proper version informati=

on

into these binaries, from which then some identity and the commit t=

ag

could be retrieved from which they were created?

Maybe:

# strings /boot/loader.efi | fgrep Revision
DFreeBSD/amd64 EFI loader, Revision 3.0

I tried this:

strings loader.efi | fgrep Revision
11.1:
FreeBSD/amd64 EFI loader, Revision 1.1
12.2:
FreeBSD/amd64 EFI loader, Revision 1.1
13.2:
FreeBSD/amd64 EFI loader, Revision 1.1
14.x/15.x:
FreeBSD/amd64 EFI loader, Revision 3.0

but the size of the file was different in all 1.1 cases.
So I'm not sure it really defines the exact version.

--
pi@FreeBSD.org +49 171 3101372 Now what ?

This was exactly my experience in the forum post. Multiple versions
had the same "Revision" tag, and there is no way to crossreference
with a specific Freebsd version.

We used to encode the date the loader was built. Reproducible builds
stopped that.

The Revision tag really is what boot protocol is supported. That protocol changes very rarely.

It's not been a goal to communicate the version, and generally, there's no
good way to know. You can tell loader.efi vs boot1.efi, that's about it.

commit a97b71605af6c68c785b02f573ed880d87635d04
Author: Ed Maste <emaste@FreeBSD.org>
Date: Mon Dec 19 14:45:59 2016 +0000

Build loaders reproducibly when WITH_REPRODUCIBLE_BUILD

When WITH_REPRODUCIBLE_BUILD=3Dyes is set in src.conf(5), eliminate the
time, user, and host from the loader's version information. This allow=
s
builds to produce bit-for-bit identical output.

If you build WITHOUT_REPRODUCIBLE_BUILD, you'd get version info.

Warner

--000000000000da6306063d59af12
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div dir=3D"ltr"><br></div><br><div class=3D"gmail_quote g= mail_quote_container"><div dir=3D"ltr" class=3D"gmail_attr">On Wed, Aug 27,=
2025 at 8:12=E2=80=AFAM Russell Adams &lt;<a href=3D"mailto:Russell.Adams@= adamssystems.nl">Russell.Adams@adamssystems.nl</a>&gt; wrote:<br></div><blo= ckquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left= :1px solid rgb(204,204,204);padding-left:1ex">On Wed, Aug 27, 2025 at 04:03= :18PM +0200, Kurt Jaeger wrote:<br>
&gt; Hi!<br>
&gt;<br>
&gt; &gt; &gt; Question: is there any concept to get some proper version in= formation<br>
&gt; &gt; &gt; into these binaries, from which then some identity and the c= ommit tag<br>
&gt; &gt; &gt; could be retrieved from which they were created?<br>
&gt; &gt;<br>
&gt; &gt; Maybe:<br>
&gt; &gt;<br>
&gt; &gt; # strings /boot/loader.efi | fgrep Revision<br>
&gt; &gt; DFreeBSD/amd64 EFI loader, Revision 3.0<br>
&gt;<br>
&gt; I tried this:<br>
&gt;<br>
&gt; strings loader.efi | fgrep Revision<br>
&gt; 11.1:<br>
&gt; FreeBSD/amd64 EFI loader, Revision 1.1<br>
&gt; 12.2:<br>
&gt; FreeBSD/amd64 EFI loader, Revision 1.1<br>
&gt; 13.2:<br>
&gt; FreeBSD/amd64 EFI loader, Revision 1.1<br>
&gt; 14.x/15.x:<br>
&gt; FreeBSD/amd64 EFI loader, Revision 3.0<br>
&gt;<br>
&gt; but the size of the file was different in all 1.1 cases.<br>
&gt; So I&#39;m not sure it really defines the exact version.<br>
&gt;<br>
&gt; --<br>
&gt; pi@FreeBSD.org=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0+49 171 3101372=C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Now what ?<br>
&gt;<br>

This was exactly my experience in the forum post. Multiple versions<br>
had the same &quot;Revision&quot; tag, and there is no way to crossreferenc= e<br>
with a specific Freebsd version.</blockquote><div><br></div><div>We used to=
encode the date the loader was built. Reproducible builds stopped that.</d= iv><div><br></div><div>The Revision tag really is what boot protocol is sup= ported. That protocol changes very rarely.</div><div><br></div><div>It&#39;=
s not been a goal to communicate the version, and generally, there&#39;s no=
good way to know. You can tell loader.efi vs boot1.efi, that&#39;s about i= t.</div><div><br></div><div>commit a97b71605af6c68c785b02f573ed880d87635d04= <br>Author: Ed Maste &lt;emaste@FreeBSD.org&gt;<br>Date: =C2=A0 Mon Dec 19 = 14:45:59 2016 +0000<br><br>=C2=A0 =C2=A0 Build loaders reproducibly when WI= TH_REPRODUCIBLE_BUILD<br>=C2=A0 =C2=A0 <br>=C2=A0 =C2=A0 When WITH_REPRODUC= IBLE_BUILD=3Dyes is set in src.conf(5), eliminate the<br>=C2=A0 =C2=A0 time=
, user, and host from the loader&#39;s version information.=C2=A0 This allo= ws<br>=C2=A0 =C2=A0 builds to produce bit-for-bit identical output.<br></di= v><div><br></div><div>If you build WITHOUT_REPRODUCIBLE_BUILD, you&#39;d ge=
t version info.=C2=A0 =C2=A0=C2=A0<br></div><div><br></div><div>Warner=C2= =A0</div></div></div>

--000000000000da6306063d59af12--


--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-admin@muc.de
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: muc.lists.freebsd.stable

On Thu, Aug 28, 2025 at 12:20:56AM +0900, Tomoaki AOKI wrote:

Question: is there any concept to get some proper version information
into these binaries, from which then some identity and the commit tag
could be retrieved from which they were created?

We used to encode the date the loader was built. Reproducible builds stopped that.

Can't git hash (full or first 12 digits, possibly plus n**** number,
too) like in kernel help the situation? Yes, it shouldn't be suitable
for legacy bootcodes (wastes of bytes!), though.

Really I don't care if the data is embedded in the bootcode. I
understand it may be in a difficult format with limited space.

I'm not building my own here. I just want to be able to find out what
I have vs what was shipped.

I would expect that the OS distribution tools (freebsd-upgrade) can
verify the files I have installed, including the boot loader it is
shipping into /boot.

I'd like to be able to compare the checksums of bootloaders I have
from EFI against a table of checksums of the same files across
authentic distributions. Even if it was just a text file in /var that freebsd-update uses or I could grep. I was disappointed that
"freebsd-upgrade IDS" never mentioned files in /boot.

I must manually update the bootloader when I upgrade FreeBSD. If I
mess up, or lose track, I need a way to find out what I have in EFI
against files shipped with FreeBSD.

------------------------------------------------------------------
Russell Adams Russell.Adams@AdamsSystems.nl
Principal Consultant Adams Systems Consultancy
https://adamssystems.nl/


--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-admin@muc.de
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: muc.lists.freebsd.stable

--0000000000009b47c9063d5b10c0
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Wed, Aug 27, 2025 at 10:00=E2=80=AFAM Mel P. <list_freebsd@bluerosetech.=

wrote:

On 2025-08-27 7:34, Warner Losh wrote:

On Wed, Aug 27, 2025 at 8:12=E2=80=AFAM Russell Adams <Russell.Adams@adamssystems.nl <mailto:Russell.Adams@adamssystems.nl>> wrote:
This was exactly my experience in the forum post. Multiple versions
had the same "Revision" tag, and there is no way to crossreference
with a specific Freebsd version.

We used to encode the date the loader was built. Reproducible builds stopped that.

The Revision tag really is what boot protocol is supported. That
protocol changes very rarely.

If loaders had the version and patch level hardcoded into them it during
the build like how that information is hardcoded into freebsd-version,
would that be a reproducible build? If so, can EFI loaders with ZFS
support also have the OpenZFS version? For example:

FreeBSD/amd64 EFI loader, Revision 1.1, 13.5-RELEASE, OpenZFS-2.1.15

Those two version numbers would be immensely helpful when moving disks
or verifying upgrades.

Yea, that's not going to happen. The loader is independent of the release,
in many ways, 13.5-RELEASE comes from the kernel, and this would introduce
a coupling between the two. We generally don't have the OpenZFS version available. We don't sync to OpenZFS releases, necessarily. Also, the boot loader only makes limited use of the OpenZFS code, so its version wouldn't necessarily help you. There's often a lag between OpenZFS code hitting the
tree and the boot loader understanding new items introduced by that import.

We can report the _FreeBSD_version for the tree we build in, though. And
that will give you information. We don't currently bump it, though, when we
add ZFS features to the whitelist of enabled features, but could. This
would make it still reproducible.

I'm on the fence about git hashes. I generally don't like it. But we do it
for the kernel, and it might be appropriate here. Though it introduces a dependency on the git tree and the 'n' number is highly dependent on how
the tree was cloned.

Warner

--0000000000009b47c9063d5b10c0
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div dir=3D"ltr"><br></div><br><div class=3D"gmail_quote g= mail_quote_container"><div dir=3D"ltr" class=3D"gmail_attr">On Wed, Aug 27,=
2025 at 10:00=E2=80=AFAM Mel P. &lt;<a href=3D"mailto:list_freebsd@blueros= etech.com">list_freebsd@bluerosetech.com</a>&gt; wrote:<br></div><blockquot=
e class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px s= olid rgb(204,204,204);padding-left:1ex">On 2025-08-27 7:34, Warner Losh wro= te:<br>
&gt; On Wed, Aug 27, 2025 at 8:12=E2=80=AFAM Russell Adams <br>
&gt; &lt;<a href=3D"mailto:Russell.Adams@adamssystems.nl" target=3D"_blank"= >Russell.Adams@adamssystems.nl</a> &lt;mailto:<a href=3D"mailto:Russell.Ada= ms@adamssystems.nl" target=3D"_blank">Russell.Adams@adamssystems.nl</a>&gt;= &gt; <br>
&gt; wrote:<br>
&gt;=C2=A0 =C2=A0 =C2=A0This was exactly my experience in the forum post. M= ultiple versions<br>
&gt;=C2=A0 =C2=A0 =C2=A0had the same &quot;Revision&quot; tag, and there is=
no way to crossreference<br>
&gt;=C2=A0 =C2=A0 =C2=A0with a specific Freebsd version.<br>
&gt; <br>
&gt;<br>
&gt; We used to encode the date the loader was built. Reproducible builds <=

&gt; stopped that.<br>
&gt; <br>
&gt; The Revision tag really is what boot protocol is supported. That <br>
&gt; protocol changes very rarely.<br>
If loaders had the version and patch level hardcoded into them it during <b=

the build like how that information is hardcoded into freebsd-version, <br> would that be a reproducible build?=C2=A0 If so, can EFI loaders with ZFS <=

support also have the OpenZFS version?=C2=A0 For example:<br>

FreeBSD/amd64 EFI loader, Revision 1.1, 13.5-RELEASE, OpenZFS-2.1.15<br>

Those two version numbers would be immensely helpful when moving disks <br>
or verifying upgrades.<br></blockquote><div><br></div><div>Yea, that&#39;s = not going to happen. The loader is independent of the release, in many ways=
, 13.5-RELEASE comes from the kernel, and this would introduce a coupling b= etween the two. We generally don&#39;t have the OpenZFS version available. =
We don&#39;t sync to OpenZFS releases, necessarily. Also, the boot loader o= nly makes limited use of the OpenZFS code, so its version wouldn&#39;t nece= ssarily help you. There&#39;s often a lag between OpenZFS code hitting the = tree and the boot loader understanding new items introduced by that import.= </div><div><br></div><div>We can report the _FreeBSD_version for the tree w=
e build in, though. And that will give you information. We don&#39;t curren= tly bump it, though, when we add ZFS features to the whitelist of enabled f= eatures, but could. This would make it still reproducible.</div><div><br></= div><div>I&#39;m on the fence about git hashes. I generally don&#39;t like = it. But we do it for the kernel, and it might be appropriate here. Though i=
t introduces a dependency on the git tree and the &#39;n&#39; number is hig= hly dependent on how the tree was cloned.</div><div><br></div><div>Warner= =C2=A0</div></div></div>

--0000000000009b47c9063d5b10c0--


--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-admin@muc.de
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: muc.lists.freebsd.stable

i get why reproducible builds are a good thing and maybe only way forward but that makes system debugging much harder. once we get rid of n and hash in kernel too, that leaves only, what, fbsd version and release name? eg, which 16-current it is, where was it built and when. or maybe we should get rid or in-kernel version as well, as patchlevel interferes with pkgbase, i mean it already does now. in many cases kernel doesn't get patched at all. i mean holy hell. that would mean pkg would be the only thing to query versions from? that would create whole new world to figure out is the system patched or not...
--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-admin@muc.de
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: muc.lists.freebsd.stable

On Wed, 27 Aug 2025 14:25:40 -0700
"Edward Sanford Sutton, III" <mirror176@hotmail.com> wrote:

On 8/27/25 08:37, Russell Adams wrote:

On Thu, Aug 28, 2025 at 12:20:56AM +0900, Tomoaki AOKI wrote:

Question: is there any concept to get some proper version information >>>>>>> into these binaries, from which then some identity and the commit tag >>>>>>> could be retrieved from which they were created?

We used to encode the date the loader was built. Reproducible builds
stopped that.

Can't git hash (full or first 12 digits, possibly plus n**** number,
too) like in kernel help the situation? Yes, it shouldn't be suitable
for legacy bootcodes (wastes of bytes!), though.

Really I don't care if the data is embedded in the bootcode. I
understand it may be in a difficult format with limited space.

I'm not building my own here. I just want to be able to find out what
I have vs what was shipped.

I would expect that the OS distribution tools (freebsd-upgrade) can
verify the files I have installed, including the boot loader it is
shipping into /boot.

My understanding is freebsd-update leaves all boot loaders alone.
Having new ZFS code didn't break booting but upgrading a ZFS pool breaks boot access to the pool without a corresponding boot loader update. That
was not just an EFI issue.
I forget where but recall someone wrote a script to try to detect a difference and replace (or give instructions?) if different but it
didn't know what version anything is either. My attempt at writing a
check in my source based update scripts hasn't been correct yet but
again it was a non-version based difference check.

Maybe this one?

https://www.freshports.org/sysutils/loaders-update

It was discussed here at the beginning.

https://forums.freebsd.org/threads/utility-that-tries-to-figure-how-to-update-the-freebsd-loaders.94237/

Would NOT be covering 100% of possible configurations, though.

I'd like to be able to compare the checksums of bootloaders I have
from EFI against a table of checksums of the same files across
authentic distributions. Even if it was just a text file in /var that freebsd-update uses or I could grep. I was disappointed that "freebsd-upgrade IDS" never mentioned files in /boot.

I must manually update the bootloader when I upgrade FreeBSD. If I
mess up, or lose track, I need a way to find out what I have in EFI
against files shipped with FreeBSD.

------------------------------------------------------------------
Russell Adams Russell.Adams@AdamsSystems.nl Principal Consultant Adams Systems Consultancy

--
Tomoaki AOKI <junchoon@dec.sakura.ne.jp>


--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-admin@muc.de
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: muc.lists.freebsd.stable

--000000000000640fe2063d814c1a
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Fri, Aug 29, 2025, 7:12=E2=80=AFAM Tomoaki AOKI <junchoon@dec.sakura.ne.=

wrote:

On Wed, 27 Aug 2025 10:52:30 -0700
"Mel P." <list_freebsd@bluerosetech.com> wrote:

On 2025-08-27 9:13, Warner Losh wrote:

On Wed, Aug 27, 2025 at 10:00=E2=80=AFAM Mel P. <list_freebsd@blueros=

etech.com

<mailto:list_freebsd@bluerosetech.com>> wrote:

If loaders had the version and patch level hardcoded into them it
during
the build like how that information is hardcoded into

freebsd-version,

would that be a reproducible build? If so, can EFI loaders with

ZFS

support also have the OpenZFS version? For example:

FreeBSD/amd64 EFI loader, Revision 1.1, 13.5-RELEASE,

OpenZFS-2.1.15

Those two version numbers would be immensely helpful when moving

disks

or verifying upgrades.

Yea, that's not going to happen. The loader is independent of the release, in many ways, 13.5-RELEASE comes from the kernel, and this
would introduce a coupling between the two. We generally don't have

the

OpenZFS version available. We don't sync to OpenZFS releases, necessarily. Also, the boot loader only makes limited use of the

OpenZFS

code, so its version wouldn't necessarily help you. There's often a

lag

between OpenZFS code hitting the tree and the boot loader

understanding

new items introduced by that import.

This is very good to know, thank you.

We can report the _FreeBSD_version for the tree we build in, though.

And

that will give you information. We don't currently bump it, though,

when

we add ZFS features to the whitelist of enabled features, but could.
This would make it still reproducible.

__FreeBSD_version would be just as helpful.

That feature whitelist is exactly the information needed when figuring
out if a given loader can boot a given pool and fs. Would it be
possible to include that in the loader in a way that strings or some
other utility can find it?

Unfortunately, __FreeBSD_version is NOT promised to be bumped everytime loader/bootcode receive new ZFS read-incompatible features support.

Two points: it gets bumped fairly often anyway, so there only a few commits between the change and a zfs change. This is also true, btw, for the change
in the tree and the bumps. There's often a lag. So it's always going to be bother pretty good on the long scane, and imprecise on the short. It's also
the same everywhere no matter what.

This is why I previously commented with git hash and/or n number.


This is harder and introduces a git dependency to the loader process. The kernel has this, true. And hg, svn, gitup and a few others. It's a mess
that I'd rather not have since the loader is built a dozen times, not once
like the kernel, and any slowdown when one of the above scms misbehaves is greater.

Warner

--=20

Tomoaki AOKI <junchoon@dec.sakura.ne.jp>

--000000000000640fe2063d814c1a
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"auto"><div><br><br><div class=3D"gmail_quote gmail_quote_contai= ner"><div dir=3D"ltr" class=3D"gmail_attr">On Fri, Aug 29, 2025, 7:12=E2=80= =AFAM Tomoaki AOKI &lt;<a href=3D"mailto:junchoon@dec.sakura.ne.jp">junchoo= n@dec.sakura.ne.jp</a>&gt; wrote:<br></div><blockquote class=3D"gmail_quote=
" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">O=
n Wed, 27 Aug 2025 10:52:30 -0700<br>
&quot;Mel P.&quot; &lt;<a href=3D"mailto:list_freebsd@bluerosetech.com" tar= get=3D"_blank" rel=3D"noreferrer">list_freebsd@bluerosetech.com</a>&gt; wro= te:<br>

&gt; On 2025-08-27 9:13, Warner Losh wrote:<br>
&gt; &gt; On Wed, Aug 27, 2025 at 10:00=E2=80=AFAM Mel P. &lt;<a href=3D"ma= ilto:list_freebsd@bluerosetech.com" target=3D"_blank" rel=3D"noreferrer">li= st_freebsd@bluerosetech.com</a> <br>
&gt; &gt; &lt;mailto:<a href=3D"mailto:list_freebsd@bluerosetech.com" targe= t=3D"_blank" rel=3D"noreferrer">list_freebsd@bluerosetech.com</a>&gt;&gt; w= rote:<br>
&gt; &gt; <br>
&gt; &gt;=C2=A0 =C2=A0 =C2=A0If loaders had the version and patch level har= dcoded into them it<br>
&gt; &gt;=C2=A0 =C2=A0 =C2=A0during<br>
&gt; &gt;=C2=A0 =C2=A0 =C2=A0the build like how that information is hardcod=
ed into freebsd-version,<br>
&gt; &gt;=C2=A0 =C2=A0 =C2=A0would that be a reproducible build?=C2=A0 If s=
o, can EFI loaders with ZFS<br>
&gt; &gt;=C2=A0 =C2=A0 =C2=A0support also have the OpenZFS version?=C2=A0 F=
or example:<br>
&gt; &gt; <br>
&gt; &gt;=C2=A0 =C2=A0 =C2=A0FreeBSD/amd64 EFI loader, Revision 1.1, 13.5-R= ELEASE, OpenZFS-2.1.15<br>
&gt; &gt; <br>
&gt; &gt;=C2=A0 =C2=A0 =C2=A0Those two version numbers would be immensely h= elpful when moving disks<br>
&gt; &gt;=C2=A0 =C2=A0 =C2=A0or verifying upgrades.<br>
&gt; &gt; <br>
&gt; &gt; <br>
&gt; &gt; Yea, that&#39;s not going to happen. The loader is independent of=
the <br>
&gt; &gt; release, in many ways, 13.5-RELEASE comes from the kernel, and th=
is <br>
&gt; &gt; would introduce a coupling between the two. We generally don&#39;=
t have the <br>
&gt; &gt; OpenZFS version available. We don&#39;t sync to OpenZFS releases,=

&gt; &gt; necessarily. Also, the boot loader only makes limited use of the = OpenZFS <br>
&gt; &gt; code, so its version wouldn&#39;t necessarily help you. There&#39=
;s often a lag <br>
&gt; &gt; between OpenZFS code hitting the tree and the boot loader underst= anding <br>
&gt; &gt; new items introduced by that import.<br>
&gt; <br>
&gt; This is very good to know, thank you.<br>
&gt; <br>
&gt; &gt; We can report the _FreeBSD_version for the tree we build in, thou= gh. And <br>
&gt; &gt; that will give you information. We don&#39;t currently bump it, t= hough, when <br>
&gt; &gt; we add ZFS features to the whitelist of enabled features, but cou= ld. <br>
&gt; &gt; This would make it still reproducible.<br>
&gt; <br>
&gt; __FreeBSD_version would be just as helpful.<br>
&gt; <br>
&gt; That feature whitelist is exactly the information needed when figuring=

&gt; out if a given loader can boot a given pool and fs.=C2=A0 Would it be =

&gt; possible to include that in the loader in a way that strings or some <=

&gt; other utility can find it?<br>

Unfortunately, __FreeBSD_version is NOT promised to be bumped everytime<br> loader/bootcode receive new ZFS read-incompatible features support.<br></bl= ockquote></div></div><div dir=3D"auto"><br></div><div dir=3D"auto">Two poin= ts: it gets bumped fairly often anyway, so there only a few commits between=
the change and a zfs change. This is also true, btw, for the change in the=
tree and the bumps. There&#39;s often a lag. So it&#39;s always going to b=
e bother pretty good on the long scane, and imprecise on the short. It&#39;=
s also the same everywhere no matter what.</div><div dir=3D"auto"><br></div= ><div dir=3D"auto"><div class=3D"gmail_quote gmail_quote_container"><blockq= uote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc = solid;padding-left:1ex">
This is why I previously commented with git hash and/or n number.<br></bloc= kquote></div></div><div dir=3D"auto"><br></div><div dir=3D"auto">This is ha= rder and introduces a git dependency to the loader process. The kernel has = this, true. And hg, svn, gitup and a few others. It&#39;s a mess that I&#39=
;d rather not have since the loader is built a dozen times, not once like t=
he kernel, and any slowdown when one of the above scms misbehaves is greate= r.</div><div dir=3D"auto"></div><div dir=3D"auto"><br></div><div dir=3D"aut= o">Warner</div><div dir=3D"auto"><br></div><div dir=3D"auto"><div class=3D"= gmail_quote gmail_quote_container"><blockquote class=3D"gmail_quote" style= =3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
-- <br>
Tomoaki AOKI=C2=A0 =C2=A0 &lt;<a href=3D"mailto:junchoon@dec.sakura.ne.jp" = target=3D"_blank" rel=3D"noreferrer">junchoon@dec.sakura.ne.jp</a>&gt;<br> </blockquote></div></div></div>

--000000000000640fe2063d814c1a--


--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-admin@muc.de
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: muc.lists.freebsd.stable

--0000000000000f58de063da09a6e
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Sat, Aug 30, 2025 at 7:11=E2=80=AFPM Tomoaki AOKI <junchoon@dec.sakura.n= e.jp>
wrote:

On Sat, 30 Aug 2025 16:45:15 -0700
"Mel P." <list_freebsd@bluerosetech.com> wrote:

On 2025-08-30 16:34, Tomoaki AOKI wrote:

On Fri, 29 Aug 2025 07:49:49 -0600
Warner Losh <imp@bsdimp.com> wrote:

On Fri, Aug 29, 2025, 7:12=E2=80=AFAM Tomoaki AOKI <junchoon@dec.sak=

ura.ne.jp

wrote:

This is why I previously commented with git hash and/or n number.

This is harder and introduces a git dependency to the loader process=

.

The

kernel has this, true. And hg, svn, gitup and a few others. It's a

mess

that I'd rather not have since the loader is built a dozen times, no=

t

once

like the kernel, and any slowdown when one of the above scms

misbehaves is

greater.

Warner

Yeah, precisely determining what read-incompatible features is/are enabled (whitelisted) is the key point for the bootcodes / loaders.

Using date/time, ancient method was (IIRC) the date/time the bootcode=

s

/ loaders are "built", NOT "committed to master repo".

Obtaining the actually wanted date / time needs git functionality
in current form, thus, heavy-weighted for bootcodes / loaders.

Just have it store the whitelist in a retrievable format. Provide the information directly.

The whitelist would be this.

https://cgit.freebsd.org/src/tree/stand/libsa/zfs/zfsimpl.c#n109

Note that it includes only read-incompatible features supported.
So seeing this alone could confuse like "Isn't feature xxx supported?
Should I re-create pool without the (read-compatible) feature xxx?!".

The comment in the file is clear enough for me, but what about for
someone just started learning about ZFS?

To know features including read-compatible ones that are "enabled"
by default ("active" is another thing), we need to understand
in what state the whole ZFS codes are when the bootcode / loader
is built. And this require to specify the commit the build is
done at.

Warner, please correct me if I'm mis-understanding.
I believe you're the best person who knows correctly in loader area.

Generally, that's correct. Many new features are 'read-only' stable.
Meaning, if they are enabled, then the on-media format isn't affected, so read-only applications like the boot loader can read them effectively. Most
new features are like this, and none of these new ZFS features needs a new loader...

The problem comes when there's new features that aren't exactly 'read-only-stable' but which the bootloader can none-the-less read. These features are added with a much slower rate, and it's not always clear if a feature falls into this category or not. The latest one being the feature
that allows one to expand a ZRAID. There's some on-media implications for
that, but it's not clear if the loader should allow it or not. So far,
we've come down on the side of 'not' and recommend you don't enable it for
your root dataset. The boot loader reading routines would need code to
properly read a zraid dataset that's being expanded in case the kernel or
klds (or whatever) lands in the area that matters (I don't recall all the details, but while things are rebalancing for the dataset, the striping is variable and the boot code would need to know that, but currently does not)=
.

So FreeBSD's _FreeBSD_version changes on the order of weekly. We get, on
main, about 30-80 changes a year over the recent history of FreeBSD. This
is why I said that the main FreeBSD version is a good 'ticker' to see if
the boot loader you have likely will boot the BE with different bells and whistles enabled. The rate that there's new features that aren't read-only-stable that the loader can none-the-less read is on the order of
once or thrice a year (though there was a period just after we adopted
OpenZFS this was much faster, since OpenZFS was catching up on the built-up backlog of features to integrate). This suggests to me that even if we
don't bump OpenZFS on each import (which happens about monthly), we'll
still be able to use it FreeBSD version to know if a given Zpool can be
booted.

I'm not sure about having a full database for this. It strikes me as rather overkill. However, it would be nice, perhaps, if we had a list of features
and FreeBSD versions that bectl (and zpool upgrade maybe) could add some (possibly optional, unsure on that point) safety that says 'Hold on, that upgrade with that boot loader is trouble! Watch yourself!' or something.
Sadly, I'm already multiply overbooked...

Warner

P.S. I'm sure I got the names pedantically incorrect... 'read incompatible'
is more correct, for example... Fixing this after the fact is too hard in firefox since gmail on this chromebook is super slow to edit, but not bad
for writing...

--0000000000000f58de063da09a6e
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div dir=3D"ltr"><br></div><br><div class=3D"gmail_quote g= mail_quote_container"><div dir=3D"ltr" class=3D"gmail_attr">On Sat, Aug 30,=
2025 at 7:11=E2=80=AFPM Tomoaki AOKI &lt;<a href=3D"mailto:junchoon@dec.sa= kura.ne.jp">junchoon@dec.sakura.ne.jp</a>&gt; wrote:<br></div><blockquote c= lass=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px soli=
d rgb(204,204,204);padding-left:1ex">On Sat, 30 Aug 2025 16:45:15 -0700<br> &quot;Mel P.&quot; &lt;<a href=3D"mailto:list_freebsd@bluerosetech.com" tar= get=3D"_blank">list_freebsd@bluerosetech.com</a>&gt; wrote:<br>

&gt; On 2025-08-30 16:34, Tomoaki AOKI wrote:<br>
&gt; &gt; On Fri, 29 Aug 2025 07:49:49 -0600<br>
&gt; &gt; Warner Losh &lt;<a href=3D"mailto:imp@bsdimp.com" target=3D"_blan= k">imp@bsdimp.com</a>&gt; wrote:<br>
&gt; &gt; <br>
&gt; &gt;&gt; On Fri, Aug 29, 2025, 7:12=E2=80=AFAM Tomoaki AOKI &lt;<a hre= f=3D"mailto:junchoon@dec.sakura.ne.jp" target=3D"_blank">junchoon@dec.sakur= a.ne.jp</a>&gt;<br>
&gt; &gt;&gt; wrote:<br>
&gt; &gt;&gt;<br>
&gt; &gt;&gt; This is why I previously commented with git hash and/or n num= ber.<br>
&gt; &gt;&gt;&gt;<br>
&gt; &gt;&gt;<br>
&gt; &gt;&gt; This is harder and introduces a git dependency to the loader = process. The<br>
&gt; &gt;&gt; kernel has this, true. And hg, svn, gitup and a few others. I= t&#39;s a mess<br>
&gt; &gt;&gt; that I&#39;d rather not have since the loader is built a doze=
n times, not once<br>
&gt; &gt;&gt; like the kernel, and any slowdown when one of the above scms = misbehaves is<br>
&gt; &gt;&gt; greater.<br>
&gt; &gt;&gt;<br>
&gt; &gt;&gt; Warner<br>
&gt; &gt; <br>
&gt; &gt; Yeah, precisely determining what read-incompatible features is/ar= e<br>
&gt; &gt; enabled (whitelisted) is the key point for the bootcodes / loader= s.<br>
&gt; &gt; <br>
&gt; &gt; Using date/time, ancient method was (IIRC) the date/time the boot= codes<br>
&gt; &gt; / loaders are &quot;built&quot;, NOT &quot;committed to master re= po&quot;.<br>
&gt; &gt; <br>
&gt; &gt; Obtaining the actually wanted date / time needs git functionality=

&gt; &gt; in current form, thus, heavy-weighted for bootcodes / loaders.<br=

&gt; <br>
&gt; Just have it store the whitelist in a retrievable format.=C2=A0 Provid=
e the <br>
&gt; information directly.<br>

The whitelist would be this.<br>

=C2=A0 <a href=3D"https://cgit.freebsd.org/src/tree/stand/libsa/zfs/zfsimpl= .c#n109" rel=3D"noreferrer" target=3D"_blank">https://cgit.freebsd.org/src/= tree/stand/libsa/zfs/zfsimpl.c#n109</a><br>

Note that it includes only read-incompatible features supported.<br>
So seeing this alone could confuse like &quot;Isn&#39;t feature xxx support= ed?<br>
Should I re-create pool without the (read-compatible) feature xxx?!&quot;.<=


The comment in the file is clear enough for me, but what about for<br>
someone just started learning about ZFS?<br>

To know features including read-compatible ones that are &quot;enabled&quot= ;<br>
by default (&quot;active&quot; is another thing), we need to understand<br>
in what state the whole ZFS codes are when the bootcode / loader<br>
is built. And this require to specify the commit the build is<br>
done at.<br>

Warner, please correct me if I&#39;m mis-understanding.<br>
I believe you&#39;re the best person who knows correctly in loader area.</b= lockquote><div><br></div><div>Generally, that&#39;s correct. Many new featu= res are &#39;read-only&#39; stable. Meaning, if they are enabled, then the = on-media format isn&#39;t affected, so read-only applications like the boot=
loader can read them effectively. Most new features are like this, and non=
e of these new ZFS features needs a new loader...</div><div><br></div><div>= The problem comes when there&#39;s new features that aren&#39;t exactly &#3= 9;read-only-stable&#39; but which the bootloader can none-the-less read. Th= ese features are added with a much slower rate, and it&#39;s not always cle=
ar if a feature falls into this category or not. The latest one being the f= eature that allows one to expand a ZRAID. There&#39;s some on-media implica= tions for that, but it&#39;s not clear if the loader should allow it or not=
. So far, we&#39;ve come down on the side of &#39;not&#39; and recommend yo=
u don&#39;t enable it for your root dataset. The boot loader reading routin=
es would need code to properly read a zraid dataset that&#39;s being expand=
ed in case the kernel or klds=C2=A0(or whatever) lands in the area that mat= ters (I don&#39;t recall all the details, but while things are rebalancing = for the dataset, the striping is variable and the boot code would need to k= now that, but currently does not).</div><div><br></div><div>So FreeBSD&#39;=
s _FreeBSD_version changes on the order of weekly. We get, on main, about 3= 0-80 changes a year over the recent history of FreeBSD. This is why I said = that the main FreeBSD version is a good &#39;ticker&#39; to see if the boot=
loader you have likely will boot the BE with different bells and whistles = enabled.=C2=A0 The rate that there&#39;s new features that aren&#39;t read-= only-stable that the loader can none-the-less read is on the order of once =
or thrice a year (though there was a period just after we adopted OpenZFS t= his was much faster, since OpenZFS was catching up on the built-up backlog =
of features to integrate). This suggests to me that even if we don&#39;t bu=
mp OpenZFS on each import (which happens about monthly), we&#39;ll still be=
able to use it FreeBSD version to know if a given Zpool can be booted.</di= v><div><br></div><div>I&#39;m not sure about having a full database for thi=
s. It strikes me as rather overkill. However, it would be nice, perhaps, if=
we had a list of features and FreeBSD versions that bectl (and zpool upgra=
de maybe) could add some (possibly optional, unsure on that point) safety t= hat says &#39;Hold on, that upgrade with that boot loader is trouble! Watch=
yourself!&#39; or something. Sadly, I&#39;m already multiply overbooked...= </div><div><br></div><div>Warner</div><div><br></div><div>P.S. I&#39;m sure=
I got the names pedantically incorrect... &#39;read incompatible&#39; is m= ore correct, for example... Fixing this after the fact is too hard in firef=
ox since gmail on this chromebook is super slow to edit, but not bad for wr= iting...</div></div></div>

--0000000000000f58de063da09a6e--


--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-admin@muc.de
--- Synchronet 3.21a-Linux NewsLink 1.2