Been having those weird issues lately after upgrades I guess. I didn’t do anything outside normal.
As stated in one of my post, this issue came back and was able to fix it yesterday, got another upgrade today and again the same issue where :
I tried to regenerate my initfsram and I got this error :
dracut[F]: Can't write to /boot/efi/ed3991a0a95240cfb5acb6779334be27/6.18.7-200.fc43.x86_64: Directory /boot/efi/ed3991a0a95240cfb5acb6779334be27/6.18.7-200.fc43.x86_64 does not exist or is not accessible.
Does anyone have any idea what is happening to my system?? Also the weird part is I don’t even have 6.18.7 available from the grub boot screen… I’m getting the feeling something has gone wrong with one of the updates..
These are the kernels I have on my system (got 6.18.7 with today’s update)
And if I try the dracut command I get denied the operation so.. really not sure what is going on. If anyone has any idea, please let me know what I could try.
I mean look at this 6.18.4 should not even be there according to rpm -qa kernel-core…. weird.
Please show the output shown by running sudo kernel-install. Also show the output from running rpm -qa 'kernel*'. And finally the output of sudp find /boot.
I myself am noticing that kernel 6.18.3 is still in the /boot and that option is not even available as a boot option from grub. Is there a command to clean that old stuff up or how can I remove those old kernels?
What I find strange is that in boot/loader/entries I have kernels 6.18.5, 6.18.3 and 6.18.7, while the kernel core listing shows 6.18.5, 6.18.6 and 6.18.7 which makes sense since it keeps the latest 3. Then my boot loading screen shows 4 entries, 6.18.7, 6.18.6, 6.18.5 and 6.18.4.. So the boot/loader/entries do not seem to match what I see.. How do I fix / regenerate this?
❯sudo dracut --kver=kernel-6.18.5-200.fc43.x86_64 --force realpath: /lib/modules/kernel-6.18.5-200.fc43.x86_64: No such file or directory dracut[F]: Cannot find module directory dracut[F]: and --no-kernel was not specified
Then I tried this and had issues as well..
❯sudo dracut --regenerate-all --force dracut[F]: Can't write to /boot/efi/ed3991a0a95240cfb5acb6779334be27/6.18.6-200.fc43.x86_64: Directory /boot/efi/ed3991a0a95240cfb5acb6779334be27/6.18.6-200.fc43.x86_64 does not exist or is not accessible.
/lib/modules🔒 ❯sudo dracut --kver=6.18.6-200.fc43.x86_64 --force dracut[F]: Can't write to /boot/efi/ed3991a0a95240cfb5acb6779334be27/6.18.6-200.fc43.x86_64: Directory /boot/efi/ed3991a0a95240cfb5acb6779334be27/6.18.6-200.fc43.x86_64 does not exist or is not accessible.
That id ‘ed3991a0a95240cfb5acb6779334be27’ folder is not there.. How did it figure out to go there? Why is that folder missing? This smells like a bug but not sure.
Last but not least… In my grub boot menu I still see kernel 6.18.4 even though that is nowhere to be found on my system..
So at this point I’m wondering what are my options as there seems to be some kind of mess in the boot loader and failure to regenerate some configs with DRACUT.. What can I do to fix this mess?
What I’m noticing is that the failure in regenerating kernel 6.18.6 actually seems to point to Fedora Linux o-rescue-ed3991a0a95240cfb5acb6779334be27 from my boot screen.. How can that be? Is my grub installation screwed up somehow?
Alright under boot I have the following : ❯sudo ls -la /boot total 616348 dr-xr-xr-x. 6 root root 4096 Jan 29 10:18 . dr-xr-xr-x. 1 root root 194 Jan 29 14:26 .. -rw-r--r--. 1 root root 294203 Jan 7 19:00 config-6.18.4-200.fc43.x86_64 -rw-r--r--. 1 root root 294203 Jan 10 19:00 config-6.18.5-200.fc43.x86_64 -rw-r--r--. 1 root root 294203 Jan 17 19:00 config-6.18.6-200.fc43.x86_64 -rw-r--r--. 1 root root 294417 Jan 22 19:00 config-6.18.7-200.fc43.x86_64 drwx------. 5 root root 4096 Dec 31 1969 efi drwx------. 3 root root 4096 Jan 29 14:27 grub2 -rw-------. 1 root root 173988204 Feb 9 2025 initramfs-0-rescue-ed3991a0a95240cfb5acb6779334be27.img -rw-------. 1 root root 80691204 Jan 28 19:00 initramfs-6.18.4-200.fc43.x86_64.img -rw-------. 1 root root 79887383 Jan 29 09:56 initramfs-6.18.5-200.fc43.x86_64.img -rw-------. 1 root root 79890966 Jan 29 09:56 initramfs-6.18.6-200.fc43.x86_64.img -rw-------. 1 root root 80755887 Jan 29 10:18 initramfs-6.18.7-200.fc43.x86_64.img drwxr-xr-x. 3 root root 4096 Feb 9 2025 loader drwx------. 2 root root 16384 Feb 9 2025 lost+found lrwxrwxrwx. 1 root root 46 Jan 12 11:25 symvers-6.18.4-200.fc43.x86_64.xz -> /lib/modules/6.18.4-200.fc43.x86_64/symvers.xz lrwxrwxrwx. 1 root root 46 Jan 15 12:47 symvers-6.18.5-200.fc43.x86_64.xz -> /lib/modules/6.18.5-200.fc43.x86_64/symvers.xz lrwxrwxrwx. 1 root root 46 Jan 26 08:29 symvers-6.18.6-200.fc43.x86_64.xz -> /lib/modules/6.18.6-200.fc43.x86_64/symvers.xz lrwxrwxrwx. 1 root root 46 Jan 29 10:18 symvers-6.18.7-200.fc43.x86_64.xz -> /lib/modules/6.18.7-200.fc43.x86_64/symvers.xz -rw-r--r--. 1 root root 11246030 Jan 7 19:00 System.map-6.18.4-200.fc43.x86_64 -rw-r--r--. 1 root root 11246129 Jan 10 19:00 System.map-6.18.5-200.fc43.x86_64 -rw-r--r--. 1 root root 11247275 Jan 17 19:00 System.map-6.18.6-200.fc43.x86_64 -rw-r--r--. 1 root root 11248579 Jan 22 19:00 System.map-6.18.7-200.fc43.x86_64 -rwxr-xr-x. 1 root root 16296296 Feb 9 2025 vmlinuz-0-rescue-ed3991a0a95240cfb5acb6779334be27 -rwxr-xr-x. 1 root root 18343976 Jan 7 19:00 vmlinuz-6.18.4-200.fc43.x86_64 -rw-r--r--. 1 root root 161 Jan 7 19:00 .vmlinuz-6.18.4-200.fc43.x86_64.hmac -rwxr-xr-x. 1 root root 18343976 Jan 10 19:00 vmlinuz-6.18.5-200.fc43.x86_64 -rw-r--r--. 1 root root 161 Jan 10 19:00 .vmlinuz-6.18.5-200.fc43.x86_64.hmac -rwxr-xr-x. 1 root root 18343976 Jan 17 19:00 vmlinuz-6.18.6-200.fc43.x86_64 -rw-r--r--. 1 root root 161 Jan 17 19:00 .vmlinuz-6.18.6-200.fc43.x86_64.hmac -rwxr-xr-x. 1 root root 18356264 Jan 22 19:00 vmlinuz-6.18.7-200.fc43.x86_64 -rw-r--r--. 1 root root 161 Jan 22 19:00 .vmlinuz-6.18.7-200.fc43.x86_64.hmac
and in /lib/modules I have :
❯sudo ls -la /lib/modules total 0 drwxr-xr-x. 1 root root 132 Jan 22 19:00 . dr-xr-xr-x. 1 root root 24274 Jan 29 09:44 .. drwxr-xr-x. 1 root root 772 Jan 15 12:47 6.18.5-200.fc43.x86_64 drwxr-xr-x. 1 root root 358 Jan 29 14:24 6.18.6-200.fc43.x86_64 drwxr-xr-x. 1 root root 716 Jan 29 10:18 6.18.7-200.fc43.x86_64
I What I can see is that I have under /boot, a lot of old configs that are no longer valid. I did some research and the command sudo grub2-mkconfig -o /boot/grub2/grub.cfg
should sort all the mess out but it doesn’t. Is there something else I should run to clean what shouldn’t be in there?
Update : I tried everything even reinstall 6.18.4 but that package is nowhere to be found.. Can I manually remove any reference to 6.18.4 from /boot or would that brick my system?
-rw-------. 1 root root 173988204 Feb 9 2025 initramfs-0-rescue-ed3991a0a95240cfb5acb6779334be27.img
-rw-------. 1 root root 80691204 Jan 28 19:00 initramfs-6.18.4-200.fc43.x86_64.img
-rw-------. 1 root root 79887383 Jan 29 09:56 initramfs-6.18.5-200.fc43.x86_64.img
-rw-------. 1 root root 79890966 Jan 29 09:56 initramfs-6.18.6-200.fc43.x86_64.img
-rw-------. 1 root root 80755887 Jan 29 10:18 initramfs-6.18.7-200.fc43.x86_64.img
I see that they are recreated on 29 January at 9:56 and 10:18. So the dracut must have been run successful. The one for 6.18.4-200.fc43.x86_64.img is old anyway so that is not important.
You are right I was able to fix it by reinstall 6.18.6, it was the only way to get it to run.. It was there but just reinstalling it fixed it and was able to run dracut.
6.18.4, that one I can’t even find or install it.. the problem is that executing
sudo grub2-mkconfig -o /boot/grub2/grub.cfg
wont remove 6.18.4 from my boot screen.. I have tried everything and it stays there and refuses to remove it from the /boot directory… Can I physcally erase it from there by
sudo rm /boot/anything 6.8.14 relatred and then recompile grub?
6.18.3 should not be there but 6.18.6 should be since it is in /lib/modules.
Just want to confirm one thing in case there is any doubt. I have not messed into this before. All this seemed to have happened through upgrades so there is definitely a bug with the upgrade process.
Yeah the picture shows something different because that was a picture taken after I removed 6.18.4, also been trying things out to try and fix this mess.
In the end I ended up doing this
sudo dnf4 remove --oldinstallonly
then I had to manually delete the old configs by end in /boot/loader/entries
sudo grub2-mkconfig -o /boot/grub2/grub.cfg
Now my boot menu shows
6.8.17
Rescue
Windows
Hopefully when the next kernel is released things will stay in order and not get messed up. Really not sure what happened that my menu would not get generated automatically executing sudo grub2-mkconfig -o /boot/grub2/grub.cfg and not sure why ghost kernels were left in there.
Hopefully this will be useful to someone else who has the same issues.
grub.cfg doesn’t contain an explicit list of your Fedora kernels to be included in the GRUB menu. Rather it contains the code which GRUB uses to build the menu at boot time from the contents of /boot/loader/entries.
So if you had a stray item in /boot/loader/entries, and the corresponding kernel didn’t disappear from the GRUB menu until that entry was removed, that’s why.
This should never be required if the kernels are removed properly. sudo dnf remove kernel\*<Version>\* will cleanly remove everything related to that kernel. So for example, to remove kernel 6.18.4 I would use sudo dnf remove kernel\*6.18.4\* and it would remove everything that was installed by that kernel.
Manually removing kernel files without using dnf to perform the removal can easily result in a user having stray files on the system. It also can mean that the rpm database may become out of sync with actually installed packages.
What is the result of running dnf list --installed kernel\* ?
If that shows anything but the 6.18.7 kernel packages (and the 6.18.3 header package) then cleanup will be required.
I also noted that your rescue kernel is from fedora 41. It probably should be updated, and that is easily done with sudo rm /boot/*rescue* and the next kernel update will replace it with the new kernel and release version.
This happened because you apparently removed part of the 6.18.4 files manually and the .conf file for the 6.18.4 kernel remained in /boot/loader/entries. A stray file left by manually removing part of the files and not using the package manager (dnf). The grub menu list of kernels is created by bls from the files located in /boot/loader/entries.
Lingering files of this sort is why it is always best to use dnf to manage kernels and to allow it to perform the installation of new kernels and removal of older kernels as it is designed to do.
The answer to your earlier question about the 6.18.3 package is that the package kernel-headers-6.18.3-200.fc43.x86_64 is a perfectly valid package even with the kernel version at 6.18.7. The headers do not get updated frequently so the older package often remains until a header update occurs.
Hey Jeff.. You seem very keen to place the blame on the person because you assume they themselves didn’t follow procedure and that it is impossible that perhaps there was a bug caused by the upgrade. Not sure if it is because you didn’t pay attention to what I said but I did say that in the end I had to remove things MANUALLY because doing the sudo dnf remove kernel*<Version>* procedure and all others that I found DID NOT WORK! I also did say that all these left overs like kernel 6.18.3 that 6.18.4 are things I noticed as I looked around further. It is only then that I confirmed with VILLY that I could remove the left overs from /boot/load/entries including those in /boot. Now if you want to continue believing that somehow I fucked up that is on you. I have never installed or removed a kernel before because I never had to.
Just a recommendation, before you make assumptions, ask first. Again to make sure you get it right this time, kernel updates only made it into my system via “dnf upgrade” and the issues I experienced and what I noticed I only saw them because I started noticing something weird things during boot time which I also reported in another post that someone else also experienced following an update
That is when I noticed 6.18.4 being in /boot but not in the /lib/modules and same for 6.18.3.
As for what I saw via dnf list --installed kernel* that was the exact content found in /lib/modules. 6.18.5, 6.18.6 and 6.18.7… I had to reinstall 6.18.6 because that was somehow NOT in /boot when it should have been.. And again I never tempered manually with those before.
Yeah I noticed that after looking further to understand how all this works. I’m not sure what happened. It was only by looking around that I noticed more unusual things such as 6.18.3 in /boot for example which should have been removed through updates.. I never touched that myself manually. Same thing with 6.18.4 that stayed behind but was somehow not removed from /boot/loader/entries.. Of 6.18.6 that was in /lib/modules but not in /boot. All I can say is that all of these updates were done through upgrades “dnf upgrade”, I never installed or remove a kernel manually, never had to.
I did a full review of this entire thread and you did say you removed kernels but nowhere did you reveal how the kernels were removed, whether manually or using the dnf package manager. The apparent leftover file in /boot/loader/entries for the 6.18.4 kernel (that had already been removed but was still showing up in the grub menu) led me to believe removal may not have been done with the package manager. We on this forum can only know the details that you share, and our suggestions are based on past experiences and information received (even if that information does not contain quite enough detail.)
I have seen several instances where users manually removed the kernel files in /boot and did not use the package manager to remove the kernels. This leaves the system believing those kernels may still be installed, it leaves left-over files in /boot/loader/entries (which still show up on the grub menu) as well as in /usr/lib/module. When this happens there seem times where the package manager cannot perform removals properly because of missing files when it attempts to remove them so it sometimes fails even when success is indicated.
There have been cases where reinstalling a kernel version was necessary before it could be cleanly removed.
