Solved Poudriere Jail Base System is 14.2-RELEASE-p2, but Hosts Base System is 14.2-RELEASE-p1 after updating

SDK Chan

SDK Chan

After going through SAS, and ENS, I decided to update my poudriere jails base system, and my hosts base system.
For updating poudriere I issued as root the following command: poudriere jail -u -j my-jail-name.
After updating I verified the jail version with this command, again issued as root: poudriere jail -i -j my-jail-name.
Poudriere shows the most up to date patch level.

After reading Chapter 26. Updating and Upgrading FreeBSD, I managed to update my system.
For updating I issued the following commands as root:
Code: 
freebsd-update fetch
freebsd-update install
and rebooted since kernel files where updated.
Veryfing that my system is indeed patched, I issued as my user the command uname -a and noticed that my patch level is still p1.

Do I need to update again ?
EDIT: I tried to update again, but this time I got the output "No updates needed to update system to 14.2-RELEASE-p2.".
I am a little bit confused.
Does not the second patch level has new security fixes, too ?

Another thing I noticed now then issuing the command zfs list there is a new dataset attached to my zroot zpool and mounted at /, although I have already a dataset mounted at /.
1) Default dataset mounted at root: zroot/ROOT/default 7.31G 851G 7.24G /
2) New dataset mounted alongside the old one: originz/ROOT/14.2-RELEASE_2025-02-25_114420 8K 851G 7.23G /

My question here is why do I need both if the 1st zroot/ROOT/default dataset already suffice ?
 
I get the following output on my FreeBSD machine:
Code: 
[joy] ~ $ uname -a
FreeBSD joy.marcoen.net 14.2-RELEASE-p1 FreeBSD 14.2-RELEASE-p1 GENERIC amd64
[joy] ~ $ freebsd-version -kru
14.2-RELEASE-p1
14.2-RELEASE-p1
14.2-RELEASE-p2
The latter commands prints the version of the installed kernel, the running kernel, and the userland. Apparently the kernel version did not bump up to the same patch level as the userland. I have seen this before so to me it is normal. But I do not know the details behind it.
 
LillieNB said:
Another thing I noticed now then issuing the command zfs list there is a new dataset attached to my zroot zpool and mounted at /, although I have already a dataset mounted at /.
1) Default dataset mounted at root: zroot/ROOT/default 7.31G 851G 7.24G /
2) New dataset mounted alongside the old one: originz/ROOT/14.2-RELEASE_2025-02-25_114420 8K 851G 7.23G /

My question here is why do I need both if the 1st zroot/ROOT/default dataset already suffice ?
Click to expand...
freebsd-update(8) takes a snapshot of your current boot environment dataset (before update) and this is for rolling back to the state before the update. You can delete created snapshot if you have no issues after update.

Not every patch updates kernel and/or userland. So this may be expected, I had encountered this in the past too after running neofetch.

freebsd-version(1)

Code: 
     -k          Print the version and patch level of the installed kernel.
                 Unlike uname(1), if a new kernel has been installed but the
                 system has not yet rebooted, freebsd-version will print the
                 version and patch level of the new kernel.

     -r          Print the version and patch level of the running kernel.
                 Unlike uname(1), this is unaffected by environment variables.

     -u          Print the version and patch level of the installed userland.
                 These are hardcoded into freebsd-version during the build.
 
I see.
I have deleted the dataset used for the boot environment backup.
For example, I have now 2 kernels.
The new GENERIC one, and kernel old.
If I update (not upgrade) again to a new patch level (if one gets available), will the current GENERIC kernel become kernel old, and a new kernel version will be the GENERIC one ?
Or is it like in Linux where you get each kernel version installed, stored on the drive ?
 
LillieNB said:
For example, I have now 2 kernels.
The new GENERIC one, and kernel old.
If I update (not upgrade) again to a new patch level (if one gets available), will the current GENERIC kernel become kernel old, and a new kernel version will be the GENERIC one ?
Click to expand...
Yes, exactly. Old kernels will have .old suffix.

LillieNB said:
Or is it like in Linux where you get each kernel version installed, stored on the drive ?
Click to expand...
They are stored on /boot partition and you can boot each kernel.
 
nxjoseph said:
Yes, exactly. Old kernels will have .old suffix.


They are stored on /boot partition and you can boot each kernel.
Click to expand...
Ok.
Everything runs smooth, and I want to delete this kernel.old directory.
Does a rm -r suffice so that only the new kernel can be seen and booted while being in the boot screen ?
Or is there a special command for that like it is the case with poudriere jail where you have to specify the -d parameter to delete the jail.
I once did the stupid mistake to delete a poudriere jail with rm -r and the outcome was anything else, but not pleasant thats why I am wondering if files regarding the kernel should be deleted with a special command.

It seems to be safe just to delete the kernel.old directory with rm -r according to this thread.
 
You must log in or register to reply here.
Back
Top