Bug 275482
| Summary: | ports-mgmt/pkg: incorrectly complains about outdated os version | ||
|---|---|---|---|
| Product: | Ports & Packages | Reporter: | Martin Birgmeier <d8zNeCFG> |
| Component: | Individual Port(s) | Assignee: | freebsd-pkg (Nobody) <pkg> |
| Status: | Closed Not A Bug | ||
| Severity: | Affects Only Me | CC: | emaste |
| Priority: | --- | Flags: | bugzilla:
maintainer-feedback?
(pkg) |
| Version: | Latest | ||
| Hardware: | Any | ||
| OS: | Any | ||
|
Description
Martin Birgmeier
2023-12-02 11:02:00 UTC
A commit in branch stable/14 references this bug: URL: https://cgit.FreeBSD.org/src/commit/?id=daa0dc908882f1a724dbe61af2ee86115bd86461 commit daa0dc908882f1a724dbe61af2ee86115bd86461 Author: Randall Stewart <rrs@FreeBSD.org> AuthorDate: 2023-11-27 19:38:06 +0000 Commit: Gleb Smirnoff <glebius@FreeBSD.org> CommitDate: 2024-01-16 18:47:49 +0000 Fix two latent bugs in hpts. One where a static is put on a local variable, the other an initialization bug where we should be setting tv.tv_sec to 0. PR: 275482 (cherry picked from commit 6a79e48076bcce3e902323e62689eacb98faa180) sys/netinet/tcp_hpts.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) I am currently running stable/14 at a727d8d7f50f06a83b391428b0fa8b6436f0e210 with minor modifications, and the issue is still here. pkg gets its "running" from the uname binary file You local userland is probably outdated, try uname -UK No it is not: [1]# uname -UK 1400507 1400507 [0]# And the issue still persists. -- Martin Adding to the previous, the systems are currently on stable/14 a727d8d7f50f (with minor local patches) and latest ports (including ports-mgmt/pkg). you do incremental build of you stable system don't you ? if yes please run file /usr/bin/uname Yes indeed. And the output is interesting: [0]# file /usr/bin/uname /usr/bin/uname: ELF 64-bit LSB pie executable, x86-64, version 1 (FreeBSD), dynamically linked, interpreter /libexec/ld-elf.so.1, for FreeBSD 14.0 (1400500), FreeBSD-style, stripped [0]# ll /usr/bin/uname -r-xr-xr-x 1 root wheel 14336 Feb 9 20:49 /usr/bin/uname [0]# So it says 1400500 although it has been installed with the build of a727d8d7f50f. And the way I update the system is to first installkernel installworld it to a temporary directory and then to copy over only the changed files (this is so that dump(8)s and zvol changes are minimized). So uname must have changed when I did the NO_CLEAN buildworld, but still it says "for FreeBSD 14.0 (1400500)". Anyhow, does this mean that pkg fetches the system version from the uname binary instead of getting the actual value from the running system? -- Martin yes pkg fetches from uname because it is supposed to be rebuilt each time _FreeBSD_version is bumped and because we want to determine if we are running from a chroot or a jail or a rootdir which may have older userland that the running system, that said, there is a bug in the build system when building with NO_CLEAN which makes a part of the toolchain which hold the information about the version not in the elf to not be rebuilt (this is fixed in head and should hopefully be MFCed soon. Your problem will be fixed then. https://cgit.freebsd.org/src/commit/?id=ed3563b0ac31d854bf907d4d847ac0195ec9637b Thank you for the detailed explanation, this explains what is going on. Is this approach used only to determine the userland version or also the kernel version? -- Martin (In reply to Baptiste Daroussin from comment #8) Note that my commit in ed3563b0ac31 is necessary but not sufficient to fix the issue. My change will cause the CRT files to be rebuilt when __FreeBSD_version is changed, but the binaries do not have a dependency on those and so uname will not be rebuilt. @emaste it actually is sufficient, uname is always rebuilt because it requires sys/params.h for uname -U and now thanks to your fix, it wears the proper elf note. @Martin: nothing in pkg do actually determine the running kernel (beside it says it is kernel, but it is actually the running userland, I should fix the message). (In reply to Baptiste Daroussin from comment #11) I cherry-picked the patch from comment 1 to stable/14 (actually my own parallel branch) and rebuilt. The result is that /usr/bin/uname did not change, after installing "file /usr/bin/uname" still gives the same result as in comment 7. Ed seems to be right in comment 10. -- Martin (In reply to Martin Birgmeier from comment #13) You probably need to touch param.h after cherry-picking my change -- that should cause csu* to get rebuilt and then uname in turn. It should happen again after any future param.h update. (In reply to Ed Maste from comment #14) Oops my "it" was ambiguous, should be: The rebuild should happen again automatically after any future param.h update in the tree. Ah, of course! - Missed this. Thanks for the hint. -- Martin Checking sys/sys/param.h reveals that it was last changed on Feb. 9. [0]% cd /usr/src [0]% ll sys/sys/param.h -rw-r--r-- 1 src srcs 13577 Feb 9 12:03 sys/sys/param.h [0]% git log sys/sys/param.h | head -8 commit b566e44b2b88eb9f1b3b658998c7418cccab9e2f Author: Konstantin Belousov <kib@FreeBSD.org> Date: Wed Jan 31 02:47:49 2024 +0200 stable/14: bump __FreeBSD_version for kcmp(2) and kern_openatfp(9) Sponsored by: The FreeBSD Foundation [0]% On Feb. 14 I did the cherry-pick: [0]% fc -liD 1 | grep cherry-pick 4986 2024-02-14 07:44 0:37 git cherry-pick ed3563b0ac31d854bf907d4d847ac0195ec9637b [0]% And I started the -DNO_CLEAN buildworld buildkernel later (I am keeping logfiles whose name contains the start time): [0]# ll /usr/obj/usr/src/make.-j16.-DNO_CLEAN.buildworld.buildkernel.KERNCONF=XYZZY_SMP.XYZZY_SMP_VM.GENERIC.2024-02-14.19:07:32@v904 -rw-r--r-- 1 root srcs 37319862 Feb 14 19:50 /usr/obj/usr/src/make.-j16.-DNO_CLEAN.buildworld.buildkernel.KERNCONF=XYZZY_SMP.XYZZY_SMP_VM.GENERIC.2024-02-14.19:07:32@v904 [0]# And crtbrand.o really was rebuilt: [0]% ll /usr/obj/usr/src/amd64.amd64/lib/csu/amd64 total 39 -rw-r--r-- 1 root srcs 2280 Feb 14 19:11 Scrt1.o -rw-r--r-- 1 root srcs 960 Nov 11 17:41 Scrt1_c.o -rw-r--r-- 1 root srcs 2288 Feb 14 19:11 crt1.o -rw-r--r-- 1 root srcs 1160 Nov 11 17:41 crt1_c.o -rw-r--r-- 1 root srcs 968 Nov 11 17:41 crt1_s.o -rw-r--r-- 1 root srcs 2304 Feb 9 17:18 crtbegin.o -rw-r--r-- 1 root srcs 2560 Feb 9 17:18 crtbeginS.o -rw-r--r-- 1 root srcs 2304 Feb 9 17:18 crtbeginT.o -rw-r--r-- 1 root srcs 664 Feb 14 19:11 crtbrand.o -rw-r--r-- 1 root srcs 1720 Nov 11 17:41 crtend.o -rw-r--r-- 1 root srcs 1720 Nov 11 17:41 crtendS.o -rw-r--r-- 1 root srcs 1072 Feb 14 19:11 crti.o -rw-r--r-- 1 root srcs 656 Nov 11 17:41 crti_s.o -rw-r--r-- 1 root srcs 600 Nov 11 17:41 crtn.o -rw-r--r-- 1 root srcs 552 Nov 11 17:41 feature_note.o -rw-r--r-- 1 root srcs 2432 Feb 14 19:11 gcrt1.o -rw-r--r-- 1 root srcs 1104 Nov 11 17:41 gcrt1_c.o -rw-r--r-- 1 root srcs 552 Nov 11 17:41 ignore_init_note.o [0]% But uname was not: [0]% ll /usr/obj/usr/src/amd64.amd64/usr.bin/uname total 24 -rwxr-xr-x 1 root srcs 17464 Feb 9 17:48 uname -rw-r--r-- 1 root srcs 2015 Nov 11 18:01 uname.1.gz -rw-r--r-- 1 root srcs 23192 Feb 9 17:48 uname.o [0]% So the events were - sys/sys/param.h update on Feb 9 - cherry-pick on Feb 14 - build -DNO_CLEAN on Feb 14 And the result was that crtbrand.o was indeed rebuilt, but not uname. Would uname be rebuilt if I touched param.h again? -- Martin (In reply to Martin Birgmeier from comment #17) It looks like you're missing a touch param.h after cherry-picking my change. param.h has to be newer than both *crt*.o and uname for both to be built and for uname to pick up the new version tag With the explanations given here, let us close this. -- Martin |
