Bug 1767904

Summary:	dnf provides not way to preserve an old version of a pkg while also installing updates
Product:	[Fedora] Fedora	Reporter:	morgan read <mstuff>
Component:	dnf	Assignee:	Jaroslav Rohel <jrohel>
Status:	CLOSED NOTABUG	QA Contact:	Fedora Extras Quality Assurance <extras-qa>
Severity:	unspecified	Docs Contact:
Priority:	unspecified
Version:	30	CC:	dmach, jmracek, jrohel, mblaha, mhatina, packaging-team-maint, pkratoch, rpm-software-management, rpm, spamulousbastard+redhat, vmukhame
Target Milestone:	---	Keywords:	Triaged
Target Release:	---
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:		Doc Type:	If docs needed, set a value
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2020-01-09 10:07:26 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description morgan read 2019-11-01 16:02:23 UTC

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

Comment 1 Jaroslav Rohel 2019-11-04 10:11:39 UTC

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" .

Comment 2 Jaroslav Rohel 2020-01-09 10:07:26 UTC

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.

Comment 3 spamulousbastard+redhat 2020-09-11 10:52:10 UTC

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.