Description of problem: I want to have more than two kernel packages installed at the same time. This is because I have a driver that depends on a certain version, and I want to install the latest kernel while keeping older versions until the driver is available for a newer version. To that end I tried raising installonly_limit in yum.conf. The packages kernel-2.6.22.4-65.fc7 and kernel-2.6.22.5-76.fc7 are currently installed, and I'm trying to get 2.6.22.9-91.fc7 in. Two versions of the driver are also installed: one for kernel-2.6.22.4-65.fc7 and one for kernel-2.6.22.5-76.fc7. man yum.conf says that the default for installonlypkgs is a list of kernel packages and that the default for installonly_limit is 2. I concluded that these two parameters are what makes Yum keep the two latest kernels installed. I first set installonly_limit to 0 so that Yum would never remove a kernel automatically. When that didn't work I tried values like 3, 4, 6 and 10000, with no success. If installonly_limit is 1 or 2, Yum performs dependency resolution and then presents a list of packages to install and remove and asks for confirmation. If I answer "y", Yum fails with the message "ERROR with rpm_check_debug vs depsolve" because that driver needs /boot/vmlinuz-2.6.22.4-65.fc7. With any other value for installonly_limit, Yum instead fails during dependency resolution because the driver needs /boot/vmlinuz-2.6.22.5-76.fc7, so apparently Yum tries to remove the *newer* of the two installed kernel packages. Version-Release number of selected component (if applicable): yum-3.2.5-1.fc7
Can you publish the output when you set installonly_limit to 0 and when you set it to 2? It would be helpful to see the output of yum -d5 for both of those operations.
Created attachment 220311 [details] failure after confirmation Well, things have changed a little. I was unforgivably careless and erased the oldest kernel package, so now there's only one old kernel installed. This has the effect that yum fails at the later point only when installonly_limit is 1. When it's 0, 2 or 3 – or presumably any higher number – yum fails at the earlier point. Apparently it gets through the dependency resolution phase only if installonly_limit is a positive number less than or equal to the number of installed kernel packages. This attachment is what I get when installonly_limit is 1.
Created attachment 220321 [details] failure during dependency resolution And this is what I get when installonly_limit is some other number.
hmm, you're using 3.2.5 - could you grab 3.2.6 from updates-testing and retry, please? I made some changes to the kernel ver detection in that one which I think will help. thanks
Created attachment 224681 [details] yum-d5_3.2.6_limit_1_Linux_2.5.22.9 Do you detect the version of the running kernel? Then it might be significant that my results in comment 2 were produced with Linux 2.6.22.9 running. I had downloaded kernel-2.6.22.9-91.fc7 manually and installed it with RPM, bypassing Yum. To test yum -d5 I removed that package (and by mistake the oldest one too), but I didn't reboot. This time I have tested both with 2.6.22.9 running and with 2.6.22.5 running, in both cases with only the 2.6.22.5 package installed. Yum is version 3.2.6 from updates-testing. Under the same circumstances as last time (Linux 2.6.22.9 running but not installed), Yum 3.2.6 behaves exactly like Yum 3.2.5 did, but under the same circumstances as when I first reported this bug (Linux 2.6.22.5 runing) it fails during dependency resolution regardless of the value of installonly_limit. This is an improvement, but of course not enough as I still can't get it to install a new kernel. The only other difference between Yum 3.2.5 and 3.2.6 that I noticed was that when I ran yum remove kernel-2.6.22.9-91.fc7, Yum 3.2.6 correctly removed the corresponding version of the ipw3945 driver. With Yum 3.2.5 I had to add that to the command line. I see that Yum first tries to find an "update path" for the driver's dependency on the old kernel package, and then says "converted to install". It seems to do things in the wrong order. I would think it should convert the kernel update to installation *before* it tries to resolve dependencies on the old kernel. Here's the output when installonly_limit is 1 under Linux 2.5.22.9.
Created attachment 224691 [details] yum-d5_3.2.6_limit_1_Linux_2.5.22.5 And here's the output when installonly_limit is 1 under Linux 2.5.22.5, which is identical to the output for other values of installonly_limit under both kernels.
the dep resolution error is not related to this bug and is a red herring. It looks like installonly_limit is doing the right thing under 3.2.6. Please run the following for me: yum list installed kernel\* yum list available kernel\* yum list updates cat /etc/yum.conf | grep installonly uname -a thanks
# yum list installed kernel\* Loading "refresh-updatesd" plugin Installed Packages kernel.x86_64 2.6.22.5-76.fc7 installed kernel-devel.x86_64 2.6.22.9-91.fc7 installed kernel-devel.x86_64 2.6.22.5-76.fc7 installed kernel-headers.x86_64 2.6.22.9-91.fc7 installed # yum list available kernel\* Loading "refresh-updatesd" plugin Available Packages kernel.x86_64 2.6.22.9-91.fc7 updates kernel-debug.x86_64 2.6.22.9-91.fc7 updates kernel-debug-devel.x86_64 2.6.22.9-91.fc7 updates kernel-doc.noarch 2.6.22.9-91.fc7 updates kernel-kdump.x86_64 2.6.21-1.3194.fc7 fedora kernel-kdump-devel.x86_64 2.6.21-1.3194.fc7 fedora kernel-xen.x86_64 2.6.20-2936.fc7 updates kernel-xen-2.6-doc.noarch 2.6.20-2936.fc7 updates kernel-xen-devel.x86_64 2.6.20-2936.fc7 updates # yum list updates Loading "refresh-updatesd" plugin Updated Packages antlr.x86_64 2.7.7-1jpp.3.fc7.2 updates curl.i386 7.16.4-1.fc7 updates curl.x86_64 7.16.4-1.fc7 updates curl-devel.i386 7.16.4-1.fc7 updates curl-devel.x86_64 7.16.4-1.fc7 updates eclipse-cdt.x86_64 1:3.1.2-8.fc7 updates hpijs.x86_64 1:1.7.4a-6.fc7 updates hplip.x86_64 1.7.4a-6.fc7 updates kdebluetooth.x86_64 1.0-0.34.beta8.fc7 updates kernel.x86_64 2.6.22.9-91.fc7 updates libsane-hpaio.x86_64 1.7.4a-6.fc7 updates postgresql-libs.x86_64 8.2.5-1.fc7 updates postgresql-libs.i386 8.2.5-1.fc7 updates # cat /etc/yum.conf | grep installonly installonly_limit=0 # uname -a Linux dors.xn--rombobjrn-67a.se 2.6.22.5-76.fc7 #1 SMP Thu Aug 30 13:08:59 EDT 2007 x86_64 x86_64 x86_64 GNU/Linux Yum 3.2.6 is not doing the right thing. It fails to install kernel updates. If the dependency resolution error is unrelated then what prevents Yum from installing the update?
In case somebody out there cares about this problem, here's an interesting observation: I have Yum 3.2.7 now, and I discovered by pure accident that Yum fails to install kernel updates only when there is a driver package installed for the latest kernel installed. If there are several kernel packages installed, and driver packages are installed for older kernels but not for the latest kernel that's installed, then Yum can successfully install a new kernel and seems to obey installonly_limit. I'm starting to think that this behavior is actually intended as some kind of feature, and that the bug that remains in Yum 3.2.7 is only that the error message is completely backwards and very misleading, but in that case I have to wonder why Seth Vidal doesn't simply explain this.
1. yum doesn't run a transaction unless everything in the transaction has been successfully dependency solved 2. If you are going to use (kmdl) kernel modules you have to use the kernel-module plugin to make sure you get later ones installed/removed. That's really what this comes down to. yum install yum-kernel-module and see if your problem gets better.
"yum doesn't run a transaction unless everything in the transaction has been successfully dependency solved" Neither does RPM. I have always assumed that the definition of "dependency" is the same in Yum as in RPM. It seemed like a very reasonable assumption given that the purpose of Yum is to resolve dependencies for RPM. But apparently the definitions of "dependency" differ, because in this case Yum rejects a transaction that RPM happily runs. OK, so Yum tries to ensure that kernel modules get updated together with the kernel. That's a good idea, but something must be done about the error message. It says "Missing Dependency: X is needed by package Y". Normally that means that Yum tried to install Y but X wasn't available. When both X and Y are already installed the only way I can read it is that Yum tried to remove X. Therefore I thought Yum ignored installonly_update and tried to remove old kernel packages. When X is in the installonlypkgs list the message should instead be "Missing co-update: An update to kernel won't be installed because there is no corresponding update to Y."
"Missing Dependency: X is needed by package Y" Can also mean that you cant update packet X to a new version, because packet Y need the old version of X. There is a lot of cases, so it is hard to give a message describing the cause of why there is a missing dependency. Another way to read it is. If where do this Transaction then we will have a "Missing Dependency: X is needed by package Y" So this is why we don't do it, because we don't want to break your system.
That's *exactly* what I thought it meant, and that's why I thought Yum ignored installonly_update and tried to remove old kernel packages. When X is in the installonlypkgs list, then Yum is *not* supposed to update X; it's supposed to *install* the new version *without* removing the one that's already installed. That Y needs the old X is then *not* a problem in itself, because the old X *will still be there*. The dependency will *not* be missing. If, on the other hand, X were to be updated the usual way, then the dependency would be broken, and now yum says the dependency would be broken, so I draw the conclusion that Yum tried to update X the usual way. That conclusion is wrong, and therefore the message is wrong. You say it's hard? Yes, writing programs of good quality is hard. If it were easy there wouldn't be so many companies selling garbage and calling it software.
Björn, Your hostility to Tim is not necessary or warranted. We're trying to solve this problem but it is not a trivial issue to work with. I ask that you test the behavior you're seeing on yum 3.2.12 from rawhide and let us know if the problem persists. We've fixed a lot of problems since november.
This message is a reminder that Fedora 7 is nearing the end of life. Approximately 30 (thirty) days from now Fedora will stop maintaining and issuing updates for Fedora 7. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as WONTFIX if it remains open with a Fedora 'version' of '7'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version prior to Fedora 7's end of life. Bug Reporter: Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 7 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora please change the 'version' of this bug. If you are unable to change the version, please add a comment here and someone will do it for you. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. If possible, it is recommended that you try the newest available Fedora distribution to see if your bug still exists. Please read the Release Notes for the newest Fedora distribution to make sure it will meet your needs: http://docs.fedoraproject.org/release-notes/ The process we are following is described here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping