Solved host and jail version are the same but differ from pkg OSVERSION

nbari

Active Member

Reaction score: 11
Messages: 106

The output of uname -K in both host and jail is the same, currently 1202505, but when I run pkg -vv | grep OSVERSION inside the jail I get a different version:
Code:
OSVERSION = 1201512;

Any idea of what I could be missing within the pkg within the jail is returning a different version?

When trying to upgrade something I get:

Newer FreeBSD version for package php73-zlib:
To ignore this error set IGNORE_OSVERSION=yes
- package: 1202000
- running kernel: 1201512

but the running kernel in both the HOST and JAIL is the same 1202505, not 1201512
 

SirDice

Administrator
Staff member
Administrator
Moderator

Reaction score: 12,767
Messages: 39,377

The output of uname -K in both host and jail is the same
A jail doesn't have a kernel, so this shows the kernel version of the host in both cases.

Any idea of what I could be missing within the pkg within the jail is returning a different version?
Look at freebsd-version -u on the host and the jail. This will show you the version of the userland.

I suspect you have upgraded the host to 12.2 but the jail is still on 12.1.
 
OP
nbari

nbari

Active Member

Reaction score: 11
Messages: 106

Both host/jail show same version when using freebsd-version -u, in this case: 12.2-STABLE
 

SirDice

Administrator
Staff member
Administrator
Moderator

Reaction score: 12,767
Messages: 39,377

Can you check if that OSVERSION is perhaps hard set in /usr/local/etc/pkg.conf?

freebsd-version(8) mentions this:
Code:
     -r          Print the version and patch level of the running kernel.
                 Unlike uname(1), this is unaffected by environment variables.
And looking further in uname(1):
Code:
ENVIRONMENT
     An environment variable composed of the string UNAME_ followed by any
     flag to the uname utility (except for -a) will allow the corresponding
     data to be set to the contents of the environment variable.  See uname(3)
     for more information.
uname(3) mentions these:
Code:
ENVIRONMENT
     UNAME_s      If the environment variable UNAME_s is set, it will override
                  the sysname member.

     UNAME_r      If the environment variable UNAME_r is set, it will override
                  the release member.

     UNAME_v      If the environment variable UNAME_v is set, it will override
                  the version member.

     UNAME_m      If the environment variable UNAME_m is set, it will override
                  the machine member.
Can you check if you have a UNAME_* variable defined in the jail perhaps?

One of those environment variables appears to be set somewhere and this throws off pkg(8).
 
OP
nbari

nbari

Active Member

Reaction score: 11
Messages: 106

I had to remove the usr/src/obj directory and rebuild because this file usr/src/amd64.amd64/host-osreldate.h was not getting updated or at least seems not be updated when using "-DNO_CLEAN":

Code:
env MAKEOBJDIRPREFIX=/jroot/build/obj SRCCONF=/etc/src-jail.conf __MAKE_CONF=/etc/make.conf make -DNO_CLEAN -j${NUMBER_OF_CORES} buildworld
 

Mjölnir

Daemon

Reaction score: 1,511
Messages: 2,114

Using devel/ccache instead of caching build results through /usr/obj (should be /var/obj) would have avoided this issue, because then you can safely ommit -DNO_CLEAN?
 
OP
nbari

nbari

Active Member

Reaction score: 11
Messages: 106

Using devel/ccache instead of caching build results through /usr/obj (should be /var/obj) would have avoided this issue, because then you can safely ommit -DNO_CLEAN?
Hi, could you please explain how to use ccache when building the world?
 

Mjölnir

Daemon

Reaction score: 1,511
Messages: 2,114

pkg alias|fgrep message
Code:
message              'query '[%C/%n] %M''
rmessage             'rquery '[%o] %M''
pkg message ccache
Code:
[devel/ccache] On install:
NOTE:
Please read /usr/local/share/doc/ccache/ccache-howto-freebsd.txt for
information on using ccache with FreeBSD ports and src.
 

bsd-harry

New Member


Messages: 1

I had to remove the usr/src/obj directory and rebuild because this file usr/src/amd64.amd64/host-osreldate.h was not getting updated or at least seems not be updated when using "-DNO_CLEAN":
Code:
env MAKEOBJDIRPREFIX=/jroot/build/obj SRCCONF=/etc/src-jail.conf __MAKE_CONF=/etc/make.conf make -DNO_CLEAN -j${NUMBER_OF_CORES} buildworld

Relevant files I found so far to understand why this helped:
pkg-1.16.3/libpkg/pkg_config.c resp. pkg-1.16.3/libpkg/pkg_elf.c (ports-mgmt/pkg):
Maybe pkg(8) implemented OSVERSION check before the sysctl() kern.osreldate was available, or for any other reason I don't understand, but it checks elf headers (elfdump(1)) of /usr/bin/uname.

So if you compile kernel+world with -DNO_CLEAN resp. WITHOUT_CLEAN=true (in src.conf(5)), everything might be fine, but NT_FREEBSD_ABI_TAG of /usr/bin/uname won't correspond to the actual (meanwhile updated) __FreeBSD_version in sys/sys/param.h.

To check what pkg(8) thinks your world dates to (although claiming 'running kernel'): pkg config OSVERSION
One solution is to set OSVERSION to what sysctl kern.osreldate reports in pkg.conf(5).

But I prefer not adjusting things which shouldn't need adjusting, so I made sure uname will be re-compiled even with WITHOUT_CLEAN=true by deleting the objdir obj{/arch}/usr.bin/uname.
To my surprise, the new binary again showed the outdated __FreeBSD_version ( elfdump -a obj/i386.i386/usr.bin/uname/uname | grep NT_FREEBSD_ABI_TAG).
Since I don't understand ELF and build/make-framework to the degree necessary to read what to do, I tried deleting /usr/bin/uname's shared object dependency too:
obj/lib/libc/
Again, obj{/arch}/usr.bin/uname/uname still showed the outdated NT_FREEBSD_ABI_TAG.

After failing with removing obj/lib/libelf* likewise, I set OSVERSION for now (cross compiling ia32 on amd64).
Removing the complete obj tree means 4 hours llvm compilation... just to pet pkg(8) :-(

Maybe somebody else can elaborate which object files need to be deleted/rebuilt in order to get elfump(1) reporting the sys/sys/param.h matching NT_FREEBSD_ABI_TAG of usr/bin/uname?

Thanks,
-harry

P.S.: Removing the whole obj/lib path (together wirth obj/usr.bin/uname/) gave the disired results. At the cost of some hours llvm compile time...
 
Top