Hi,
I’ve currently have fedora 38 on my machine with dual boot (also windows). Everytime I’m updating the kernel my boot is stuck at loading kernel and I always need to restore/reinstall grub and then everything works.
https://fedoraproject.org/wiki/GRUB_2#Reinstalling_GRUB
Is there a better solution to this? A solution where I don’t need to repeat this reinstalling.
Thank you!
Sorry to hear about those troubles.
It is helpful for us to know exactly and in detail what happens when this occurs.
Please post the output of
[ -d /sys/firmware/efi ] && echo UEFI || echo BIOS
and
dnf list installed grub*
Also please run sudo dnf upgrade --refresh and let us know the result.
One thing I have noticed is that many tend to be impatient in rebooting after a kernel upgrade. Doing a quick reboot may interrupt normal processes that configure the kernel and modules needed for booting then cause problems in booting. Waiting a few minutes after the upgrade completes before rebooting often avoids such problems.
Hi sorry for late reply.
UEFi
Installed Packages
grub-customizer.x86_64 5.2.3-1.fc38 @updates
grub2-common.noarch 1:2.06-95.fc38 @updates
grub2-efi-ia32.x86_64 1:2.06-95.fc38 @updates
grub2-efi-ia32-cdboot.x86_64 1:2.06-95.fc38 @updates
grub2-efi-x64.x86_64 1:2.06-95.fc38 @updates
grub2-efi-x64-cdboot.x86_64 1:2.06-95.fc38 @updates
grub2-pc.x86_64 1:2.06-95.fc38 @updates
grub2-pc-modules.noarch 1:2.06-95.fc38 @updates
grub2-tools.x86_64 1:2.06-95.fc38 @updates
grub2-tools-efi.x86_64 1:2.06-95.fc38 @updates
grub2-tools-extra.x86_64 1:2.06-95.fc38 @updates
grub2-tools-minimal.x86_64 1:2.06-95.fc38 @updates
grubby.x86_64 8.40-69.fc38 @fedora
and for sudo dnf upgrade --refresh: Dependencies resolved.
Nothing to do.
Complete! (Everything seems alright)
The problem did not get’s only fixed after reinstsalling grub
You do seem to have grub-customizer installed where I do not.
When did the problem start? What changes may have been made just before it started? Is it possible that the problem began after installing the grub-customizer package? Note that grub on fedora (every default system installed package) begins with grub2- and grub-customizer is not the same.
To test if that package may be the cause, try backing out any changes made with the customizer then remove the package itself sudo dnf remove grub-customizer.
Finally run the three steps from the link you provided in post #1
Remove the following files:
# rm /boot/efi/EFI/fedora/grub.cfg
# rm /boot/grub2/grub.cfg
Reinstall the following packages:
# dnf reinstall shim-* grub2-efi-* grub2-common
followed by a new boot and see if it still has the same issue.
This issue should not occur if fedora is properly installed and one does not make additional changes to grub.
it does not seem to be a good solution … because grub-customizer should in theory not create any problems to the other packages… I’ve already used the instructions within reinstalling grub … but the problem is I need to perform this every time there is a kernel update on the fedora distribution.
Can you show the contents of /etc/default/grub?
In theory that is correct. In practice it may not be quite so simple.
My suggestion was simply for testing by removing known alterations to what grub does.
It actually sounds like something is interfering with the normal grub updates done when a new kernel is installed, and reverting to a clean baseline environment at that point seems the best point to start.
@vekruse asked for the content of /etc/default/grub and I would suggest that it may be useful to add the content of /boot/efi/EFI/fedora/grub.cfg as well.
As for the grub-customizer, until recently it would update the wrong grub.cfg, namely the one in the ESP. So if the old version has ever been used it might have damaged the grub configuration. For details see https://bugzilla.redhat.com/show_bug.cgi?id=2174582.
Then again, there is not much custumization that can be done, especially with the BLS configuration, the grub.cfg file will never be modified by a kernel update. Only a new BLS file is created and the oldest one removed. The old way of modifying the grub.cfg using the original grubby-deprecated program is no longer supported.
That is exactly why I asked for the content of the grub.cfg in the ESP.
I suspected that problem since @chalapai states they must repeat the installation step with every kernel update.
If that is the case then removing the currently installed grub-customizer should enable the system to function normally and not overwrite that file in the future.
so the contents fro /etc/default/grub are:
GRUB_TIMEOUT="5"
GRUB_DISTRIBUTOR="$(sed 's, release .*$,,g' /etc/system-release)"
GRUB_DEFAULT="saved"
GRUB_DISABLE_SUBMENU="true"
GRUB_TERMINAL_OUTPUT="console"
GRUB_CMDLINE_LINUX="rhgb quiet"
GRUB_DISABLE_RECOVERY="true"
GRUB_ENABLE_BLSCFG="false"
and for /boot/efi/EFI/fedora/grub.cfg
search --no-floppy --fs-uuid --set=dev eXXXXX-XXXX-XXXX-XXXX-XXXXXXXXX
set prefix=($dev)/grub2
export $prefix
configfile $prefix/grub.cfg
Is that after doing the grub reinstall or after doing a kernel update before doing the grub fix.
Those look like what I would expect on a normal system that has no problems.
That means that you do no longer get grub configuration updated when updating the kernel. That was in earlier releases done by grubby-deprecated, which is not provided anymore.
Unfurtunately, you still see tutorials which recommends to disable BLS.
so if i change it to true than everything is solved or?
it was before doing the grub fix
Not quite.
First check if the BLS files has been created as I suspect they would be. The files are
/boot/loader/entries/b4146134cc534b2bb35b75e467b91eb4-6.4.4-200.fc38.x86_64.conf
/boot/loader/entries/b4146134cc534b2bb35b75e467b91eb4-6.4.6-200.fc38.x86_64.conf
/boot/loader/entries/b4146134cc534b2bb35b75e467b91eb4-6.4.7-200.fc38.x86_64.conf
Then you can run grub2-mkconfig -o /boot/grub2/grub.cfg to fix the configuration files.
If your BLS files doesn’t exist yet, you should then reinstall the latest kernel, and check that the BLS file for the latest kernel now exists.
As a double check
[root@newbox ~]# grubby --info=ALL
index=0
kernel="/boot/vmlinuz-6.4.7-200.fc38.x86_64"
args="ro rhgb quiet video=1280x720"
root="UUID=56a83e29-1e98-44f6-a33e-8988906ef2a1"
initrd="/boot/initramfs-6.4.7-200.fc38.x86_64.img"
title="Fedora Linux (6.4.7-200.fc38.x86_64) 38 (Xfce)"
id="b4146134cc534b2bb35b75e467b91eb4-6.4.7-200.fc38.x86_64"
index=1
kernel="/boot/vmlinuz-6.4.6-200.fc38.x86_64"
args="ro rhgb quiet video=1280x720"
root="UUID=56a83e29-1e98-44f6-a33e-8988906ef2a1"
initrd="/boot/initramfs-6.4.6-200.fc38.x86_64.img"
title="Fedora Linux (6.4.6-200.fc38.x86_64) 38 (Xfce)"
id="b4146134cc534b2bb35b75e467b91eb4-6.4.6-200.fc38.x86_64"
index=2
kernel="/boot/vmlinuz-6.4.4-200.fc38.x86_64"
args="ro rhgb quiet video=1280x720"
root="UUID=56a83e29-1e98-44f6-a33e-8988906ef2a1"
initrd="/boot/initramfs-6.4.4-200.fc38.x86_64.img"
title="Fedora Linux (6.4.4-200.fc38.x86_64) 38 (Xfce)"
id="b4146134cc534b2bb35b75e467b91eb4-6.4.4-200.fc38.x86_64"
[root@newbox ~]#
Thx for the comprehensive reply! After doing another kernel update … I runned the command grub2-mkconfig -o /boot/grub2/grub.cfg and I did not get any stuck at loading kernel. I hope in the next kernel update I won’t need to perform this command again. Then I can test this definetly! Hope it works