Bug 880524 - [kernel] managing multiple kernel packages
Summary: [kernel] managing multiple kernel packages
Alias: None
Product: Fedora
Classification: Fedora
Component: dnf
Version: 19
Hardware: Unspecified
OS: Unspecified
Target Milestone: ---
Assignee: Ales Kozumplik
QA Contact: Fedora Extras Quality Assurance
Depends On:
Blocks: 871892
TreeView+ depends on / blocked
Reported: 2012-11-27 08:56 UTC by shu.chen
Modified: 2014-09-30 23:40 UTC (History)
9 users (show)

Fixed In Version: hawkey-0.4.4-1.fc20
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2013-11-12 00:39:17 UTC
Type: Bug

Attachments (Terms of Use)

Description shu.chen 2012-11-27 08:56:50 UTC
Description of problem:
dnf no longer manages versions of kernel packages, keeping some X number of kernels around (dropping the oldest when it installs a newer, leaving at most some specified X versions around)

Version-Release number of selected component (if applicable):

How reproducible:
dnf upgrade on fedora rawhide

Steps to Reproduce:
Actual results:

Expected results:

Additional info:
Yum has a feature where it'll keep around N versions of the kernel (This might be linked to installonly_limit config in yum.conf?). If there is a kernel update, it'll uninstall your oldest version (and associated -devel and -header package) when it installs the latest.  Also, it appears smart enough to know what kernel you're running currently, and will drop the penultimate-oldest if you're currently booted into the oldest.  It also somehow fixes my grub entries (whether that's done in yum or it punts that somewhere else I don't know).

I installed dnf today on my rawhide system and tried an upgrade, and dnf doesn't appear to manage kernels at all.  Actually what happened was on a "dnf upgrade" it upgraded every package except kernel and kernel-devel (that is, it installed non-kernel upgrade and kernel-headers).  "dnf upgrade kernel" and "dnf upgrade kernel-devel" installed the package I asked, but did not remove the penultimate-oldest kernel (since I live day to day on a kernel I know is stable, which is the oldest kernel of the ones installed)

So that looks like a depsolving problem, since there are no issues installing the newest kernel and kernel-devel, but the upgrade command did not install them.  But that's unrelated to what I'm really interested in, which is the ability to keep multiple versions of the kernel around, so as to easily revert in case the new kernel proves unstable.

Comment 1 Ales Kozumplik 2012-11-28 08:23:41 UTC
Hello and thank you for the report,

Yum really has some 'smart' rules about how to handle kernel upgrades, and for the F18 version of DNF we only implemented the 'dnf upgrade kernel' scenario (which as you've observed installs a new kernel if one is available but doesn't look at the old ones to remove them). There are plans to achieve high degree of compatibility between Yum and DNF, but for some issues (like this current one) it might be trickier than for others.

I'll keep this bugzilla as a progress tracker for the issue.

Comment 2 Miroslav Suchý 2012-12-14 16:32:09 UTC
Also note, that when installing new kernel yum output is

kernel                 3.6.6
kernel-devel           3.6.6
kernel-modules-extra   3.6.6
kernel                 3.6.1
kernel-devel           3.6.1
kernel-modules-extra   3.6.1

While dnf prints:
kernel                 3.6.6
kernel-modules-extra   3.6.6
kernel-modules-extra   3.6.1

There is difference in that kernel-modules-extra and is completly ommited kernel-devel.

Comment 3 Fedora End Of Life 2013-04-03 13:36:02 UTC
This bug appears to have been reported against 'rawhide' during the Fedora 19 development cycle.
Changing version to '19'.

(As we did not run this process for some time, it could affect also pre-Fedora 19 development
cycle bugs. We are very sorry. It will help us with cleanup during Fedora 19 End Of Life. Thank you.)

More information and reason for this action is here:

Comment 4 Ales Kozumplik 2013-05-14 15:15:04 UTC
The fact that 'dnf upgrade' does not trigger any operation for new, available kernels is treated in bug 905209.

This bug will focus on keeping the right amount of all the latest kernels and the running kernel installed.

Comment 5 Ales Kozumplik 2013-05-20 08:33:25 UTC

If you'll remember I talked to you about this feature at the devconf in February: Yum limits the number of running installonlies (e.g. kernel) to a certain constant. We decided it's best to implement this with re-resolving for those cases when we detect the transaction would leave too many kernels installed. However I have a don't get an installation of a multiversion package if I erase another one at the same time:

repo system 0 testtags <inline>
#>=Ver: 2.0
#>=Pkg: c 25 1 x86_64
#>=Pkg: c 26 1 x86_64
#>=Pkg: c 27 1 x86_64
repo available 0 testtags <inline>
#>=Ver: 2.0
#>=Pkg: c 31 1 x86_64
#>=Obs: d

system x86_64 rpm system

job multiversion name c
job erase selection c-25 canon
job update all packages
result transaction,problems <inline>
#>erase c-25-1.x86_64@system
#>install c-31-1.x86_64@available

What do you think?

Comment 6 Michael Schröder 2013-05-27 12:34:06 UTC
(back from the Tizen conf in San Francisco)

Well, looks like a bug, of course. The erase element blocks the installation of c-31.

Comment 7 Michael Schröder 2013-05-27 12:40:58 UTC
(As a workaround, you can add "install" elements for the kernels from the first solver result when creating the re-run job)

Comment 8 Jiri Moskovcak 2013-10-15 08:58:23 UTC
I just run out of space on /boot because of this bug, Ales, can you please rise a priority for this one?

Comment 9 Ales Kozumplik 2013-10-15 12:28:40 UTC
yeah, moving it up the queue.

Comment 10 Fabien Archambault 2013-10-23 09:05:20 UTC
up? I have the same issue here:
$ rpm -qa | grep kernel

Comment 11 Ales Kozumplik 2013-10-23 10:12:15 UTC
looking at this now

Comment 12 Ales Kozumplik 2013-10-29 10:08:14 UTC
Fixed by 7e609a4 and a series of patches in hawkey. Needs hawkey-0.4.4.

Comment 13 Fedora Update System 2013-10-30 10:08:51 UTC
dnf-0.4.6-1.fc20 has been submitted as an update for Fedora 20.

Comment 14 Fedora Update System 2013-10-30 17:14:02 UTC
Package dnf-0.4.6-1.fc20, libsolv-0.4.0-1.gitd49d319.fc20, hawkey-0.4.4-1.fc20:
* should fix your issue,
* was pushed to the Fedora 20 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing dnf-0.4.6-1.fc20 libsolv-0.4.0-1.gitd49d319.fc20 hawkey-0.4.4-1.fc20'
as soon as you are able to.
Please go to the following url:
then log in and leave karma (feedback).

Comment 15 Fabien Archambault 2013-10-30 17:17:32 UTC
Is it possible to get it for F19? I cannot consider this fixed until I get a version for F19 as this bug is against that version.

Comment 16 Ales Kozumplik 2013-10-31 06:37:41 UTC
Hello Fabien, this fix is not going to be backported, sorry.

Comment 17 Fedora Update System 2013-10-31 14:22:22 UTC
hawkey-0.4.4-1.fc20 has been submitted as an update for Fedora 20.

Comment 18 Fedora Update System 2013-10-31 17:42:17 UTC
Package hawkey-0.4.4-1.fc20, dnf-0.4.6-1.fc20, libsolv-0.4.0-1.gitd49d319.fc20, librepo-1.3.0-1.fc20:
* should fix your issue,
* was pushed to the Fedora 20 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing hawkey-0.4.4-1.fc20 dnf-0.4.6-1.fc20 libsolv-0.4.0-1.gitd49d319.fc20 librepo-1.3.0-1.fc20'
as soon as you are able to.
Please go to the following url:
then log in and leave karma (feedback).

Comment 19 Fedora Update System 2013-11-12 00:39:17 UTC
hawkey-0.4.4-1.fc20, dnf-0.4.6-1.fc20, libsolv-0.4.0-1.gitd49d319.fc20, librepo-1.3.0-1.fc20 has been pushed to the Fedora 20 stable repository.  If problems still persist, please make note of it in this bug report.

Note You need to log in before you can comment on or make changes to this bug.