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): 0.2.16 How reproducible: dnf upgrade on fedora rawhide Steps to Reproduce: 1. 2. 3. 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.
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.
Also note, that when installing new kernel yum output is Installing: kernel 3.6.6 kernel-devel 3.6.6 kernel-modules-extra 3.6.6 Removing: kernel 3.6.1 kernel-devel 3.6.1 kernel-modules-extra 3.6.1 While dnf prints: Installing: kernel 3.6.6 Upgrading kernel-modules-extra 3.6.6 Removing: kernel-modules-extra 3.6.1 There is difference in that kernel-modules-extra and is completly ommited kernel-devel.
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: https://fedoraproject.org/wiki/BugZappers/HouseKeeping/Fedora19
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.
Michael, 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?
(back from the Tizen conf in San Francisco) Well, looks like a bug, of course. The erase element blocks the installation of c-31.
(As a workaround, you can add "install" elements for the kernels from the first solver result when creating the re-run job)
I just run out of space on /boot because of this bug, Ales, can you please rise a priority for this one?
yeah, moving it up the queue.
up? I have the same issue here: $ rpm -qa | grep kernel kernel-devel-3.11.2-201.fc19.x86_64 kernel-devel-3.11.6-200.fc19.x86_64 texlive-l3kernel-svn29409.SVN_4469-0.1.fc19.noarch kernel-3.11.6-200.fc19.x86_64 abrt-addon-kerneloops-2.1.8-1.fc19.x86_64 kernel-3.11.3-201.fc19.x86_64 kernel-3.11.2-201.fc19.x86_64 kernel-devel-3.11.4-201.fc19.x86_64 kernel-devel-3.11.3-201.fc19.x86_64 kernel-devel-3.10.11-200.fc19.x86_64 libreport-plugin-kerneloops-2.1.8-1.fc19.x86_64 kernel-headers-3.11.6-200.fc19.x86_64 kernel-devel-3.10.10-200.fc19.x86_64 kernel-3.10.10-200.fc19.x86_64 kernel-3.10.9-200.fc19.x86_64 kernel-3.10.11-200.fc19.x86_64 kernel-3.9.9-302.fc19.x86_64 kernel-3.11.4-201.fc19.x86_64 kernel-modules-extra-3.11.6-200.fc19.x86_64 kernel-devel-3.10.9-200.fc19.x86_64 kernel-devel-3.9.9-302.fc19.x86_64
looking at this now
Fixed by 7e609a4 and a series of patches in hawkey. Needs hawkey-0.4.4.
dnf-0.4.6-1.fc20 has been submitted as an update for Fedora 20. https://admin.fedoraproject.org/updates/dnf-0.4.6-1.fc20
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: https://admin.fedoraproject.org/updates/FEDORA-2013-20333/libsolv-0.4.0-1.gitd49d319.fc20,hawkey-0.4.4-1.fc20,dnf-0.4.6-1.fc20 then log in and leave karma (feedback).
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.
Hello Fabien, this fix is not going to be backported, sorry.
hawkey-0.4.4-1.fc20 has been submitted as an update for Fedora 20. https://admin.fedoraproject.org/updates/hawkey-0.4.4-1.fc20
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: https://admin.fedoraproject.org/updates/FEDORA-2013-20406/dnf-0.4.6-1.fc20,libsolv-0.4.0-1.gitd49d319.fc20,librepo-1.3.0-1.fc20,hawkey-0.4.4-1.fc20 then log in and leave karma (feedback).
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.