Why kernel are still named 4.15.18-11-pve

[udo]

Hi,
yesterday I updated an cluster and today there are an new kernel available (enterprise repo).

The changelog shows important bugfixes, but the name ist still the same!
Today before update:

pveversion -v
proxmox-ve: 5.3-1 (running kernel: 4.15.18-11-pve)
pve-manager: 5.3-9 (running version: 5.3-9/ba817b29)
pve-kernel-4.15: 5.3-2
pve-kernel-4.15.18-11-pve: 4.15.18-33
pve-kernel-4.15.18-5-pve: 4.15.18-24
...

after update today:

pveversion -v
proxmox-ve: 5.3-1 (running kernel: 4.15.18-11-pve)
pve-manager: 5.3-11 (running version: 5.3-11/d4907f84)
pve-kernel-4.15: 5.3-2
pve-kernel-4.15.18-11-pve: 4.15.18-34
pve-kernel-4.15.18-5-pve: 4.15.18-24
...

So pveversion shows, that the actual kernel ist running, which isn't true!
I assume an reboot is nessesary but I see only with uname that the older version is running...

Looks not so nice for me.

Udo

 

[fabian]

Hi,
yesterday I updated an cluster and today there are an new kernel available (enterprise repo).

The changelog shows important bugfixes, but the name ist still the same!
Today before update:

pveversion -v
proxmox-ve: 5.3-1 (running kernel: 4.15.18-11-pve)
pve-manager: 5.3-9 (running version: 5.3-9/ba817b29)
pve-kernel-4.15: 5.3-2
pve-kernel-4.15.18-11-pve: 4.15.18-33
pve-kernel-4.15.18-5-pve: 4.15.18-24
...

after update today:

pveversion -v
proxmox-ve: 5.3-1 (running kernel: 4.15.18-11-pve)
pve-manager: 5.3-11 (running version: 5.3-11/d4907f84)
pve-kernel-4.15: 5.3-2
pve-kernel-4.15.18-11-pve: 4.15.18-34
pve-kernel-4.15.18-5-pve: 4.15.18-24
...

So pveversion shows, that the actual kernel ist running, which isn't true!
I assume an reboot is nessesary but I see only with uname that the older version is running...

Looks not so nice for me.

Udo

there are two kinds of kernel upgrades, those that break ABI and those that don't.

if the ABI is not compatible, the package name is different, and the kernel image and modules are installed in a different path so that old and new kernels/packages can be installed in parallel.
if the ABI is compatible, the kernel image and modules get overwritten (since new modules can be loaded on the old kernel) and just the package release (the last part of the debian package version) is bumped, just like for all other normal packages.

a reboot is recommended in both cases, as it is needed to get the full effect of the update. none of the above is specific to PVE - Debian does it the same (but kernel updates are so infrequent that they very often include an ABI bump).

we patched our kernel images a long while ago to include the package release in "uname -a"/"uname -v" output in order to allow users to easily tell whether the running kernel is in fact the latest - but that string is too long to include into pveversion by default:

$ uname -rv
4.15.18-11-pve #1 SMP PVE 4.15.18-34 (Mon, 25 Feb 2019 14:51:06 +0100)

 

[udo]

Hi Fabian,
thanks for the info.

Nevertheless my opinion is, if things different,they should named different too - especially with numbers - we have a lot of them, and can count to very high versions ;-)
But it's seems to be hip, to reuse the versions these days - Dell do the same with bios-numbers. Same name but different content.

Udo

 

[fabian]

Hi Fabian,
thanks for the info.

Nevertheless my opinion is, if things different,they should named different too - especially with numbers - we have a lot of them, and can count to very high versions ;-)
But it's seems to be hip, to reuse the versions these days - Dell do the same with bios-numbers. Same name but different content.

Udo

we don't reuse the version (each released package has a unique version!), we keep the ABI version identical if the ABI does not change (this is the same way shared library versioning in Unix/Linux is handled, see https://en.wikipedia.org/wiki/Soname ). especially for kernel packages which are quite big and don't get autoremoved, you don't want to generate a completely new set of packages for every release.