determination of running FreeBSD kernel is bogus and misreported [pkg 1.20.4]

[mandree]

In a situation, where the OSVERSION got bumped from 1400092 to 1400093 in both my host (buildworld buildkernel installkernel, reboot, etcupdate, installworld, etcupdate, reboot) and also my poudriere jail, I receive packages that are marked as though they had been built for 1400093.

However, pkg misdetermines the "running kernel" as 1400092.

The cause appears to be that:

1. unless ABI_FILES is defined, pkg will read the ELF FreeBSD notes section (equivalent of readelf -n) of both /usr/bin/uname, and /bin/sh, to presume THAT were the version of the running table (pkg_get_myarch() and pkg_get_myarch_elfparse())
2. these files receive the ELF note section from one of the startup files {g,S,}crt[1i].o, crtbrand.o, which are part of the /usr/src/lib/csu build, see also https://www.netbsd.org/Documentation/kernel/elf-notes.html - we're doing the same thing with different tag, and also through these C startup files.
3. these crt files do not get rebuilt with WITH_CCACHE_BUILD=yes WITHOUT_CLEAN=yes in /usr/src.

[mandree@libvirt-freebsdcurrent ~]$ sudo pkg upgrade -r local
Updating local repository catalogue...
Fetching meta.conf: 100%    163 B   0.2kB/s    00:01
Fetching packagesite.pkg: 100%    9 KiB   8.8kB/s    00:01    
Processing entries:   0% 
Newer FreeBSD version for package rhash:
To ignore this error set IGNORE_OSVERSION=yes 
- package: 1400093
- running kernel: 1400092
Ignore the mismatch and continue? [y/N]: 
pkg: repository local contains packages for wrong OS version: FreeBSD:14:amd64

I am currently testing my buildworld script that will "make clean -C /usr/src/lib/csu" first when rebuilding, but is there a reason why pkg is not calling into int getosreldate(void); from libc to figure the running kernel? And it probably also needs to wait for the next OSVERSION update to ...94 or ...100 so that I can really test it.

I can prove with "grep" or "strings" that the running kernel is indeed already 1400093 and no longer 1400092, and this bogus - running kernel: 1400092 when the actual check was performed would suggest - FreeBSD ABI tag of /usr/bin/uname or /bin/sh: 1400092 is what was checked is EXTREMELY CONFUSING and should be fixed.

At the very least, fix the printed text, so that people do not get sent to rebuild their kernels which are fine and up to date, but actually, fix pkg.

[bapt]

it does not check the kernel but the userland because of jail support which might report a newer kernel, what matters is the ABI of the userland you are running not the kernel. so yeah I should probably s/kernel/userland here.

[mandree]

But how can the jail - if it just executing applications under tighter reins but still uses the host's kernel - possibly report a newer kernel?

Of course the userland is also important, if my libc is too old, apparently the build toolchain has some "incompatible OSVERSION and rebuild" figures which I have not fully grokked yet.

[emaste]

But how can the jail - if it just executing applications under tighter reins but still uses the host's kernel - possibly report a newer kernel?

Presumably @bapt means report a newer kernel than the binaries in the jail, not a newer kernel than the host.

That said I agree it's reasonable to check the userland (/usr/bin/uname, /bin/sh) for compatibility, but we should not report the version found there as the "running kernel" version.