Description of problem: Can't preserve an old version of a package (eg kernel) while maintaining current updates. Version-Release number of selected component (if applicable): $ dnf --version 4.2.11 Installed: dnf-0:4.2.11-2.fc30.noarch at Sun 13 Oct 2019 15:18:10 GMT Built : Fedora Project at Tue 01 Oct 2019 14:12:41 GMT Installed: rpm-0:4.14.2.1-5.fc30.x86_64 at Sun 01 Sep 2019 21:02:06 GMT Built : Fedora Project at Thu 29 Aug 2019 10:46:16 GMT How reproducible: Always Steps to Reproduce: 1. n/a (how does one reproduce something that doesn't happen...) 2. 3. Actual results: Can't keep old package version installed while maintain an up to date installed version Expected results: Install old and new Additional info: See discussion here: https://ask.fedoraproject.org/t/howto-prevent-kernel-updates/3001/10
There is a mechanism for automatic remove the oldest non-running kernel during kernel upgrade (installing the new one). You can change the number of kernels that stays in the system by option "installonly_limit". You can disable the mechanism by setting the option to "0". The option can be set permanently in configuration file (/etc/dnf/dnf.conf) or for a single DNF run using argument "--setopt=installonly_limit=0" .
As I explained 2 months ago in the comment 1. There is a way how to preserve old version of kernel during installation of new one. And it is documented. Example part of output from "man dnf.conf": installonly_limit integer Number of installonly packages allowed to be installed concurrently. Defaults to 3. The minimal number of installonly packages is 2. Value 0 or 1 means unlimited number of installonly packages. I'm closing the bugreport. Don't hesiate to reopen the bugreport if the solution presented does not work for you.
That doesn't solve the problem. Setting installonly_limit to 0 causes an ever increasing number of kernels to be installed, which quickly fills up /boot. What is missing is the ability to keep *one specific* old kernel. Here is the user story: 1. User is running kernel 5.6.19. 2. User upgrades to 5.7.4. It has a crash bug that is triggered non-deterministically after hours or days. Eventually, the user figures it out and boots back into 5.6.19. 3. Every time a new kernel comes out, the user would like to try that one to see if the bug is still present. Testing a new kernel takes days, during which another kernel might be released. 4. In order to stop 5.6.19 from getting uninstalled, user must either reboot into 5.6.19 to run updates, or manually uninstall earlier 5.7 series kernels, or increase installonly_limit, which fills up /boot. 5. Bug is finally fixed in 5.7.13, but the LKML discussion seems to be divided on whether the fix was the right approach. 6. User would like to keep 5.6.19 around forever, or at least for a year or so, just in case, because it had over 100 days of flawless uptime and no other installed kernel is as battle-tested. Unfortunately this still requires the rigmarole from item 4.