I am running an up-to-date F38 workstation and overall I am quite happy with it. The system originally started out in 2016 as F24 or F25. I have moved the system with all disks to newer hardware in the meantime. Now I also want to update the old rescue kernel - in case I ever need it, I want it to be recent.
However, the documentation for Fedora updates, section Update rescue kernel mentions that having dracut-config-rescue installed should automatically update the rescue kernel on kernel updates. On my machine, that did not work: Even though I had that package installed, it has not been updated since 2015 (!)
The problem is that that documentation section neglects to mention that you need to delete your current rescue kernel from /boot prior to doing the kernel update. You can see this for yourself by looking at the shell script pointed out in that same section of the document, /usr/lib/kernel/install.d/51-dracut-rescue.install. That is, unless I’m reading that script incorrectly myself!
Yes.
As noted by @jrredho there is a requirement to remove the old rescue images (both initramfs and vmlinuz) before the system will build a new rescue image.
This seems intended to ensure the rescue kernel is not accidentally removed, but the drawback is that it does require the user to take action to ensure the kernel rescue image remains current and does not become obsolete (a 2015 kernel probably would not boot a 2024 fedora system [though it might]).
Personally, I think that it’s safest to use the method @vgaetera described earlier, which is also given in that same section of the documentation we’re talking about. It seem to me that it’s a bit risky to delete your rescue kernels on a kernel update as you don’t know if it’ll be a problem for your system or not.
Yeah, that would be nice. I read it more like If you have this package installed, it will automatically keep your rescue kernel updated, which is wrong as I learned from the clarifying comments above.
(And I wondered whether that would make sense at all, because you probably do not want to have the latest kernel as rescue kernel, but maybe kernel n-1, i.e. the previous one – just in case something is broken in the latest kernel…)
The way I view it is that if the user has a known good kernel, and fairly recent, they could choose to
remove the rescue images
reinstall the kernel group for the kernel they wish to have for the rescue image
done
To me this seems the best way to have a known good and fairly recent kernel for the rescue image and it does not risk the potential of a newly installed kernel being faulty for booting (which could, as noted, result in a defective rescue kernel).
Maybe provide a script the user could use to replace the rescue image once they are certain the new kernel is acceptable?
The problem is that it’s really complicated. There is no guarantee that the (n-1)st kernel isn’t also broken. This is probably why re-building the rescue kernel isn’t automated.
My suggestion going forward is to use the two-command method discussed above periodically, but only after you’ve confirmed that you’ve got a good working kernel as your latest one. I can confirm that rescue kernels too out of date will not even boot. It doesn’t take years for them to go stale.
Last time I tried to boot the rescue kernel, it went into emergency mode where you need the root password on order to do anything. The reason is that after a few kernel updates, the kernel modules matching the emergency kernel have all been removed.
This would seem to imply that the rescue kernel would need updated at least once every 3 kernel updates.
I try to do that myself, but most users would have no clue this was necessary until the rescue mode was needed and failed. Most would not even know there was the option to select the rescue kernel since the grub menu is normally hidden.
