On 2025-08-27 9:13, Warner Losh wrote:
On Wed, Aug 27, 2025 at 10:00 AM Mel P. <[email protected]
<mailto:[email protected]>> 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?
