Re: pkg: Newer FreeBSD version for package... but why?
- In reply to: John Baldwin : "Re: pkg: Newer FreeBSD version for package... but why?"
- Go to: [ bottom of page ] [ top of archives ] [ this month ]
Date: Wed, 13 Jul 2022 19:13:24 UTC
unsubscribe On Wed, Jul 13, 2022 at 12:33 PM John Baldwin <jhb@freebsd.org> wrote: > On 7/13/22 3:17 AM, Andriy Gapon wrote: > > On 2022-07-13 13:09, Michael Gmelin wrote: > >> > >> > >> On Wed, 13 Jul 2022 10:29:06 +0300 > >> Andriy Gapon <avg@FreeBSD.org> wrote: > >> > >>> # uname -U > >>> 1400063 > >>> > >>> # uname -K > >>> 1400063 > >>> > >>> # pkg upgrade > >>> Updating FreeBSD repository catalogue... > >>> Fetching packagesite.pkg: 100% 5 MiB 4.8MB/s 00:01 > >>> Processing entries: 0% > >>> Newer FreeBSD version for package zyre: > >>> To ignore this error set IGNORE_OSVERSION=yes > >>> - package: 1400063 > >>> - running kernel: 1400051 > >>> Ignore the mismatch and continue? [y/N]: > >>> > >>> Does anyone know why this would happen? > >>> Where does pkg get its notion of the running kernel version? > >>> > >> > >> If I'm reading the sources correctly, it's determining the OS version > >> by looking at the elf headers of various files in this order: > >> > >> getenv("ABI_FILE") > >> /usr/bin/uname > >> /bin/sh > >> > >> So I would assume that `file /usr/bin/uname` shows 1400051 on your > >> system. > > > > Thank you very much! That's it: > > # file /usr/bin/uname > > /usr/bin/uname: ELF 32-bit LSB executable, ARM, EABI5 version 1 > > (FreeBSD), dynamically linked, interpreter /libexec/ld-elf.so.1, > > FreeBSD-style, for FreeBSD 14.0 (1400051), stripped > > > >> You can point it to checking another file by setting ABI_FILE[0] in the > >> environment or ignore the check by setting IGNORE_OSVERSION (like > >> advised). The "running kernel:" label seems a bit misleading. > > > > Indeed. > > > > Now the next thing (for me) to research is why the binaries were built > > "for FreeBSD 14.0 (1400051)" when the source tree has 1400063 and uname > > -U also reports 1400063. > > FWIW, this was a cross-build, maybe that played a role too. > > If you do a NO_CLEAN=yes build, we don't relink binaries just because > crt*.o changed (where the note is stored). > > -- > John Baldwin > >