[RESOLVED] 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.

[joneall]

Well, I have finally done a fresh install of three (don't ask...) new systems on two different disks, partitions sda2, sdb2 and sdb3. If I use refind to boot one of these partitions, it never gets the latest system. If I use refind to choose an EFI file, there are three, with these results:

EFI/neon/grub.cfg    --> sdb3 latest system
EFI/ubuntu/grub.cfg --> hardware setup
EFI/debian/grub.cfg --> recover mode (immediately)
EFI/kde/grub.cfg      --> sda2 latest system with choice of sda5 (old, updated system)

The only ones with recent entries are

/boot/efi/EFI$ ll *
...
BOOT:
total 1868
-rwxr-xr-x 1 root root 966664 nov. 3 09:45 BOOTX64.EFI
-rwxr-xr-x 1 root root 88344 nov. 3 09:45 fbx64.efi
-rwxr-xr-x 1 root root 856280 nov. 3 09:45 mmx64.efi
...
​
​kde:
total 4376
-rwxr-xr-x 1 root root 132 nov. 3 09:45 BOOTX64.CSV
-rwxr-xr-x 1 root root 126 nov. 3 09:45 grub.cfg
-rwxr-xr-x 1 root root 2656136 nov. 3 09:45 grubx64.efi
-rwxr-xr-x 1 root root 856280 nov. 3 09:45 mmx64.efi
-rwxr-xr-x 1 root root 966664 nov. 3 09:45 shimx64.efi

As to booting an actual system, the grubs seem to not know about the ones on sdb, but refind does.

What is going on? Is there any way to re-initialize all that? Can I make grub do a complete re-write based on the current status of my partitions? Can it find systems on sdb partitions?

I know, too many questions.

[jlittle]

I don't understand the above, especially EFI/{neon,debian,kde}, but

W
As to booting an actual system, the grubs seem to not know about the ones on sdb

Unless you've changed /etc/default/grub to have the line

GRUB_DISABLE_OS_PROBER=false

a grub install will not look for other OSs on other drives. I suggest booting via one of the grubs, perhaps the one on sdb3, changing /etc/default/grub to have the line above (without a #), and running sudo update-grub there.

[claydoh]

the grubs seem to not know about the ones on sdb, but refind does.

You need to update grub on each OS install, after re-enabling the os-prober in each one as well, which is the bit used to detect other OS installs, since the grub folks consider it a security issue these days and have it turned off by default.

[joneall]

Thanks for your suggestions.

You need to update grub on each OS install

That sounds logical...

, after [re-enabling the os-prober in each one as well, which is the bit used to detect other OS installs, since the grub folks consider it a security issue these days and have it turned off by default.

When I did a dist-upgrade this morning (4 houra fwo), the output included this:

Warning: os-prober will be executed to detect other bootable partitions.
Its output will be used to detect bootable binaries on them and create new boot entries.
Found KDE neon User Edition (24.04) on /dev/sda2
Found KDE neon 6.2 (22.04) on /dev/sda5
Found KDE neon User Edition (24.04) on /dev/sdb3
Adding boot menu entry for UEFI Firmware Settings ...
done

Which grub.cfd is important here? It seems to have updated the ones in /boot/efi/EFI/BOOT and in /boot/efi/EFI/kde, but not in the others.

I just ran update-grub:

$ sudo update-grub
[sudo] password for jon:
Sourcing file `/etc/default/grub'
Sourcing file `/etc/default/grub.d/99_breeze-grub.cfg'
Generating grub configuration file ...
Found theme: /boot/grub/themes/breeze/theme.txt
Found linux image: /boot/vmlinuz-6.8.0-48-generic
Found initrd image: /boot/initrd.img-6.8.0-48-generic
Found linux image: /boot/vmlinuz-6.8.0-45-generic
Found initrd image: /boot/initrd.img-6.8.0-45-generic
Found memtest86+ 64bit EFI image: /boot/memtest86+x64.efi
Warning: os-prober will be executed to detect other bootable partitions.
Its output will be used to detect bootable binaries on them and create new boot entries.
Found KDE neon User Edition (24.04) on /dev/sda2
Found KDE neon 6.2 (22.04) on /dev/sda5
Found KDE neon User Edition (24.04) on /dev/sdb3
Adding boot menu entry for UEFI Firmware Settings ...
done

which seems to run os-prober even tho

$ grep DISABLE_OS /etc/default/grub
#GRUB_DISABLE_OS_PROBER=false

.

But the time stamps under /boot/EFI are not changed. What exactly is update-grub updating? Seems to me something should copy that into /boot/efi/EFI/kde or someplace similar where the boot process can find it.

[joneall]

But the time stamps under /boot/EFI are not changed. What exactly is update-grub updating?

That brings up a question. Where is grub writing its config files now? My notes from nine years ago (!) say it reads config info from /etc/default/grub. But the files in there are old. Somewhere, it wrote a file with the different systems it found and one could change GRUB_DEFAULT=n to pick the default system to boot, but I cannot find that anywhere any more.

Stop the presses, I have answered one question. Thanks to a grub 2 tutorial , I now know that grub uses info /etc/default/grub to update that in /etc/grub and then writes the actual grub.cfg in /boot/grub, where I find the on I wrote today.

It contains menuentry items for my systems on sda2, sda5 and sdb3, but for sdb2, the reference is by UUID.

So I have a good grub.cfg. But it does not seem to be making its way into /boot/efi/EFI/. What to do?

[joneall]

After finding all this, I ran update-grub and now all is well. One problem is that, when I reached a grub menu, I only saw 4 entries. You have to scroll down to see the others.

One way to get to it is through reFind, where it is listed as EFI/kde/grubx64.cfg