So a while ago, I did some software updates and to my notice, while installing, it threw some error messages. I thought it would be wise to have a note on what these messages were saying, and with an intent of copying the error message from the terminal I accidentally interrupted the update.
To my notice, i found that was a kernel update, and 6.15.4 was being install which I happened to interrupt, while I was working in 6.15.3. Now I panicked, I searched everywhere for measures to reduce the issues I may have created, however I found none, until I tried to hit a quick reboot.
To my surprise, there was a new kernel up there in the Grub menu, into which I booted naturally. It turned out to be broken and the system went in kernel panic. Of course, I panicked and didn’t think much before hitting a forced shutdown. When I thought about it, I realized the issue I was looking for might be here, inside the kernel. So, I researched about it, and I found that my interruption might have caused such behavior. Some initramfs which are basically the programs which boots the kernel might have gotten affected.
After that, I booted into the previous kernel, i.e 6.15.3 which was pretty functioning i supposed. After discussing more with LLM’s I found out that reinstalling the kernel would best course of action and then I proceeded with it, only to learn that this kernel version is nowhere to be found in dnf repositories. So, I removed the kernel off my disk, however it is still present in the Grub menu along with other kernels.
At this point, my mind has become a mess, so I need you guys to validate what I did was correct, and guide what to do next.
LLM’s should not be trusted until the results have been checked against disto documentation.
When in doubt, ask here.
Several recent topics here deal with failures attempting to boot a new kernel. If your problem is failure to create the initrd for the new kernel, those topic include instructions for creating initrd when booted to an older kernel, but they usually involve running dnf in a terminal session. If you are not familiar with command-line tools, you may want to have The Linux Command Line on hand (it was written by a human),
You may be better off just upgrading, which should provde the latest kernel. Some systems don’t support recent kernels, so you can install older kernel.
I did and I am glad they released a newer version 6.15.5, which is very stable i guess. The previous aka broken one is still in the grub menu and I would like to change that.
Thanks for the reference, I would surely check it out.
I discovered this community like 3-4 days ago and I am loving it already.
6.15.4 has been superceded by the 6.15.5 kernel and is no longer in the fedora updates repo. You may be able to reinstall it by using sudo dnf reinstall kernel*6.15.4* --enablerepo updates-archive
If you just do a new update it should install the newer kernel for you.
How did you remove that kernel?
Did you manually delete files (which can easily cause problems) or did you use either dnf or the package manager to remove it?
If you used dnf or the package manager then it should not show up in grub, but if you manually deleted files then it may still show in grub and will likely be very broken. Removing it completely and cleanly would involve a reinstall shown above then use dnf to remove it.
yes I used package manager dnf, yet it didn’t really remove it from the grub menu kernel list.
So, I did a little research and found /boot may contain some residue of 6.15.4 kernel which I may need to manually delete and then update grub.
the list of modules I deleted manually:
* config-6.15.4
* symvers-6.15.4
* System.map-6.15.4
* vmlinuz-6.15.4
Note that initramfs-6.15.4 was already missing by the time I was going to remove the above modules.
So, after allat
rpm -q kernel returns : list of kernels avaliable except the broken 6.15.4 and
upon running sudo grub2-mkconfig -o /boot/efi/EFI/fedora/grub.cfg it returned an error message and directed me to run the below command.
sudo grub2-mkconfig -o /boot/grub2/grub.cfg
to update grub list.
What are the contents of your /boot/loader/entries directory?
The grub.cfg file generated by grub2-mkconfig doesn’t directly include a list of kernels: instead it contains code that makes GRUB read the /boot/loader/entries directory at boot time to determine what entries to show you.
-rw-r--r--. 1 root root 492 Jul 12 03:20 934a49bb8ce042c388670c6bd36b949a-0-rescue.conf
-rw-r--r--. 1 root root 430 Jul 12 03:20 934a49bb8ce042c388670c6bd36b949a-6.15.3-200.fc42.x86_64.conf
-rw-r--r--. 1 root root 430 Jul 12 03:20 934a49bb8ce042c388670c6bd36b949a-6.15.4-200.fc42.x86_64.conf
-rw-r--r--. 1 root root 430 Jul 12 03:20 934a49bb8ce042c388670c6bd36b949a-6.15.5-200.fc42.x86_64.conf
Yeah it’s in the entries directory.
That makes sense! So if you delete that file from the entries directory then 6.15.4 should no longer appear in the GRUB menu.
But the question is should I remove it? I am not sure it won’t cause problems in my current workspace. Also such operations require me to start a root user session, I don’t know if I should leverage such high permissions and don’t worry about a consequence or two.
I actually removed one of these today (context). It had no negative effects.
Do you have sudo permissions on your user account? If so then sudo rm would work, no need for a root shell.
If you like, you could move the file into your home directory rather than deleting it, so that GRUB won’t see it but you could later restore it if you wanted to.
But if you prefer not to touch the file, you can just leave it where it is. The only “problem” is the cosmetic one that you’ll be left with an unusable entry in your GRUB menu.
This command has not been valid since about fedora 32.
If you are following guides that tell you to use that command they are at least 5 years out of date.
Yes.
If the kernel has been removed then something went wrong with the way dnf removed that kernel and it left that file there, along with the ones you found in /boot. The proper command to cleanly remove all packages for the 6.15.4 kernel should have been sudo dnf remove kernel*6.15.4* which would have removed everything related to that kernel. (it may still work if the command dnf list --installed kernel* shows any of the packages related to that kernel installed.)
Do you still have content in /usr/lib/modules or /usr/src/kernels or /usr/share/licenses/kernel-core or /usr/share/doc/kernel-keys that is related to the 6.15.4 kernel
An easy command to find out is find /usr -name *6.15.4* 2>/dev/null
As I mentioned earlier, the easiest way to cleanly remove a kernel that has been broken (as this one appears to be) would be to reinstall it from the updates-archive directory sudo dnf reinstall kernel*6.15.4* --enablerepo updates-archive followed by removing that kernel with the command I mentioned above.
yeah there are still some modules
/usr/lib/modules/6.15.4-200.fc42.x86_64
/usr/share/doc/kernel-keys/6.15.4-200.fc42.x86_64
/usr/share/licenses/kernel-core/COPYING-6.15.4-200.fc42
/usr/src/kernels/6.15.4-200.fc42.x86_64
okay then i would try to reinstall and attempt a clean remove.
this was actually ChatGPT, I didn’t really find such commands anywhere else, however I found similar commands for Ubuntu/Debian, so thought it was worth a shot
This is one of the reasons that users MUST be cautious when using an AI to solve problems. They must already know or be able to verify that the suggested solution is valid. In this case using the quoted command WILL break all future updates of kernels for the users system; That may not be recognized immediately and will require a recovery process that is not always intuitive.
Recovery requires removing some grub files and reinstalling a grub package.
AI’s often present outdated information, and are not good at determining whether a procedure is appropriate for a given current Linux distro.
As you found, it is often difficult to find current procedures to fix common problems. Asking this forum whether a procedure you found from external sources is valid for Fedora may help you avoid issues and also help others with similar issues find the right solution.
Actually, LLM-G.A.I.s are never the correct path because they WILL hallucinate solutions.
By posing the question in the correct way, the LLM will say ANYTHING and EVERYTHING you want it to say.
(Google’s LLM is an abominable amalgamation of the first 8 search results anyways…)
Yeah, I am well aware of that fact, and I actually never run any root level commands before verifying it through multiple resources. I will keep those things in mind, btw you said the command, it may break the future updates of kernels. Can you please elaborate?
That I wholeheartedly agree, interacting with the community is still the best way around, AI can only provide answers for most relevant queries, and those of which still might be outdated.
Note that I said WILL, not may.
When the change was made to use the file located at /boot/grub2/grub.cfg for both BIOS and UEFI based systems, the other file located at /boot/efi/EFI/fedora/grub.cfg was made into a static pointer to redirect grub to the other file.
While a user can manually change that file, as the command you posted would do, the system NEVER automatically changes it. Thus, once overwritten the pointer is gone and the file under /boot/efi remains static with content as-is.
Kernel updates modify the file under /boot/grub2 but never touch the one under /boot/efi which results in a static /boot/efi/EFI/fedora/grub.cfg which never sees the updated kernels. Grub looks at that file first and without the pointer never knows about the one at /boot/grub2/grub.cfg.
If the file /boot/efi/EFI/fedora/grub.cfg has been modified the only way I know to recover involves 2 steps.
- delete both grub.cfg files.
sudo rm /boot/grub2/grub.cfg /boot/efi/EFI/fedora/grub.cfg - followed by rebuilding both files.
sudo dnf reinstall grub2-common
After performing these 2 steps the system should be returned to normal automatic updates and booting after a kernel update
That command actually does the non-destructive thing of failing and directing the user to update the right file:
$ sudo grub2-mkconfig -o /boot/efi/EFI/fedora/grub.cfg
Running `grub2-mkconfig -o /boot/efi/EFI/fedora/grub.cfg' will overwrite the GRUB wrapper.
Please run `grub2-mkconfig -o /boot/grub2/grub.cfg' instead to update grub.cfg.
GRUB configuration file was not updated.
Yes same threw up for me, as I already mentioned earlier, so the file, wasn’t overwritten, was it?