Description of problem: I am currently running the oldest of 3 installed kernels (since the oldest kernel is non-debug). Therefore, when updating the kernel* packages which have more than one version installed, the second-oldest should be removed. Yum does this correctly, however dnf does not. Note that it does want to remove the correct versions of kernel and kernel-modules-extra, however. [root@localhost ~]# dnf distro-sync Resolving dependencies --> Starting dependency resolution ---> Package kernel.x86_64 3.14.0-0.rc1.git4.1.fc21 will be installed ---> Package kernel-devel.x86_64 3.14.0-0.rc1.git4.1.fc21 will be installed ---> Package kernel-modules-extra.x86_64 3.14.0-0.rc1.git4.1.fc21 will be installed ---> Package kernel-headers.x86_64 3.14.0-0.rc1.git3.1.fc21 will be upgraded ---> Package kernel-headers.x86_64 3.14.0-0.rc1.git4.1.fc21 will be an upgrade ---> Package kernel-tools.x86_64 3.14.0-0.rc1.git3.1.fc21 will be upgraded ---> Package kernel-tools.x86_64 3.14.0-0.rc1.git4.1.fc21 will be an upgrade ---> Package kernel-tools-libs.x86_64 3.14.0-0.rc1.git3.1.fc21 will be upgraded ---> Package kernel-tools-libs.x86_64 3.14.0-0.rc1.git4.1.fc21 will be an upgrade ---> Package kernel-tools-libs-devel.x86_64 3.14.0-0.rc1.git3.1.fc21 will be upgraded ---> Package kernel-tools-libs-devel.x86_64 3.14.0-0.rc1.git4.1.fc21 will be an upgrade ---> Package kernel.x86_64 3.14.0-0.rc1.git2.1.fc21 will be erased ---> Package kernel-devel.x86_64 3.14.0-0.rc1.git0.1.fc21 will be erased ---> Package kernel-modules-extra.x86_64 3.14.0-0.rc1.git2.1.fc21 will be erased --> Finished dependency resolution Dependencies resolved. ================================================================================ Package Arch Version Repository Size ================================================================================ Installing: kernel x86_64 3.14.0-0.rc1.git4.1.fc21 rawhide 33 M kernel-devel x86_64 3.14.0-0.rc1.git4.1.fc21 rawhide 8.8 M kernel-modules-extra x86_64 3.14.0-0.rc1.git4.1.fc21 rawhide 2.2 M Upgrading: kernel-headers x86_64 3.14.0-0.rc1.git4.1.fc21 rawhide 948 k kernel-tools x86_64 3.14.0-0.rc1.git4.1.fc21 rawhide 145 k kernel-tools-libs x86_64 3.14.0-0.rc1.git4.1.fc21 rawhide 72 k kernel-tools-libs-devel x86_64 3.14.0-0.rc1.git4.1.fc21 rawhide 69 k Removing: kernel x86_64 3.14.0-0.rc1.git2.1.fc21 @System 141 M kernel-devel x86_64 3.14.0-0.rc1.git0.1.fc21 @System 33 M kernel-modules-extra x86_64 3.14.0-0.rc1.git2.1.fc21 @System 9.0 M Transaction Summary ================================================================================ Install 3 Packages Upgrade 4 Packages Remove 3 Packages Total download size: 45 M Is this ok [y/N]: N Exiting on user Command [root@localhost ~]# rpm -q kernel kernel-devel kernel-modules-extra kernel-3.14.0-0.rc1.git0.1.fc21.x86_64 kernel-3.14.0-0.rc1.git2.1.fc21.x86_64 kernel-3.14.0-0.rc1.git3.1.fc21.x86_64 kernel-devel-3.14.0-0.rc1.git0.1.fc21.x86_64 kernel-devel-3.14.0-0.rc1.git2.1.fc21.x86_64 kernel-devel-3.14.0-0.rc1.git3.1.fc21.x86_64 kernel-modules-extra-3.14.0-0.rc1.git0.1.fc21.x86_64 kernel-modules-extra-3.14.0-0.rc1.git2.1.fc21.x86_64 kernel-modules-extra-3.14.0-0.rc1.git3.1.fc21.x86_64 [root@localhost ~]# uname -r 3.14.0-0.rc1.git0.1.fc21.x86_64 [root@localhost ~]# Version-Release number of selected component (if applicable): dnf-0.4.13-2.fc21.noarch Additional info: I updated all non-kernel* packages first, to make sure dnf wasn't confused, and there are currently no broken dependencies.
Hello, can you please attach the depsolving data as described at http://dnf.baseurl.org/2013/11/25/reporting-depsolving-bugs/ ? Thank you.
Created attachment 861334 [details] debugdata.tgz Reproduced the bug by running the oldest kernel in 32-bit F20. Gzipped debugdata/ attached. The behavior is the same with either "dnf distro-sync" or "dnf update". [root@dell-pc ~]# dnf --debugsolver distro-sync Resolving dependencies --> Starting dependency resolution ---> Package kernel-PAE.i686 3.12.10-300.fc20 will be installed ---> Package kernel-PAE-devel.i686 3.12.10-300.fc20 will be installed ---> Package kernel-PAE-modules-extra.i686 3.12.10-300.fc20 will be installed ---> Package kernel-doc.noarch 3.12.9-301.fc20 will be upgraded ---> Package kernel-doc.noarch 3.12.10-300.fc20 will be an upgrade ---> Package kernel-headers.i686 3.12.9-301.fc20 will be upgraded ---> Package kernel-headers.i686 3.12.10-300.fc20 will be an upgrade ---> Package kernel-tools.i686 3.12.9-301.fc20 will be upgraded ---> Package kernel-tools.i686 3.12.10-300.fc20 will be an upgrade ---> Package kernel-tools-libs.i686 3.12.9-301.fc20 will be upgraded ---> Package kernel-tools-libs.i686 3.12.10-300.fc20 will be an upgrade ---> Package kernel-tools-libs-devel.i686 3.12.9-301.fc20 will be upgraded ---> Package kernel-tools-libs-devel.i686 3.12.10-300.fc20 will be an upgrade ---> Package kernel-PAE.i686 3.12.8-300.fc20 will be erased ---> Package kernel-PAE-devel.i686 3.12.7-300.fc20 will be erased ---> Package kernel-PAE-modules-extra.i686 3.12.8-300.fc20 will be erased --> Finished dependency resolution Dependencies resolved. ================================================================================ Package Arch Version Repository Size ================================================================================ Installing: kernel-PAE i686 3.12.10-300.fc20 updates 29 M kernel-PAE-devel i686 3.12.10-300.fc20 updates 8.5 M kernel-PAE-modules-extra i686 3.12.10-300.fc20 updates 1.9 M Upgrading: kernel-doc noarch 3.12.10-300.fc20 updates 7.9 M kernel-headers i686 3.12.10-300.fc20 updates 915 k kernel-tools i686 3.12.10-300.fc20 updates 119 k kernel-tools-libs i686 3.12.10-300.fc20 updates 61 k kernel-tools-libs-devel i686 3.12.10-300.fc20 updates 57 k Removing: kernel-PAE i686 3.12.8-300.fc20 @System 98 M kernel-PAE-devel i686 3.12.7-300.fc20 @System 31 M kernel-PAE-modules-extra i686 3.12.8-300.fc20 @System 5.4 M Transaction Summary ================================================================================ Install 3 Packages Upgrade 5 Packages Remove 3 Packages Total download size: 48 M Is this ok [y/N]: N Exiting on user Command [root@dell-pc ~]# rpm -q kernel-PAE kernel-PAE-devel kernel-PAE-modules-extra kernel-PAE-3.12.7-300.fc20.i686 kernel-PAE-3.12.8-300.fc20.i686 kernel-PAE-3.12.9-301.fc20.i686 kernel-PAE-devel-3.12.7-300.fc20.i686 kernel-PAE-devel-3.12.8-300.fc20.i686 kernel-PAE-devel-3.12.9-301.fc20.i686 kernel-PAE-modules-extra-3.12.7-300.fc20.i686 kernel-PAE-modules-extra-3.12.8-300.fc20.i686 kernel-PAE-modules-extra-3.12.9-301.fc20.i686 [root@dell-pc ~]# uname -r 3.12.7-300.fc20.i686+PAE [root@dell-pc ~]#
Andre, to clarify: you claim that everything is OK with the transaction proposal besides the kernel-devel which the version corresponding to the version you are running should not be removed?
That's correct. The version of kernel-devel it wants to remove should be the same as the versions for kernel and kernel-modules-extra. If I used yum to do the same transaction, it would remove kernel-PAE-devel-3.12.8-300.fc20.i686, which is the correct version if I'm currently running 3.12.7.
Ah, I see in the summary that is what you meant. In that case: the actual behavior is the right one. DNF has a special mechanism not to delete the running kernel package during distro-sync/upgrade, but kernel-devel is not linked to this in any way (kernel-devel only contains /usr/src packages). It is by some additional hacks this works in Yum. To remedy the situation, kernel-devel should both: 1) Provide: installonlypkg(kernel) 2) Require: kernel-uname-r = 3.12.5-200.fc19.x86_64 By doing this, the requires link to the running kernel can be established. Otherwise random installonly packages could claim they should only move with the kernel version.
Alternative would be to agree that kernel-devel should not be installonly.
kernel-devel doesn't have to match a running or even an installed kernel, so I don't want to make it require it's matching kernel package. One can plausibly build against the kernel-devel package installed locally that corresponds to a kernel only another machine is running. This enables people to build other modules for different machines, etc. I don't see anything in the kernel.spec file that leads me to believe kernel-devel is marked as installonly.
(In reply to Josh Boyer from comment #7) > kernel-devel doesn't have to match a running or even an installed kernel, so > I don't want to make it require it's matching kernel package. One can > plausibly build against the kernel-devel package installed locally that > corresponds to a kernel only another machine is running. This enables > people to build other modules for different machines, etc. > > I don't see anything in the kernel.spec file that leads me to believe > kernel-devel is marked as installonly. the installonlyness of kernel-devel is a specific hack in Yum. Seeing this is not intentionally and probably does more confusion than good, I'm dropping this in Yum so people can install whatever specific kernel-devel they fancy (and have in their repos): https://github.com/akozumpl/dnf/commit/e3856e6d4c67579abeae03791fdc07820bf0c9b9 Thanks for clarifying this Josh, I reckon this can be closed now as NOTABUG.
If the yum hack is reverted, I think there should be a warning posted to some of the mailing lists regarding the change in behavior. The vast majority of users expect the versions to be synchronized, and if they're not always running the latest kernel, they'll be affected, and will have to be careful to delete the desired old version manually.
> I'm dropping this in Yum so people can install whatever specific kernel-devel they fancy (and have in their repos): Of course, people can do this now, if they're willing to also install the corresponding kernel.
I'm going to punt this back to dnf because of comment #9. If you'd like to close it as fixed or whatever, that's fine with me. Closing it as notabug when a change in dnf was made seems inaccurate.
DNF upstream commit e3856e6d4c67579abeae03791fdc07820bf0c9b9 addresses this.
*** Bug 1069969 has been marked as a duplicate of this bug. ***
[root@localhost ~]# rpm -q kernel kernel-3.14.0-0.rc3.git5.1.fc21.x86_64 kernel-3.14.0-0.rc4.git0.1.fc21.x86_64 kernel-3.14.0-0.rc4.git1.1.fc21.x86_64 [root@localhost ~]# uname -r 3.14.0-0.rc4.git0.1.fc21.x86_64 [root@localhost ~]# rpm -q dnf dnf-0.4.16-2.fc21.noarch [root@localhost ~]# When updating the kernel packages, this is what yum wants to do (normal, expected behavior): Installing: kernel x86_64 3.14.0-0.rc4.git3.1.fc21 rawhide 33 M kernel-devel x86_64 3.14.0-0.rc4.git3.1.fc21 rawhide 8.8 M kernel-modules-extra x86_64 3.14.0-0.rc4.git3.1.fc21 rawhide 2.2 M Updating: kernel-headers x86_64 3.14.0-0.rc4.git3.1.fc21 rawhide 953 k kernel-tools x86_64 3.14.0-0.rc4.git3.1.fc21 rawhide 148 k kernel-tools-libs x86_64 3.14.0-0.rc4.git3.1.fc21 rawhide 75 k kernel-tools-libs-devel x86_64 3.14.0-0.rc4.git3.1.fc21 rawhide 72 k Removing: kernel x86_64 3.14.0-0.rc3.git5.1.fc21 @rawhide 141 M kernel-devel x86_64 3.14.0-0.rc3.git5.1.fc21 @rawhide 33 M kernel-modules-extra x86_64 3.14.0-0.rc3.git5.1.fc21 @rawhide 9.0 M This is what dnf wants to do: Installing: kernel x86_64 3.14.0-0.rc4.git3.1.fc21 rawhide 33 M kernel-modules-extra x86_64 3.14.0-0.rc4.git3.1.fc21 rawhide 2.2 M Upgrading: kernel-headers x86_64 3.14.0-0.rc4.git3.1.fc21 rawhide 953 k kernel-tools x86_64 3.14.0-0.rc4.git3.1.fc21 rawhide 148 k kernel-devel x86_64 3.14.0-0.rc4.git3.1.fc21 rawhide 8.8 M kernel-tools-libs x86_64 3.14.0-0.rc4.git3.1.fc21 rawhide 75 k kernel-tools-libs-devel x86_64 3.14.0-0.rc4.git3.1.fc21 rawhide 72 k Removing: kernel x86_64 3.14.0-0.rc3.git5.1.fc21 @System 141 M kernel-modules-extra x86_64 3.14.0-0.rc3.git5.1.fc21 @System 9.0 M Am I correct that if I let it run, dnf will remove all older kernel-devel packages? (That's what the rpm command does when using rpm -Uvh on kernel or kernel-devel, I've made that mistake.) If the intent is to make it easy to have arbitrary versions of kernel-devel installed, this doesn't seem very user-friendly.
(In reply to Andre Robatino from comment #14) > Am I correct that if I let it run, dnf will remove all older kernel-devel > packages? (That's what the rpm command does when using rpm -Uvh on kernel or > kernel-devel, I've made that mistake.) If the intent is to make it easy to > have arbitrary versions of kernel-devel installed, this doesn't seem very > user-friendly. Hello, what is seen here is the expected behavior---there is no inherent reason to have kernel-devel be installonly package, see comment 7 and others.
*** Bug 1079701 has been marked as a duplicate of this bug. ***
(In reply to Ales Kozumplik from comment #12) > DNF upstream commit e3856e6d4c67579abeae03791fdc07820bf0c9b9 addresses this. Actually this commit seems more likely to worsen the original reported problem, as well as causing bug 1079701. This is not a fix, this is a regression. This completely breaks the following workflow: 1) boot machine 2) dnf update 3) do anything requiring building a kernel module Which many people use. 3) could be ie installing a dkms or akmod package, installing nvidia or fgrlx binary drivers, building a kernel module I'm still developing so which is out of tree for now, etc. Note that esp. breaking akmod and dkms will be bad and will cause a lot of issues once dnf becomes the standard. The reason I filed this bug went like this: 1) boot machine 2) do kernel module development 3) run dnf update in another terminal 4) continue kernel module development 5) make stops working due to missing headers, huh what ? Also if you insist on keeping this change it makes no sense what so ever to take away the install-only status from kernel-devel, but not from kernel-source. Reopening this.
I found that even if you explicitly try "dnf install <kernel-devel-*.rpm>", it still wants to do the update, which would erase all of the old versions. If yum goes away, the only way to have the same versions of kernel and kernel-devel would be to use explicit rpm commands to install the new kernel-devel and remove the old one.
The way to do this would probably be to a) make kernel-devel installonly again (bug 1079906). Should make life easier in 9/10 of these situations. b) make sure that even installonly kernel packages without any kind of dependency on the running kernel stay installed. There is currently no way to do that and I am not sure if we want to build that kind of logic into dnf/hawkey. But let's see how fixing 1079906 (a right thing to do anyway) helps you, Andre and Hans, and then take it from there. If you hit problems, please attach the solver debug data as described in [1]. [1] http://dnf.baseurl.org/2013/11/25/reporting-depsolving-bugs/
579ee97 drops kernel-source from installonlypkgs on the DNF side.
(In reply to Ales Kozumplik from comment #19) > The way to do this would probably be to > > a) make kernel-devel installonly again (bug 1079906). Should make life > easier in 9/10 of these situations. Agreed. > b) make sure that even installonly kernel packages without any kind of > dependency on the running kernel stay installed. There is currently no way > to do that and I am not sure if we want to build that kind of logic into > dnf/hawkey. I don't think that will be necessary, AFAIK dnf will protect the running kernel on normal upgrades, so the user really needs to do something special to get that removed. I don't think we need to cover cases where the user explicitly shoots himself in the foot. > But let's see how fixing 1079906 (a right thing to do anyway) helps you Agreed.
(In reply to Ales Kozumplik from comment #8) > > the installonlyness of kernel-devel is a specific hack in Yum. Seeing this > is not intentionally and probably does more confusion than good, I'm > dropping this in Yum so people can install whatever specific kernel-devel > they fancy (and have in their repos): > > https://github.com/akozumpl/dnf/commit/ > e3856e6d4c67579abeae03791fdc07820bf0c9b9 > > Thanks for clarifying this Josh, I reckon this can be closed now as NOTABUG. Perhaps with this commit you've solved "running the oldest", however at the same time you're broke "running the newest"! ========================= BEFORE ======================= "installonly: kernel-devel should not be installonly." https://github.com/akozumpl/dnf/commit/e3856e6 ======================================================== $ uname -r 3.16.0-0.rc2.git0.1.fc21.x86_64 # dnf --disablerepo \* --enablerepo rawhide-koji update kernel\* \*perf Dependencies resolved. ========================================================================================== Package Arch Version Repository Size ========================================================================================== Installing: kernel-core x86_64 3.16.0-0.rc2.git3.1.fc21 rawhide-koji 19 M kernel x86_64 3.16.0-0.rc2.git3.1.fc21 rawhide-koji 86 k kernel-devel x86_64 3.16.0-0.rc2.git3.1.fc21 rawhide-koji 9.0 M kernel-modules-extra x86_64 3.16.0-0.rc2.git3.1.fc21 rawhide-koji 2.3 M kernel-modules x86_64 3.16.0-0.rc2.git3.1.fc21 rawhide-koji 17 M Upgrading: kernel-headers x86_64 3.16.0-0.rc2.git3.1.fc21 rawhide-koji 985 k kernel-tools x86_64 3.16.0-0.rc2.git3.1.fc21 rawhide-koji 168 k kernel-tools-libs x86_64 3.16.0-0.rc2.git3.1.fc21 rawhide-koji 92 k kernel-tools-libs-devel x86_64 3.16.0-0.rc2.git3.1.fc21 rawhide-koji 88 k perf x86_64 3.16.0-0.rc2.git3.1.fc21 rawhide-koji 1.0 M python-perf x86_64 3.16.0-0.rc2.git3.1.fc21 rawhide-koji 179 k Removing: kernel x86_64 3.15.0-1.fc21 @System 0 kernel-core x86_64 3.15.0-1.fc21 @System 40 M kernel-devel x86_64 3.15.0-1.fc21 @System 33 M kernel-modules x86_64 3.15.0-1.fc21 @System 16 M kernel-modules-extra x86_64 3.15.0-1.fc21 @System 2.1 M Transaction Summary ========================================================================================== Install 5 Packages Upgrade 6 Packages Remove 5 Packages Total download size: 50 M Is this ok [y/N]: OK! ========================= AFTER ======================== "installonly: kernel-devel should not be installonly." https://github.com/akozumpl/dnf/commit/e3856e6 ======================================================== $ rpm -q kernel-devel kernel-devel-3.15.0-1.fc21.x86_64 kernel-devel-3.16.0-0.rc2.git0.1.fc21.x86_64 # dnf --disablerepo \* --enablerepo rawhide-koji update kernel\* \*perf Dependencies resolved. ========================================================================================== Package Arch Version Repository Size ========================================================================================== Installing: kernel-core x86_64 3.16.0-0.rc2.git3.1.fc21 rawhide-koji 19 M kernel x86_64 3.16.0-0.rc2.git3.1.fc21 rawhide-koji 86 k kernel-modules-extra x86_64 3.16.0-0.rc2.git3.1.fc21 rawhide-koji 2.3 M kernel-modules x86_64 3.16.0-0.rc2.git3.1.fc21 rawhide-koji 17 M Upgrading: kernel-devel x86_64 3.16.0-0.rc2.git3.1.fc21 rawhide-koji 9.0 M kernel-headers x86_64 3.16.0-0.rc2.git3.1.fc21 rawhide-koji 985 k kernel-tools x86_64 3.16.0-0.rc2.git3.1.fc21 rawhide-koji 168 k kernel-tools-libs x86_64 3.16.0-0.rc2.git3.1.fc21 rawhide-koji 92 k kernel-tools-libs-devel x86_64 3.16.0-0.rc2.git3.1.fc21 rawhide-koji 88 k perf x86_64 3.16.0-0.rc2.git3.1.fc21 rawhide-koji 1.0 M python-perf x86_64 3.16.0-0.rc2.git3.1.fc21 rawhide-koji 179 k Removing: kernel x86_64 3.15.0-1.fc21 @System 0 kernel-core x86_64 3.15.0-1.fc21 @System 40 M kernel-modules x86_64 3.15.0-1.fc21 @System 16 M kernel-modules-extra x86_64 3.15.0-1.fc21 @System 2.1 M Transaction Summary ========================================================================================== Install 4 Packages Upgrade 7 Packages Remove 4 Packages Total size: 50 M Is this ok [y/N]: y Downloading Packages: [SKIPPED] kernel-core-3.16.0-0.rc2.git3.1.fc21.x86_64.rpm: Already downloaded [SKIPPED] kernel-3.16.0-0.rc2.git3.1.fc21.x86_64.rpm: Already downloaded [SKIPPED] kernel-modules-extra-3.16.0-0.rc2.git3.1.fc21.x86_64.rpm: Already downloaded [SKIPPED] kernel-modules-3.16.0-0.rc2.git3.1.fc21.x86_64.rpm: Already downloaded [SKIPPED] kernel-devel-3.16.0-0.rc2.git3.1.fc21.x86_64.rpm: Already downloaded [SKIPPED] kernel-headers-3.16.0-0.rc2.git3.1.fc21.x86_64.rpm: Already downloaded [SKIPPED] kernel-tools-3.16.0-0.rc2.git3.1.fc21.x86_64.rpm: Already downloaded [SKIPPED] kernel-tools-libs-3.16.0-0.rc2.git3.1.fc21.x86_64.rpm: Already downloaded [SKIPPED] kernel-tools-libs-devel-3.16.0-0.rc2.git3.1.fc21.x86_64.rpm: Already downloaded [SKIPPED] perf-3.16.0-0.rc2.git3.1.fc21.x86_64.rpm: Already downloaded [SKIPPED] python-perf-3.16.0-0.rc2.git3.1.fc21.x86_64.rpm: Already downloaded ------------------------------------------------------------------------------------------ Total 4.9 GB/s | 50 MB 00:00 Running transaction check Transaction check succeeded. Running transaction test Transaction test succeeded. Running transaction Installing : kernel-core-3.16.0-0.rc2.git3.1.fc21.x86_64 1/23 Installing : kernel-modules-3.16.0-0.rc2.git3.1.fc21.x86_64 2/23 Upgrading : kernel-tools-libs-3.16.0-0.rc2.git3.1.fc21.x86_64 3/23 Upgrading : kernel-tools-3.16.0-0.rc2.git3.1.fc21.x86_64 4/23 Upgrading : kernel-tools-libs-devel-3.16.0-0.rc2.git3.1.fc21.x86_64 5/23 Installing : kernel-3.16.0-0.rc2.git3.1.fc21.x86_64 6/23 Installing : kernel-modules-extra-3.16.0-0.rc2.git3.1.fc21.x86_64 7/23 Upgrading : python-perf-3.16.0-0.rc2.git3.1.fc21.x86_64 8/23 Upgrading : perf-3.16.0-0.rc2.git3.1.fc21.x86_64 9/23 Upgrading : kernel-headers-3.16.0-0.rc2.git3.1.fc21.x86_64 10/23 Upgrading : kernel-devel-3.16.0-0.rc2.git3.1.fc21.x86_64 11/23 Erasing : kernel-3.15.0-1.fc21.x86_64 12/23 Cleanup : kernel-tools-libs-devel-3.16.0-0.rc2.git0.1.fc21.x86_64 13/23 Cleanup : kernel-headers-3.16.0-0.rc2.git0.1.fc21.x86_64 14/23 Cleanup : kernel-devel-3.16.0-0.rc2.git0.1.fc21.x86_64 15/23 Cleanup : kernel-devel-3.16.0-0.rc2.git0.1.fc21.x86_64 16/23 Erasing : kernel-modules-extra-3.15.0-1.fc21.x86_64 17/23 Erasing : kernel-modules-3.15.0-1.fc21.x86_64 18/23 Cleanup : kernel-tools-3.16.0-0.rc2.git0.1.fc21.x86_64 19/23 Cleanup : kernel-tools-libs-3.16.0-0.rc2.git0.1.fc21.x86_64 20/23 Erasing : kernel-core-3.15.0-1.fc21.x86_64 21/23 Cleanup : python-perf-3.16.0-0.rc2.git0.1.fc21.x86_64 22/23 Cleanup : perf-3.16.0-0.rc2.git0.1.fc21.x86_64 23/23 Verifying : kernel-core-3.16.0-0.rc2.git3.1.fc21.x86_64 1/22 Verifying : kernel-3.16.0-0.rc2.git3.1.fc21.x86_64 2/22 Verifying : kernel-modules-extra-3.16.0-0.rc2.git3.1.fc21.x86_64 3/22 Verifying : kernel-modules-3.16.0-0.rc2.git3.1.fc21.x86_64 4/22 Verifying : kernel-devel-3.16.0-0.rc2.git3.1.fc21.x86_64 5/22 Verifying : kernel-headers-3.16.0-0.rc2.git3.1.fc21.x86_64 6/22 Verifying : kernel-tools-3.16.0-0.rc2.git3.1.fc21.x86_64 7/22 Verifying : kernel-tools-libs-3.16.0-0.rc2.git3.1.fc21.x86_64 8/22 Verifying : kernel-tools-libs-devel-3.16.0-0.rc2.git3.1.fc21.x86_64 9/22 Verifying : perf-3.16.0-0.rc2.git3.1.fc21.x86_64 10/22 Verifying : python-perf-3.16.0-0.rc2.git3.1.fc21.x86_64 11/22 Verifying : kernel-tools-libs-devel-3.16.0-0.rc2.git0.1.fc21.x86_64 12/22 Verifying : perf-3.16.0-0.rc2.git0.1.fc21.x86_64 13/22 Verifying : kernel-3.15.0-1.fc21.x86_64 14/22 Verifying : kernel-core-3.15.0-1.fc21.x86_64 15/22 Verifying : python-perf-3.16.0-0.rc2.git0.1.fc21.x86_64 16/22 Verifying : kernel-devel-3.16.0-0.rc2.git0.1.fc21.x86_64 17/22 Verifying : kernel-headers-3.16.0-0.rc2.git0.1.fc21.x86_64 18/22 Verifying : kernel-modules-3.15.0-1.fc21.x86_64 19/22 Verifying : kernel-modules-extra-3.15.0-1.fc21.x86_64 20/22 Verifying : kernel-tools-3.16.0-0.rc2.git0.1.fc21.x86_64 21/22 Verifying : kernel-tools-libs-3.16.0-0.rc2.git0.1.fc21.x86_64 22/22 Removed: kernel.x86_64 3.15.0-1.fc21 kernel-core.x86_64 3.15.0-1.fc21 kernel-modules.x86_64 3.15.0-1.fc21 kernel-modules-extra.x86_64 3.15.0-1.fc21 Installed: kernel-core.x86_64 3.16.0-0.rc2.git3.1.fc21 kernel.x86_64 3.16.0-0.rc2.git3.1.fc21 kernel-modules-extra.x86_64 3.16.0-0.rc2.git3.1.fc21 kernel-modules.x86_64 3.16.0-0.rc2.git3.1.fc21 Upgraded: kernel-devel.x86_64 3.16.0-0.rc2.git3.1.fc21 kernel-headers.x86_64 3.16.0-0.rc2.git3.1.fc21 kernel-tools.x86_64 3.16.0-0.rc2.git3.1.fc21 kernel-tools-libs.x86_64 3.16.0-0.rc2.git3.1.fc21 kernel-tools-libs-devel.x86_64 3.16.0-0.rc2.git3.1.fc21 perf.x86_64 3.16.0-0.rc2.git3.1.fc21 python-perf.x86_64 3.16.0-0.rc2.git3.1.fc21 Complete! $ rpm -q kernel-devel kernel-devel-3.16.0-0.rc2.git3.1.fc21.x86_64 $ rpm -qa | grep kernel | sort kernel-3.16.0-0.rc2.git0.1.fc21.x86_64 kernel-3.16.0-0.rc2.git3.1.fc21.x86_64 kernel-core-3.16.0-0.rc2.git0.1.fc21.x86_64 kernel-core-3.16.0-0.rc2.git3.1.fc21.x86_64 kernel-devel-3.16.0-0.rc2.git3.1.fc21.x86_64 kernel-headers-3.16.0-0.rc2.git3.1.fc21.x86_64 kernel-modules-3.16.0-0.rc2.git0.1.fc21.x86_64 kernel-modules-3.16.0-0.rc2.git3.1.fc21.x86_64 kernel-modules-extra-3.16.0-0.rc2.git0.1.fc21.x86_64 kernel-modules-extra-3.16.0-0.rc2.git3.1.fc21.x86_64 kernel-tools-3.16.0-0.rc2.git3.1.fc21.x86_64 kernel-tools-libs-3.16.0-0.rc2.git3.1.fc21.x86_64 kernel-tools-libs-devel-3.16.0-0.rc2.git3.1.fc21.x86_64
*** Bug 1121381 has been marked as a duplicate of this bug. ***
Closing this as the solution pretty much is to fix bug 1079906 filed against kernel.
Okay, but when is that going to happen? I was under the impression it was a simple fix, but my request for the status of that bug went unanswered. Did the kernel devs forget about it, or is it waiting for something? Also, I think the proper resolution is DUPLICATE, not NOTABUG, since the bug is real. *** This bug has been marked as a duplicate of bug 1079906 ***
The required changes were supposedly made to the kernel, but dnf does not remove the old version of kernel-devel (see https://bugzilla.redhat.com/show_bug.cgi?id=1079906#c18 which has not been responded to). Could someone check if that is a dnf bug?
The changes made for bug 1079906 are only in rawhide. They aren't in the f21 kernel from what I remember.
Yes, my question was in regard to the currently broken Rawhide behavior. I'm well aware that nothing has changed in F21.
Reopening since the question of whether https://bugzilla.redhat.com/show_bug.cgi?id=1079906#c18 is a dnf or kernel bug is still unanswered. If it's a kernel bug, please close this bug and report in the other bug that it's theirs, since the needinfo in that bug is also unanswered.
This bug appears to have been reported against 'rawhide' during the Fedora 22 development cycle. Changing version to '22'. More information and reason for this action is here: https://fedoraproject.org/wiki/Fedora_Program_Management/HouseKeeping/Fedora22
Josh or Andre, can anyone of you try dnf-0.6.4 in f21 and f22. The dnf is the same in these distros but if the result is different then kernel packaging is on a blame.
Jan: I'm waiting for something to happen as a result of https://bugzilla.redhat.com/show_bug.cgi?id=1079906#c30 . Hopefully a response to that should lead to this bug getting fixed.
There's no evidence that my dnf debug output in https://bugzilla.redhat.com/show_bug.cgi?id=1079906#c30 has been looked at, but that bug is assigned to kernel. Are there any dnf devs here who haven't looked at that yet who can do so?
Ok, so probably relate $ sudo dnf autoremove Last metadata expiration check performed 0:56:20 ago on Tue May 19 21:19:40 2015. Dependencies resolved. ================================================================================================================================================================================= Package Arch Version Repository Size ================================================================================================================================================================================= Removing: kernel-devel x86_64 4.0.3-300.fc22 @System 35 M kernel-modules-extra x86_64 4.0.3-300.fc22 @System 2.1 M Transaction Summary ================================================================================================================================================================================= Remove 2 Packages Installed size: 37 M Is this ok [y/N]:
Created attachment 1027484 [details] debugdata on autoremove
Hi Fabián, your report is fixed by bug 1201445 (This is fixed in code during installonly packages install process so you will see it fixed once you install all kernel* again). To completely synchronize all kernel* package versions during removal of packages over installonly_limit, we need to: * add "Suggests: kernel-modules-extras = <ver>" to kernel * add "Suggests: kernel-devel = <ver>" to kernel (bug 1226402) and then consider weak dependencies when looking which version of installonly package to remove.
Hey Jan, thanks for the heads up. So is it the same issue as what Andre was experiencing?
Fabián, no different. Your issue is bug 1201445.
Forgive me if it has been answered before (I read all the comments, but couldn't find an answer). A. Is losing all previous kernel-devels is intended behaviour? B. If not, are there any plans to fix it? C. Is there a way to force dnf to keep the old kernel-devels? I'm seeing the above on multiple F21 and F22 machines (all using dnf) and it drives us crazy. - Gilboa
Bumping Version to Rawhide since this is still not fixed. DNF still unconditionally removes the oldest version of kernel-devel, even if the corresponding kernel is running. (I provided the requested debugdata output in https://bugzilla.redhat.com/show_bug.cgi?id=1079906#c30 .)
This package has changed ownership in the Fedora Package Database. Reassigning to the new owner of this component.
*** This bug has been marked as a duplicate of bug 1298126 ***