I do not understand vmlinuz

[joneall]

I think vmlinuz.... is a compressed kernel, right? I habitually run two Neon systems on different partitions, with my personal files on a single partition linked into /home/me. For some reason, they are out of sync.

$ ll /boot/vm*
lrwxrwxrwx 1 root root 24 sept. 20 08:25 /boot/vmlinuz -> vmlinuz-6.8.0-45-generic
-rw------- 1 root root 11700328 août 29 14:47 /boot/vmlinuz-5.15.0-122-generic
-rw------- 1 root root 14928264 juil. 30 17:17 /boot/vmlinuz-6.8.0-40-generic
-rw------- 1 root root 14911880 sept. 11 15:59 /boot/vmlinuz-6.8.0-45-generic
lrwxrwxrwx 1 root root 26 sept. 20 08:25 /boot/vmlinuz.old -> vmlinuz-5.15.0-122-generic
jon@jon-desktop:~$ sudo mount /dev/sda2 mnt-temp/
jon@jon-desktop:~$ ll mnt-temp/boot/vm*
lrwxrwxrwx 1 root root 26 sept. 17 08:03 mnt-temp/boot/vmlinuz -> vmlinuz-5.15.0-122-generic
-rw------- 1 root root 11704712 août 2 16:43 mnt-temp/boot/vmlinuz-5.15.0-119-generic
-rw------- 1 root root 11699080 août 9 10:16 mnt-temp/boot/vmlinuz-5.15.0-121-generic
-rw------- 1 root root 11700328 août 29 14:47 mnt-temp/boot/vmlinuz-5.15.0-122-generic
-rw------- 1 root root 14928264 juil. 30 17:17 mnt-temp/boot/vmlinuz-6.8.0-40-generic
lrwxrwxrwx 1 root root 26 sept. 17 08:03 mnt-temp/boot/vmlinuz.old -> vmlinuz-5.15.0-121-generic
$ uname -a
Linux jon-desktop 6.8.0-45-generic #45~22.04.1-Ubuntu SMP PREEMPT_DYNAMIC Wed Sep 11 15:25:05 UTC 2 x86_64 x86_64 x86_64
GNU/Linux

I had done an apt-get dist-upgrade just before on both systems and neither had wanted to install anything. Both systems seem to work just fine, although both have bluetooth problems.
Both are maintained by apt-get and have been for years.

[Snowhog]

VERY old page, but: https://www.linfo.org/vmlinuz.html

You have two Neons on separate partitions. What the above tells me is that one hasn't yet been upgraded to the newer kernel, or, you are still booting into the older (5.15.0-122) one on that partition.

[joneall]

VERY old page, but: https://www.linfo.org/vmlinuz.html

Yes, very old, and I knew that much. Thanks anyway.

You have two Neons on separate partitions. What the above tells me is that one hasn't yet been upgraded to the newer kernel, or, you are still booting into the older (5.15.0-122) one on that partition.

No, I keep both up to date and log in to each in alternance every 3-4 days. I do a dist-upgrade in each as soon as I boot and log in. So I have no idea when they got out of sync,

I logged in to both today and did a dist-upgrade. The result is what you see. They just are not in sync. But both are supposedly the same system. If both are Neon and both upgraded yesterday, why is that so?

[oshunluvr]

Personally, I think your systems could use a little clean up. If you're not booting to the 5 series kernels, remove them.

As far as "out of sync" goes, the second system still has 5.15.0-122 set as the current kernel and -121 as the old kernel. I suspect if you remove all the 5 series kernels, reboot to the 6.8.0-40 kernel, you'll get the 6.8.0-45 kernel offered in the upgrade - like your first system did on Sept. 11.

[jlittle]

lrwxrwxrwx 1 root root 26 sept. 17 08:03 mnt-temp/boot/vmlinuz -> vmlinuz-5.15.0-122-generic
-rw------- 1 root root 14928264 juil. 30 17:17 mnt-temp/boot/vmlinuz-6.8.0-40-generic

That is weird. vmlinuz is supposed to point to the latest kernel. Perhaps the APT upgrade was interrupted when it installed vmlinuz-6.8.0-40-generic, before updating the links, and, assuming grub is the bootloader, before updating grub.

You could reinstall the latest kernel, that is something like

 sudo apt reinstall linux-image-6.8.0-45-generic

I think that would rerun update-grub, but also redo other things that may have been not completed, not least building a new initrd.img. I'm not sure what other linux-*-6.8.0-45* packages it would be advisable to reinstall as well.

(IIUC the vmlinuz symlink is not used in a vanilla *buntu install; instead every time there's a new kernel update-grub is run so that the main entry in grub.cfg points to that new kernel. The vmlinuz symlink is for independent-minded misfits like me who don't want that error-prone update-grub machinery and use a simple, clean, static grub stanza to boot, for example, from a subvolume named @r on a btrfs labelled "main":

menuentry 'Kubuntu' {
    search --no-floppy --label --set=root main
    linux  /@r/boot/vmlinuz root=LABEL=main ro rootflags=subvol=@r
    initrd /@r/boot/initrd.img
}

Your problem looks to me like another error with the update grub set up that I avoid by maintaining grub.cfg myself.)

[joneall]

The vmlinuz symlink is for independent-minded misfits like me who don't want that error-prone update-grub machinery and use a simple, clean, static grub stanza to boot, for example, from a subvolume named @r on a btrfs labelled "main":

menuentry 'Kubuntu' {
search --no-floppy --label --set=root main
linux /@r/boot/vmlinuz root=LABEL=main ro rootflags=subvol=@r
initrd /@r/boot/initrd.img
}

Your problem looks to me like another error with the update grub set up that I avoid by maintaining grub.cfg myself.)

I am using reFind instead of grub. I admit to not understanding just how far that goes in analyzing grub files on the partitions.

I think that whenever the next major 3-year upgrade comes out, I'll do a clean install on a virgin partition.

[jlittle]

I am using reFind instead of grub.

I'm well outside my area of understanding, but IIUC rEFInd is not a boot-loader. It can use the "EFI stub loader", but that usually needs a kernel in the ESP. I suspect that your rEFInd uses grub for boot-loading, without showing a menu, and that /boot/grub/grub.cfg points to the 5 series kernel.