Description of problem: Bug 737597 allowed yum-debug-restore to restore multiple installonly packages. But when restoring them, yum is trying to keep installonly_limit and removes packages that are present in the system. Moreover, yum is restoring multiple packages but believes that just one will be installed. Version-Release number of selected component (if applicable): yum-utils-1.1.30-14.el6 How reproducible: always ===================================== # rpm -i ... kernel-unsupported-2.6.32-1.noarch.rpm kernel-unsupported-2.6.32-2.noarch.rpm kernel-unsupported-2.6.32-3.noarch.rpm kernel-unsupported-2.6.32-4.noarch.rpm kernel-unsupported-2.6.32-5.noarch.rpm kernel-unsupported-2.6.32-6.noarch.rpm kernel-unsupported-2.6.32-7.noarch.rpm # yum-debug-dump --norepos # rpm -e kernel-unsupported-2.6.32-1 # rpm -e kernel-unsupported-2.6.32-2 # rpm -e kernel-unsupported-2.6.32-3 # rpm -e kernel-unsupported-2.6.32-4 # yum-debug-restore /tmp/tmp.VrMqMXUZpN/yum_debug_dump-XXX.txt.gz ... ... --> Running transaction check ---> Package kernel-unsupported.noarch 0:2.6.32-1 will be installed ---> Package kernel-unsupported.noarch 0:2.6.32-2 will be installed ---> Package kernel-unsupported.noarch 0:2.6.32-3 will be installed ---> Package kernel-unsupported.noarch 0:2.6.32-4 will be installed --> Finished Dependency Resolution --> Running transaction check ---> Package kernel-unsupported.noarch 0:2.6.32-5 will be erased --> Finished Dependency Resolution ... ... # rpm -qa | grep kernel-unsupported kernel-unsupported-2.6.32-7.noarch kernel-unsupported-2.6.32-6.noarch kernel-unsupported-2.6.32-1.noarch kernel-unsupported-2.6.32-2.noarch kernel-unsupported-2.6.32-3.noarch kernel-unsupported-2.6.32-4.noarch So yum believed that he is installing one package and therefore removed one out of 3 installed to keep the installonly_limit = 3. I am not sure what should be the correct behavior though. Maybe ignore the limit in case of debug restore (since I want to restore to the same state).
Fix is upstream, in yum (in the limit install only code paths).
This request was not resolved in time for the current release. Red Hat invites you to ask your support representative to propose this request, if still desired, for consideration in the next release of Red Hat Enterprise Linux.
This request was erroneously removed from consideration in Red Hat Enterprise Linux 6.4, which is currently under development. This request will be evaluated for inclusion in Red Hat Enterprise Linux 6.4.
Hi James, how the fix is supposed to work? In my case with 7 kernels, 3 removed after yum-debug-restore those 3 kernels are installed back but remaining four are uninstalled (in the end I have 3 kernels instead of 7 as before).
So the way it works is: 1. We count the number of pkgs. of name N to be installed. 2. We count the number of pkgs. of name N already installed. 3. We work out "how many should we remove" by doing "(#1 + #2) - installonly_limit" ... but limit it to #1 that aren't running. ...so I'm not entirely sure what your test case is, but if you had 7 installed a limit of 4 and 5 to be installed ... then yum would remove everything but the running kernel, and install all five of the new ones (so you'd have 6 installed at the end ... which is over the limit). But that is if all the kernels had the same package name ... if they have different name then each name gets a limit.
I see... For correct behavior both yum and yum-utils has to be updated. Fixing yum side only has unfortunate consequences and the debug-restore behavior is IMHO worse than without the fix. I would propose to file a new yum-utils bug and move this (yum) bug to the next release. James, do you agree?
I'm happy to ACK any new bugs to get the other changes in, dito. for load-ts. But I think that the 6.4 behaviour will be better in most normal cases (Eg. current kernels installed is less than installonly_limit) ... it's only when you are already over the limit already that it might be worse and IIRC the new behaviour is much better than you have different sets of kernel packages (also seems bad to have this behaviour in RHEL-5 but not RHEL-6).
(In reply to comment #12) > But I think that the 6.4 behaviour will be better in most normal > cases (Eg. current kernels installed is less than installonly_limit) ... What would be the difference in this case? According to my observations the "old" yum believes that he is installing/restoring just one kernel (even if he is installing more). "new" yum knows that he is installing more kernels but since we would be below the installonly limit anyway, there should not be no difference. Or did I miss something?
> What would be the difference in this case? According to my observations the "old" yum believes that he is installing/restoring just one kernel (even if he is installing more) Sorry, was trying to remember the bug(s) we'd fixed and getting confused. Yeh, that is the only real thing we fixed IIRC (although we did the loop multiple times, which seems like it might cause problems, anyway...). Just meant that I didn't think the new behaviour was worse than the old ... and having it old in RHEL-6 and new in RHEL-5 seemed bad.
OK then, let's stick with the new behavior. I have filed a yum-utils bug 820674 regarding the fix on the yum-utils side.
(In reply to comment #15) > OK then, let's stick with the new behavior. I have filed a yum-utils bug > 820674 regarding the fix on the yum-utils side. Correct bug number is bug 875630.
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. http://rhn.redhat.com/errata/RHBA-2013-0406.html