Re: Which version is BOOTX64.efi?

On Fri, Aug 29, 2025, 7:12 AM Tomoaki AOKI <junchoon@dec.sakura.ne.jp>
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 AM Mel P. <list_freebsd@bluerosetech.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

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