[SOLVED] Strange Grub behavior after new kernel installation

switching2Devuan · 2025-12-31 20:32:02

After updating my system (Chimaera 4.0) about 4-5 weeks ago, a new kernel was installed (Linux devuan 5.10.0-37-amd64).
I purged one of the previous kernels + headers (5.10.0-36) as I have always done, then I ran "sudo update-grub".

Contrary to the many kernel installations that had happened on my system during the previous 3,5 years, 5.10.0-37 would not show up on the grub boot screen.
Instead, the entry for its direct predecessor (5.10.0-36) was still there but could not boot for obvious reasons (having been purged before).
Nevertheless, 5.10.0-37 is present in grub.cfg.
Another "sudo update-grub" didn't change anything.
Apparently grub.cfg is properly updated but grub somehow does not display the changes on the boot screen.
At the moment, I have to manually select the remaining old kernel (5.10.0-35) to boot the system.

Now I wonder why grub is not using the correct information from grub.cfg and still displays some outdated configuration.

Has anyone ever encountered this before?

I appreciate any suggestions.

(I hope this topic is in the correct subforum. Otherwise please move it to a more proper location.)

Last edited by switching2Devuan (2025-12-31 20:33:20)

greenjeans · 2025-12-31 20:39:15

Arrgh, I think you may have the bug that's in that kernel though your behavior is different, this may be responsible for your other issues too.

There's another thread on here somewhere I think, I heard about the bug on IRC, some commit to that kernel version screwed up things.

Here: https://bugs.debian.org/cgi-bin/bugrepo … ug=1123750

Last edited by greenjeans (2025-12-31 20:43:32)

switching2Devuan · 2025-12-31 21:03:41

[Edit: I just checked the logs and saw that 5.10.0-37 had been installed only 2 weeks ago (on Dec. 16th).]

I wish it were just because of kernel 5.10.0-37 actively running on this system.
But I never got to the point to be able to boot it as it never showed up on the boot screen.
Since the installation of 5.10.0-37, I've been running 5.10.0-35 again.

And unfortunately, the issues that I described in my other thread started at least 2 weeks before the latest kernel update.

I still wonder, if the mere kernel installation might have lead to grub behaving in a weird way all of a sudden.

Last edited by switching2Devuan (2025-12-31 21:05:17)

RedGreen925 · 2025-12-31 23:50:00

Apparently grub.cfg is properly updated but grub somehow does not display the changes on the boot screen.

What makes you think that? Have you looked into the file and confirmed this? Also posting the output of the update-grub command would be helpful to be able to see what it does when it runs, mine for instance.

root@9600k:~# update-grub
Generating grub configuration file ...
Found theme: /usr/share/desktop-base/grub-themes/desktop-grub-theme/theme.txt
Found linux image: /boot/vmlinuz-6.12.57+deb13-amd64
Found initrd image: /boot/initrd.img-6.12.57+deb13-amd64
Found linux image: /boot/vmlinuz-6.12.48+deb13-amd64
Found initrd image: /boot/initrd.img-6.12.48+deb13-amd64
Warning: os-prober will not be executed to detect other bootable partitions.
Systems on them will not be added to the GRUB boot configuration.
Check GRUB_DISABLE_OS_PROBER documentation entry.
Adding boot menu entry for UEFI Firmware Settings ...
done

Edit: and now I think of it.

I purged one of the previous kernels + headers (5.10.0-36) as I have always done,

What is the matter with sudo apt autoremove which would have done it by removing the third oldest entry the -35 version leaving the last two version that were installed by apt, the method of doing it in/on a Debian based system. Adding the --purge option to that command is always a good idea to get rid of the leftover cruft it leaves behind without it used.

Last edited by RedGreen925 (2025-12-31 23:57:45)

switching2Devuan · 2026-01-01 00:45:48

What makes you think that? Have you looked into the file and confirmed this?

Yes, I have. Otherwise I could not have known that kernel 5.10.0-37 was in the cfg-file.

Also posting the output of the update-grub command would be helpful...

Here you go:

sudo update-grub
[sudo] Passwort für mt: 
Generating grub configuration file ...
Found background image: splash.png
Found linux image: /boot/vmlinuz-5.10.0-37-amd64
Found initrd image: /boot/initrd.img-5.10.0-37-amd64
Found linux image: /boot/vmlinuz-5.10.0-35-amd64
Found initrd image: /boot/initrd.img-5.10.0-35-amd64
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 Windows 7 on /dev/sda1
Found Devuan GNU/Linux 5 (daedalus) on /dev/sda9
done

What is the matter with sudo apt autoremove which would have done it by removing the third oldest entry the -35 version leaving the last two version that were installed by apt..

It was my personal choice to purge the .36-version.
In fact I usually purge the oldest version which in this case would indeed have been the -35-kernel but for some reason I decided to purge -36.
I've always used aptitude on the command line for installing, upgrading, purging etc.
As far as I know, aptitude doesn't know "autoremove". But it has an "--purge-unused"-option (which I have never used so far.
If I want to completely get rid of a package, I use "sudo aptitude purge package" which does the trick for me.

Anyway, as you can in the output of update-grub, the -37-kernel is recognized and enterd into the grub.cfg file but grub still does not show it in the boot menu.
And I have no clue why that is, nor how to fix it.

RedGreen925 · 2026-01-01 03:45:46

Looks like you do a BIOS MBR boot method since it says nothing about adding the UEFI firmware entry. I would open up the grub.cfg and make certain the entries get created for both kernels. Then once confirmed sudo grub-install /dev/sda to have it do a new install.

switching2Devuan · 2026-01-01 10:46:18

Looks like you do a BIOS MBR...

That's correct.

Then once confirmed sudo grub-install /dev/sda to have it do a new install.

That did it.
In addition to kernel -35, the -37-version is now correctly listed in the boot menu.
Thanks a lot.

Still interesting how grub got so twisted that it would not enter a newly installed kernel after "grub-update" as it has always done.

Although the system is running with this new kernel, I already experienced what was described in the link to the bug report (2nd post; thanks to greenjeans). All virtual consoles are unusable (except for the first one).
So I might purge this kernel and solely rely on the -35-version.

Anyway....problem solved. Thanks again.

RedGreen925 · 2026-01-01 14:16:05

You are welcome good to read you got it sorted out. If you have not cleaned your apt cache you should be able to install the -36 version of the kernel still in there and get rid of the junk buggy -37. As to why GRUB did it no clue for the longest time I always thought it was steaming pile of dung. Since I got it figured out using the EFI booting my opinion has improved a little from that but not by much. It has to be well north of a decade since I have used an MBR machine but I always remembered having to do re-installs with it. Oh before I forget to mention it the location to find the old kernel is /var/cache/apt/archives/ if you did not know. Now it can be there or not is depending on whether the system is set up to keep the files or if you have cleaned the cache manually.

switching2Devuan · 2026-01-01 16:58:38

If you have not cleaned your apt cache you should be able to install the -36 version of the kernel still in there

I clean it from time to time. Kernel -37 is still there but -36 is gone.
No big deal as I will stick to -35 until a newer kernel is available.

Last edited by switching2Devuan (2026-01-01 16:59:31)

The officially official Devuan Forum!

#1 2025-12-31 20:32:02

[SOLVED] Strange Grub behavior after new kernel installation

#2 2025-12-31 20:39:15

Re: [SOLVED] Strange Grub behavior after new kernel installation

#3 2025-12-31 21:03:41

Re: [SOLVED] Strange Grub behavior after new kernel installation

#4 2025-12-31 23:50:00

Re: [SOLVED] Strange Grub behavior after new kernel installation

#5 2026-01-01 00:45:48

Re: [SOLVED] Strange Grub behavior after new kernel installation

#6 2026-01-01 03:45:46

Re: [SOLVED] Strange Grub behavior after new kernel installation

#7 2026-01-01 10:46:18

Re: [SOLVED] Strange Grub behavior after new kernel installation

#8 2026-01-01 14:16:05

Re: [SOLVED] Strange Grub behavior after new kernel installation

#9 2026-01-01 16:58:38

Re: [SOLVED] Strange Grub behavior after new kernel installation

Board footer