Solved 14.1-RELEASE doesn't upgrade to 14.1-RELEASE-p1

bluray · Jun 22, 2024

I've rebooted and all after using freebsd-update. When I run `freebsd-version` this is the output:

Code:

[sage@Qual ~]$ freebsd-version
14.1-RELEASE-p1

But when I run `uname -a` the output is:

Code:

[sage@Qual ~]$ uname -a
FreeBSD Qual 14.1-RELEASE FreeBSD 14.1-RELEASE releng/14.1-n267679-10e31f0946d8 GENERIC amd64

Please help me, thanks in advance.

derekschrock · Jun 23, 2024

p1 didn't install a new kernel just userland so freebsd-version doesn't report -p1. Run freebsd-version -kru (kernel, running kernel, userland).

bluray · Jun 23, 2024

derekschrock said:
p1 didn't install a new kernel just userland so freebsd-version doesn't report -p1. Run freebsd-version -kru (kernel, running kernel, userland).

oh I see, thank you very much ^__^

sorry for the stupid question

Charlie_ · Jun 23, 2024

Since it is not the /boot/kernel/kernel but /boot/kernel/zfs.ko that was changed by FreeBSD-EN-24:10.zfs.

Cath O'Deray · Jun 23, 2024

derekschrock said:
p1 didn't install a new kernel just userland so freebsd-version doesn't report -p1. …

Patch level 1 for kernel and userland:

Code:

Script started on Sun Jun 23 17:02:13 2024
grahamperrin@14-pkgbase:~ % freebsd-version -kru ; uname -aKU

14.1-RELEASE-p1
14.1-RELEASE-p1
14.1-RELEASE-p1
FreeBSD 14-pkgbase 14.1-RELEASE-p1 FreeBSD 14.1-RELEASE-p1 releng/14.1-n267682-0892dff10444 GENERIC amd64 1401000 1401000
grahamperrin@14-pkgbase:~ % pkg -vv | grep -B 1 url

  FreeBSD: {
    url             : "pkg+https://pkg.FreeBSD.org/FreeBSD:14:amd64/latest",
--
  FreeBSD-base: {
    url             : "pkg+https://pkg.freebsd.org/FreeBSD:14:amd64/base_release_1",
grahamperrin@14-pkgbase:~ % …

Cath O'Deray · Jun 23, 2024

bluray said:
… rebooted and all after using freebsd-update. …

It's necessary to reboot before a run of freebsd-update.

monwarez · Jun 24, 2024

Cath O'Deray said:

Patch level 1 for kernel and userland:

Code:

Script started on Sun Jun 23 17:02:13 2024
grahamperrin@14-pkgbase:~ % freebsd-version -kru ; uname -aKU

14.1-RELEASE-p1
14.1-RELEASE-p1
14.1-RELEASE-p1
FreeBSD 14-pkgbase 14.1-RELEASE-p1 FreeBSD 14.1-RELEASE-p1 releng/14.1-n267682-0892dff10444 GENERIC amd64 1401000 1401000
grahamperrin@14-pkgbase:~ % pkg -vv | grep -B 1 url

  FreeBSD: {
    url             : "pkg+https://pkg.FreeBSD.org/FreeBSD:14:amd64/latest",
--
  FreeBSD-base: {
    url             : "pkg+https://pkg.freebsd.org/FreeBSD:14:amd64/base_release_1",
grahamperrin@14-pkgbase:~ % …

Well, this is a pkgbase issue it will reinstall the kernel regardless of change.

Cath O'Deray · Jun 24, 2024

monwarez said:
a pkgbase issue

Thanks, bug reported.

T-Daemon · Jun 24, 2024

Cath O'Deray said:
Thanks, bug reported.

I don't think that's a bug

Not sure how freebsd-update(8) server has build the patched zfs.ko kernel module without building kernel, but patched RELEASE source code (manually or Git) requires recompiling the kernel, which generates a 14.1-RELEASE-p1 kernel version.

/usr/src/UPDATING

Code:

20240619:
        14.1-RELEASE-p1 EN-24:10.zfs
                        EN-24:13.libc++

        Fix kernel memory leak in ZFS [EN-24:10.zfs]

From the Errata Notice EN-24:10.zfs

Code:

2) To update your system via a source code patch:
...
c) Recompile your kernel as described in ...

As for pkgbase packages, the kernel package is delivered as a whole, including kernel modules, which means the kernel must be recompiled:

On a test system (releng/14.1), from /usr/obj/usr/src-14.1/repo/FreeBSD:14:amd64/14.1

Code:

 # tar tvf FreeBSD-kernel-generic-14.1.pkg     /boot/kernel/zfs.ko
-r--r--r--  0 root   wheel 5549816 Jun 10 09:56 /boot/kernel/zfs.ko

monwarez · Jun 24, 2024

The whole point of kernel module, is to not have to rebuild the kernel when it is a kernel module that need to be rebuilt.
So /boot/kernel/kernel should not change, while /boot/kernel/zfs.ko changed

Erichans · Jun 24, 2024

T-Daemon said:
I don't think that's a bug

Not sure how freebsd-udate server has build the patched zfs.ko kernel module without building kernel, but patched source code (manually or Git) requires recompiling the kernel, which generates a FreeBSD-14.1-p1 kernel version.

Didn't think that was a bug also.

Looks like zfs.ko is just like any other (kernel) module—not being the kernel itself—like say, speaker.ko or also /boot/modules/amdgpu.ko from graphics/drm-515-kmod that can be build/compiled seperately against the intended kernel. The following (Customizing the FreeBSD Kernel) confirms:

Building Kernel Modules
Drivers and functionality which will not be required in the main kernel configuration can still be provided in the form of loadable kernel modules.

By default, the set of supported kernel modules on a given platform are also compiled as part of buildkernel, but they can be compiled separately as well.

Such a change, as in zfs.ko, can be localised/limited in such a way that a minimum set of patched (binary) files as part of the complete patch-update is necessary. Side effect: kernel version number stays unchanged; some confusion may arise.

Isn't it the case that IF there's only a patch in userland and one decides to also (re)build the kernel that then the kernel version wil also get an updated patched number? (couldn't locate any reference to that but seem to remember this was mentioned on the forum).

Erichans · Jun 24, 2024

monwarez said:
The whole point of kernel module [...]

and that code in a individual kernel module (as opposed to being part of the kernel itself), can be loaded and unloaded independently.

Cath O'Deray · Jun 25, 2024

Thanks. I'll change the bug to Documentation. At least:

the book of FAQ omits the frequently asked question about mixed patch levels with freebsd-version on an OS that's correctly updated within the constraints of freebsd-update
wrongness in freebsd-version(1).

T-Daemon said:
… Not sure how …

There's an indirect/partial answer in the manual page for freebsd-version(1):

… freebsd-update(8), … does not update the kernel version unless the kernel itself was affected by the latest patch. …

Essentially: freebsd-version is a best effort utility.

T-Daemon said:
… package is delivered as a whole, including kernel modules, …

OK, with six kernel packages alone installed on an already updated system (currently named fourteenpointone):

Code:

root@fourteenpointone:~ # pkg iinfo FreeBSD
FreeBSD-kernel-generic-14.1p1
FreeBSD-kernel-generic-dbg-14.1p1
FreeBSD-kernel-generic-mmccam-14.1p1
FreeBSD-kernel-generic-mmccam-dbg-14.1p1
FreeBSD-kernel-minimal-14.1p1
FreeBSD-kernel-minimal-dbg-14.1p1
root@fourteenpointone:~ # pkg info --list FreeBSD-kernel-generic | wc -l
     870
root@fourteenpointone:~ # freebsd-version -kru ; uname -aKU
14.1-RELEASE-p1
14.1-RELEASE-p1
14.1-RELEASE-p1
FreeBSD fourteenpointone 14.1-RELEASE-p1 FreeBSD 14.1-RELEASE-p1 releng/14.1-n267682-0892dff10444 GENERIC amd64 1401000 1401000
root@fourteenpointone:~ #

The 869 files in the package for the GENERIC kernel:

kernel
linker.hints
867 modules.

Note to self: fourteenpointone, old 17" MacBook Pro, disposal.

Back to the other OS (currently named 14-pkgbase),

Code:

root@14-pkgbase:~ # uname -v

FreeBSD 14.1-RELEASE-p1 releng/14.1-n267682-0892dff10444 GENERIC
root@14-pkgbase:~ # strings /boot/kernel/kernel | grep 14\.1-

@(#)FreeBSD 14.1-RELEASE-p1 releng/14.1-n267682-0892dff10444 GENERIC
FreeBSD 14.1-RELEASE-p1 releng/14.1-n267682-0892dff10444 GENERIC
14.1-RELEASE-p1
root@14-pkgbase:~ # strings /boot/kernel/zfs.ko | grep 14\.1-

root@14-pkgbase:~ # pkg iinfo FreeBSD-kernel

FreeBSD-kernel-generic-14.1p1
FreeBSD-kernel-generic-dbg-14.1p1
FreeBSD-kernel-generic-mmccam-14.1p1
FreeBSD-kernel-generic-mmccam-dbg-14.1p1
FreeBSD-kernel-minimal-14.1p1
FreeBSD-kernel-minimal-dbg-14.1p1
root@14-pkgbase:~ #

three lines in kernel include the string 14.1-
no matching string in the zfs.ko part of the kernel package.

Note to self: 14-pkgbase, uuid="{d4006022-0d96-4427-82be-38d0e7886ce8}" name="14.1-RELEASE-p1 from FreeBSD-14.0-RELEASE-amd64-disc1, issue 12"

I guess that with pkgbase, the confusion around mixed patch levels will become less commonplace ?

T-Daemon · Jun 25, 2024

monwarez said:
The whole point of kernel module, is to not have to rebuild the kernel when it is a kernel module that need to be rebuilt.

Cath O'Deray said:
There's an indirect/partial answer in the manual page for freebsd-version(1):

Code:

… freebsd-update(8), … does not update the kernel version unless the kernel itself was affected by the latest patch. …

Those are all valid replies, what I meant saying

T-Daemon said:
Not sure how freebsd-update(8) server has build the patched zfs.ko kernel module without building kernel,

is, how are the freebsd-update building servers building a kernel module alone without building the kernel in a automated way. Searching in https://github.com/freebsd/freebsd-update-build doesn't return anything useful.

On a generic installed system, to update a kernel module alone, a user can go in the modules source directory, build and install. I can't imagine the same is done manually on the freebsd-update servers building the module, they must have a configuration for this.

make.conf(5) provides some MODULE variables, but I can't spot anything which excludes buildkernel, but includes a list of modules to build.

There is a buildworld kernel module variable

Code:

   BUILDING THE WORLD
    ...
    MODULES_WITH_WORLD
                   (bool) Set to build modules with the system instead of the
                   kernel.

but this will build all, not specific modules.

The other kernel MODULE variables are buildkernel variables:

Code:

   BUILDING THE KERNEL
     ...
     MODULES_OVERRIDE
                   (str) Set to a list of modules to build instead of all of
                   them.
    ...
     NO_MODULES    (bool) Set to not build modules with the kernel.
    ...
    WITHOUT_MODULES
                   (str) Set to a list of modules to exclude from the build.
                   This provides a somewhat easier way to exclude modules you
                   are certain you will never need than specifying
                   MODULES_OVERRIDE.  This is applied after MODULES_OVERRIDE.

T-Daemon · Jun 25, 2024

Erichans said:
Isn't it the case that IF there's only a patch in userland and one decides to also (re)build the kernel that then the kernel version wil also get an updated patched number? (couldn't locate any reference to that but seem to remember this was mentioned on the forum).

That's the case. The version and patch level are picked up by buildworld and buildkernel from sys/conf/newvers.sh .

Cath O'Deray · Aug 11, 2024

monwarez said:
The whole point of kernel module, is to not have to rebuild the kernel when it is a kernel module that need to be rebuilt.

Modularity is not solely for build purposes.

SYSINIT(9), for example:

… The startup linker sets for modules that are loaded together with the kernel by the boot loader are scanned during the SI_SUB_KLD subsystem initialization. These modules' initialization routines are sorted and merged into the kernel's list of startup routines and are executed during boot along with the kernel's initialization routines. Note that this has the effect that any initialization routines in a kernel module that are scheduled earlier than SI_SUB_KLD are not executed until after SI_SUB_KLD during boot. …

Solved 14.1-RELEASE doesn't upgrade to 14.1-RELEASE-p1

Attachments