RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 820674 - yum-debug-restore is confused with the number of restored kernels
Summary: yum-debug-restore is confused with the number of restored kernels
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: yum
Version: 6.2
Hardware: Unspecified
OS: Unspecified
low
low
Target Milestone: rc
: ---
Assignee: James Antill
QA Contact: Karel Srot
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2012-05-10 16:22 UTC by Karel Srot
Modified: 2014-01-21 06:25 UTC (History)
1 user (show)

Fixed In Version: yum-3.2.29-31.el6
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2013-02-21 10:12:44 UTC
Target Upstream Version:
Embargoed:

Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2013:0406 0 normal SHIPPED_LIVE yum bug fix and enhancement update 2013-02-20 20:50:44 UTC

Description Karel Srot 2012-05-10 16:22:54 UTC 
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).
Comment 2 James Antill 2012-05-10 20:35:52 UTC 
 Fix is upstream, in yum (in the limit install only code paths).
Comment 3 RHEL Program Management 2012-07-10 06:02:12 UTC 
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.
Comment 4 RHEL Program Management 2012-07-11 02:11:44 UTC 
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.
Comment 7 Karel Srot 2012-10-11 14:33:29 UTC 
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).
Comment 8 James Antill 2012-10-11 19:52:00 UTC 
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.
Comment 11 Karel Srot 2012-10-31 07:43:03 UTC 
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?
Comment 12 James Antill 2012-11-01 14:18:27 UTC 
 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).
Comment 13 Karel Srot 2012-11-01 15:11:12 UTC 
(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?
Comment 14 James Antill 2012-11-08 18:56:26 UTC 
> 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.
Comment 15 Karel Srot 2012-11-12 09:05:54 UTC 
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.
Comment 16 Karel Srot 2013-01-02 12:25:20 UTC 
(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.
Comment 19 errata-xmlrpc 2013-02-21 10:12:44 UTC 
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
Note You need to log in before you can comment on or make changes to this bug.