On a dual boot system with two mint 19.3 systems, one with kernel 4.15 and one with kernel 5.4, upgrading kernel 5.4 results in introducing a reference to a kernel 4.15.0-121 in grub.cfg, which does not exist. Current kernel is 4.15.0-141
It is possible to get around the problem by manually correcting grub.cfg, a solution not recommanded, but if someone has a clue about the cause of this strange error, it may also help other users. Apparently, there is no reference to a kernel 121 in /boot/grub
upgrading kernel introduces error in grub.cfg
Forum rules
Before you post read how to get help. Topics in this forum are automatically closed 6 months after creation.
Before you post read how to get help. Topics in this forum are automatically closed 6 months after creation.
upgrading kernel introduces error in grub.cfg
Last edited by LockBot on Wed Dec 28, 2022 7:16 am, edited 1 time in total.
Reason: Topic automatically closed 6 months after creation. New replies are no longer allowed.
Reason: Topic automatically closed 6 months after creation. New replies are no longer allowed.
Re: upgrading kernel introduces error in grub.cfg
Hi,
One of your Linux's will have "lead Grub"..
For UEFI:
The Linux having "lead Grub".. It's the one that is pointed to by the initial 'grub.cfg' in /boot/efi/EFI/ubuntu/
This file points to the 'grub.cfg' of the "lead" system. You can check this by matching the UUID here with what is returned from 'blkid'.
For Legacy:
The first stage Grub bootloader has the relevant partition 'grub.cfg' location "hardcoded" into it.
For both, it's normally the last installed Linux that sets this. The use of 'grub-install' from the other system may alter this.
Running
Per system i.e. one at a time.
Look in '/boot' . You'll see here which kernels are physically installed here. Kernel files will be named similar to 'vmlinuz-5.11.13-051113-generic' etc.
Note that there will be a matching initrd (e.g. initrd.img-5.11.13-051113-generic) . Ignore the 'vmlinuz', 'vmlinuz.old', 'initrd.img' and 'initrd.img.old'.
This will show you what kernels are actually installed.
Now look at '/lib/modules'. You can safely delete any subdirectories here that don't match your installed kernels i.e. are different versions.
Now check /usr/src/ . Again look for header file directories that don't match your installed kernel versions. You can safely delete these.
Just look at the kernel version number.. ignore anything after this. e.g. for the installed kernel version 5.11.13, you would keep 'linux-headers-5.11.13-051113' and 'linux-headers-5.11.13-051113-generic'.
Now run
Repeat these actions after rebooting to your other Linux.
Bodge99
One of your Linux's will have "lead Grub"..
For UEFI:
The Linux having "lead Grub".. It's the one that is pointed to by the initial 'grub.cfg' in /boot/efi/EFI/ubuntu/
This file points to the 'grub.cfg' of the "lead" system. You can check this by matching the UUID here with what is returned from 'blkid'.
For Legacy:
The first stage Grub bootloader has the relevant partition 'grub.cfg' location "hardcoded" into it.
For both, it's normally the last installed Linux that sets this. The use of 'grub-install' from the other system may alter this.
Running
sudo update-grub
should identify any installed kernels per system. You may still have some remains from older kernel installations that may be causing your error.Per system i.e. one at a time.
Look in '/boot' . You'll see here which kernels are physically installed here. Kernel files will be named similar to 'vmlinuz-5.11.13-051113-generic' etc.
Note that there will be a matching initrd (e.g. initrd.img-5.11.13-051113-generic) . Ignore the 'vmlinuz', 'vmlinuz.old', 'initrd.img' and 'initrd.img.old'.
This will show you what kernels are actually installed.
Now look at '/lib/modules'. You can safely delete any subdirectories here that don't match your installed kernels i.e. are different versions.
Now check /usr/src/ . Again look for header file directories that don't match your installed kernel versions. You can safely delete these.
Just look at the kernel version number.. ignore anything after this. e.g. for the installed kernel version 5.11.13, you would keep 'linux-headers-5.11.13-051113' and 'linux-headers-5.11.13-051113-generic'.
Now run
sudo update-grub
. This will report which kernel versions are found as well as updating the local 'grub.cfg' in /boot/grub/'.Repeat these actions after rebooting to your other Linux.
Bodge99
Re: upgrading kernel introduces error in grub.cfg
well, I've checked both /lib/modules and /usr/src on both systems, then run update-grub on the system that hold the active EFI partition, and again obtained a reference to an old kernel 4.15.0-121 in grub.cfg for the mint19.3 system using kernel 4.15.
There are only two kernels for each system, the last two (140, 141 and 70, 71)
One question that may induce a problem is that I modified the entry name in grub.cfg as in :
menuentry "Linux Mint 19.3 Tricia sur sdb2 Kernel 4.15" --class linuxmint --class gnu-linux --class gnu --class os
and
menuentry "Mint19.3 sur sdb3 Kernel 5.3" --class ubuntu
in order to identify them and also to keep the entry name MINT instead of UBUNTU for the second one in the menu. It is a MINT system but after a kernel update it was renamed ubuntu...
Could that be the cause of the problem ?
There are only two kernels for each system, the last two (140, 141 and 70, 71)
One question that may induce a problem is that I modified the entry name in grub.cfg as in :
menuentry "Linux Mint 19.3 Tricia sur sdb2 Kernel 4.15" --class linuxmint --class gnu-linux --class gnu --class os
and
menuentry "Mint19.3 sur sdb3 Kernel 5.3" --class ubuntu
in order to identify them and also to keep the entry name MINT instead of UBUNTU for the second one in the menu. It is a MINT system but after a kernel update it was renamed ubuntu...
Could that be the cause of the problem ?
Re: upgrading kernel introduces error in grub.cfg
Hi,
Mint is derived from Ubuntu and uses the bootloader setup mechanism unaltered.
Your manual changes look like the cause of the problem.. The Grub tools are trying to help you here, by considering what is already existing..
You could try renaming the existing local 'grub.cfg' to something like 'grub.cfgOLD' and re-running 'update-grub'. This should stop any earlier names propagating.
You might need to rename the 'grub.cfg' from both systems, just to be sure. Be aware that the second system won't boot now, until you rename its local '/boot/grub/grub.cfgOLD' back to 'grub.cfg'.
This sort of problem is quite common and there is a way to eliminate it.
You can set up Grub in a slightly non standard way. For a UEFI system, you can install Grub to the EFI partition. A basic 'grub.cfg' here provides a simple boot menu. You select the required installation which passes control to the relevant 'grub.cfg'.
Here is a portion of my 'grub.cfg' which exists within my EFI partition. No Grub utils can alter this file, it's totally under my control.
I use this method on every computer here that has more than one OS on it.
You can do something similar on a Legacy system. Here, you would need a small separate '/preboot' partition. The first stage Grub bootloader points here.
A 'grub.cfg' here is used in a similar way as the EFI version is. Each entry here points to the relevant system 'grub.cfg'.
Apart from this, everything else is totally standard.
I haven't set up a Legacy system like this for some time.. I don't remember any problems...
Bodge99
Mint is derived from Ubuntu and uses the bootloader setup mechanism unaltered.
Your manual changes look like the cause of the problem.. The Grub tools are trying to help you here, by considering what is already existing..
You could try renaming the existing local 'grub.cfg' to something like 'grub.cfgOLD' and re-running 'update-grub'. This should stop any earlier names propagating.
You might need to rename the 'grub.cfg' from both systems, just to be sure. Be aware that the second system won't boot now, until you rename its local '/boot/grub/grub.cfgOLD' back to 'grub.cfg'.
This sort of problem is quite common and there is a way to eliminate it.
You can set up Grub in a slightly non standard way. For a UEFI system, you can install Grub to the EFI partition. A basic 'grub.cfg' here provides a simple boot menu. You select the required installation which passes control to the relevant 'grub.cfg'.
Here is a portion of my 'grub.cfg' which exists within my EFI partition. No Grub utils can alter this file, it's totally under my control.
I use this method on every computer here that has more than one OS on it.
Code: Select all
menuentry "Mint 20.1" {
search --set=root --fs-uuid f9a15e14-ffdf-4221-9fee-06b4e5564bc9
set prefix=($root)/boot/grub
configfile $prefix/grub.cfg
}
menuentry "Devuan"{
search --set=root --fs-uuid 2bbad497-b1f9-4614-9a21-c53104d24986
set prefix=($root)/boot/grub
configfile $prefix/grub.cfg
}
menuentry "Mint Cinnamon install-Extracted ISO"{
search --set=root --fs-uuid 2ef6f6af-70b2-4031-b584-60446939c97f
set prefix=($root)/boot/grub
configfile $prefix/grub.cfg
}
menuentry "Artix" {
search --set=root --fs-uuid c6c46625-b726-4656-bbba-cf85c35add35
set prefix=($root)/boot/grub
configfile $prefix/grub.cfg
}
A 'grub.cfg' here is used in a similar way as the EFI version is. Each entry here points to the relevant system 'grub.cfg'.
Apart from this, everything else is totally standard.
I haven't set up a Legacy system like this for some time.. I don't remember any problems...
Bodge99
Re: upgrading kernel introduces error in grub.cfg
well, some progress in the understanding of this question.
First, there are problems that were generated by me, some two years ago, by generating entries in
/etc/grub.d/proxifieldScripts/custom
and there I have the reference to the old kernel 121.
But suppressing that, update-grub no longer finds the last kernels in the other systems in the computer. The correction introduced at the time did work, but requires periodic modifications when installing new kernels.
This is not satisfying, there should be a more robust way to edit the grub.cfg file when installing new kernels, by running update-grub in the EFI activated boot partition.
grub is a very nice piece of code, but still quite tricky to use.
First, there are problems that were generated by me, some two years ago, by generating entries in
/etc/grub.d/proxifieldScripts/custom
and there I have the reference to the old kernel 121.
But suppressing that, update-grub no longer finds the last kernels in the other systems in the computer. The correction introduced at the time did work, but requires periodic modifications when installing new kernels.
This is not satisfying, there should be a more robust way to edit the grub.cfg file when installing new kernels, by running update-grub in the EFI activated boot partition.
grub is a very nice piece of code, but still quite tricky to use.
Re: upgrading kernel introduces error in grub.cfg
Hi,
If things get too bad, you could purge grub, check each system for anything remaining (e.g. anything in '/usr/share/grub' etc.) and then reinstall.
Bodge99
If things get too bad, you could purge grub, check each system for anything remaining (e.g. anything in '/usr/share/grub' etc.) and then reinstall.
Bodge99
Re: upgrading kernel introduces error in grub.cfg
Thanks for your help .
Looking for tips on the internet, I get that grub2 is not as efficient as grub1 in tracking other linux systems on a linux only machine with several systems.
Hence the solution you propose seems most interesting : the EFI grub.cfg would invoke the /boot/grub/grub.cfg of each system pointing to the last installed kernel, and there seem to be a way to avoid these /boot/grub/grub.cfg to include systems in other partitions.
I'm going to test that and I'll report on the results later.
Another solution might be REFIND, I remenber trying that in the past, don't remenber exactly why I didn't keep it (I think it would point to every possible EFI loaders, while a number are not usable, and I did not find the way to filter out the unwanted entries)
Looking for tips on the internet, I get that grub2 is not as efficient as grub1 in tracking other linux systems on a linux only machine with several systems.
Hence the solution you propose seems most interesting : the EFI grub.cfg would invoke the /boot/grub/grub.cfg of each system pointing to the last installed kernel, and there seem to be a way to avoid these /boot/grub/grub.cfg to include systems in other partitions.
I'm going to test that and I'll report on the results later.
Another solution might be REFIND, I remenber trying that in the past, don't remenber exactly why I didn't keep it (I think it would point to every possible EFI loaders, while a number are not usable, and I did not find the way to filter out the unwanted entries)
Re: upgrading kernel introduces error in grub.cfg
Hi,
Have a look at viewtopic.php?f=42&t=346090
This will allow you to test the EFI boot from something like a flashdrive before you alter your EFI partition contents.
If you have any questions regarding this one, then just post here..
Bodge99
Have a look at viewtopic.php?f=42&t=346090
This will allow you to test the EFI boot from something like a flashdrive before you alter your EFI partition contents.
If you have any questions regarding this one, then just post here..
Bodge99