Perplexing inconsistency in patch level

Hi,

I just patched my kernels for the latest round of advisories. Then I noticed an inconsistency in the patch level:
Code:
[ritz.156] #  uname -a
FreeBSD ritz.oakes.consulting 11.4-RELEASE-p9 FreeBSD 11.4-RELEASE-p9 #0: Tue Apr  6 09:27:45 UTC 2021     root@amd64-builder.daemonology.net:/usr/obj/usr/src/sys/GENERIC  amd64

[ritz.158] # sysctl -a | grep RELEASE
kern.osrelease: 11.4-RELEASE-p9
kern.version: FreeBSD 11.4-RELEASE-p9 #0: Tue Apr  6 09:27:45 UTC 2021

[ritz.159] # freebsd-update fetch
Looking up update.FreeBSD.org mirrors... 2 mirrors found.
Fetching metadata signature for 11.4-RELEASE from update2.freebsd.org... done.
Fetching metadata index... done.
Inspecting system... done.
Preparing to download files... done.

No updates needed to update system to 11.4-RELEASE-p13.

[ritz.160] # freebsd-update install
No updates are available to install.
Run '/usr/sbin/freebsd-update fetch' first.
How is that I can be at FreeBSD 11.4-RELEASE-p9, with no updates needed to update system to 11.4-RELEASE-p13, and nothing to install?
 
D

Deleted member 30996

Guest
Code:
jitte@bakemono:~ $ freebsd-version -k
12.2-RELEASE-p7
jitte@bakemono:~ $ freebsd-version -r
12.2-RELEASE-p7
jitte@bakemono:~ $ freebsd-version -u
12.2-RELEASE-p9
jitte@bakemono:~ $

That's normal.
 
What's your output from freebsd-version -kru ? You have separate patch levels for kernel and userland; refer to freebsd-version(1).
Code:
[ritz.156] $ freebsd-version -kru
11.4-RELEASE-p9
11.4-RELEASE-p9
11.4-RELEASE-p13
Have you rebooted?
Yes
That's normal.
So it would seem. Confusing though.

You learn something every day.

The userland and kernel versions might benefit from occupying a discernibly different name space!
 
I have to agree it's a bit weird. o_O
I never use the command, I just use uname (and don't play with UNAME_ environment variables).
Then again, I don't binary patch. :eek:
 

SirDice

Administrator
Staff member
Administrator
Moderator
The last couple of patches didn't patch anything in the kernel, so the kernel wasn't updated. Since that version string is baked into the kernel at compile time your kernel would still show the 'old' version. That's why freebsd-version(1) exists, so you can actually look at the patch version of the userland.
 
Top