Right now, I have an almost perfect Fedora WS 42 on my Hewlett-Packard HP ProDesk 600 G1 SFF:
Linux fedora 6.17.4-200.fc42.x86_64 #1 SMP PREEMPT_DYNAMIC Sun Oct 19 18:47:49 UTC 2025 x86_64 GNU/Linux
If I hit the “ESC” key when my computer boots, I come to a UEFI menu from where, if I chose “Continue Startup”, I come to a boot menu that gives a choice between last three kernel updates. Every time I make a kernel update, the oldest one disapperars.
If I have a problem that lasts long enough, and I make updates regularly, I lose the last good version of kernel.
Is there a way to keep the good version of kernel somewhere (maybe on my NAS) so to be able to boot from there?
Not entirely the answer to your question, but on Fedora Atomic Desktops (Silverblue, Kinoite, CoreOS), you can pin known working deployments. I’m not entirely sure how to explain what deployments are, but it’s kinda like pinning kernel version, except it also pins all packages you knew were working.
I’m on Fedora Silverblue Rawhide, so I pinned my last F43 deployment, in case I would want to go back.
From your answer I believe I understand what deployments are, and I believe it would be more correct if I used the word “deployment” in my question. Do you think so?
Ok, I do not know how you update, but if you see that there is a kernel update, just change in the one you do not want to loose and make the update from within this started kernel. Otherwise this would brake your running kernel.
The solution from @ilikelinux works because the running kernel will never be removed, so if you always do your updates from that running kernel, it’ll be in use when a new kernel is applied and thus won’t be removed. Of course, if you forget to switch to it… it’s very likely going to be removed as it’ll probably be the oldest.
Addendum : apparently doesn’t work, as nether versionlock or ptoected_packages applies to kernels, despite no mention of this in the man pages. Tread carefully dear reader as what you thought was a sure fire “never remove this thing”… isn’t.
This will not work, the same as dnf versionlock fails to prevent a specific kernel version to be removed by dnf.
The only reliable way to prevent dnf removing an older kernel is to manually remove another kernel before installing a new kernel version.
What you could do is changing the installonly_limit from the default 3 to 4 and remove a kernel when 4 kernels are installed. The next kernel update will not remove any older kernel version.
I’ve not checked this as I’ve no reason to., but if that is the case than it sounds magnificently disingenuous on the part of dnf. What’s the point of having “protected_packages” if they are not protected?
The man page specifically says that they will never be completely removed. If the word “completely” is doing a lot of heavy lifting in the statement then I’d say this is a pretty large “gotcha”.
protected_packages
list
This append list option contains names of packages that DNF5 should never completely remove.
They are protected via Obsoletes as well as user/plugin removals.
Default: dnf5,glob:/etc/dnf/protected.d/*.conf.
NOTE:
Any packages which should be protected can do so by including a file in /etc/dnf/protected.d with their package name in it.
DNF5 will protect also the package corresponding to the running version of the kernel. See also protect_running_kernel option.
this works only for package names, and not versions. It prevents the removal of the package, but does not prevent the package to by replaced by newer version.
So then, if this does not work to lock a specific package at a specific release, in place, how does one lock a specific package at a specific version in place?
dnf versionlock but it does not work with kernels. And there is probably a very good reason for this to prevent users from locking all available kernel slots.
But it would be nice to be able to pin ONE (and only one) kernel.
Hmm - I mean it makes sense… but if it specifically doesn’t work for kernels, it would be nice to have it mentioned in the man page to prevent users from finding out when it’s all a little bit too late.
Removed the solution flag and added a note, just in case anyone gets bitten hard on the arse by thinking they have bought themselves a locked kernel version.
I guess the installonly_limit check ignores the locked version(s)?
And I can see the point why it’s being ignored.
I tried to versionlock an older kernel a few months ago and that didn’t work.
the github issue is a perfect example:
user locks 2 kernel versions. How should dnf proceed if the system is running another kernel version (not locked ) and installonly_limit = 3 ?
I would imagine the preferred use case for people who lock kernels would be to pop a message out and require user intervention rather than just ignoring what the user thought were clear instructions in dnf.conf and removing the oldest kernel anyway.
That’s what I’d expect it to do if I were locking multiple kernel versions. Anyone who’s doing that probably has good reason to REALLY want to hang on to version n.nn.nnn and after having taken the trouble to slap a directive into dnf.conf, and would be somewhat upset to find that it was silently blown out of the water anyway.
Seems it’s be a bone of contention for 6 years now…
Unfortunately this happened this year with the kernel versions, which not resolved issues after a new release, with several users (including me on a test installation).
We can change the boot order with the id of the kernel, to set with grubby other than 0.
This means booting into the older kernel without interaction (prss ESC/Shift) is possible. This boot option is then protected
However, wile updating a kernel other than ID 0, dnf should pause when updating and display the message like:
“Do you wish to keep the kernel (other than ID0) as a further recovery option?” k / o (k=keep o=overwrite)
This way we could avoid to overwrite by accident such a “working recovery” kernel.
If the user answers with “k” to the question above, grubby should automatically being restarted (after update) to re colocate the ID correctly again.
I would not take a parameter like -y because this is already used for --assumeyes
I just wanted to shill Atomic Desktops a bit.