Re: Which version is BOOTX64.efi?

From: Peter 'PMc' Much <pmc_at_citylink.dinoex.sub.org>
Date: Wed, 27 Aug 2025 14:00:33 UTC
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