Bug 484062 - RHN providing invalid updateinfo.xml ... arch=rpm for all package entries
RHN providing invalid updateinfo.xml ... arch=rpm for all package entries
Product: Red Hat Network
Classification: Red Hat
Component: RHN/Backend (Show other bugs)
RHN Stable
All Linux
urgent Severity urgent
: ---
: ---
Assigned To: Bryan Kearney
Red Hat Satellite QA List
: Security
Depends On:
  Show dependency treegraph
Reported: 2009-02-04 11:00 EST by kbrede
Modified: 2014-01-21 01:12 EST (History)
4 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2009-02-09 05:21:17 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description kbrede 2009-02-04 11:00:36 EST
Description of problem:

I used "yum --security update" in 5.2.  After upgrading to 5.3 I noticed "yum --security update" would not update the openlib package, even though it was marked as "critical."  I had to run "yum update" to upgrade openlib.  Today there are two critical updates, which won't install with "yum --security update": nss and nss-tools.  

So it appears as though yum isn't working with yum-security anymore.

Version-Release number of selected component (if applicable):


How reproducible:

Every time.

Steps to Reproduce:
1. Make sure a package is marked as critical.
2. Run "yum --security update"
Actual results:

No update is performed.

Expected results:

I expect the package to be upgraded with "yum --security update" and packages with bugs to be ignored.

Additional info:
Comment 1 James Antill 2009-02-04 11:15:40 EST
 How are you deciding that there are security updates available?


...doesn't show anything recent. What does "yum list-security" say?
Comment 2 James Antill 2009-02-04 11:21:21 EST
 Ok, it's the one labeled firefox:

Comment 3 kbrede 2009-02-04 11:27:39 EST
I'm looking at my RHN dashboard which shows two critical updates: 

Which are listed as:
which makes no sense.....

https://rhn.redhat.com/errata/rhel-server-errata.html shows a critical firefox update.  

Comment 4 James Antill 2009-02-04 11:30:39 EST
That isn't nss or nss-tools though, just the -devel packages ... and the RHSA-2009-0256 errata isn't in the updateinfo.xml data I get for Server 5.
Comment 5 kbrede 2009-02-04 11:53:17 EST
My RHN panel shows 20 RHEL 5 boxes with critical updates needing to be installed.

I ran "rhn-profile-sync" on one of the boxes and RHN is still reporting the critical update.

If the nss and nss-tools aren't critical updates, and RHN is showing nss and nss-tools as RHSA-2009:0256-6, then maybe RHN is just mislabeling?

At any rate all my RHEL5 boxes are trying to update nss and nss-tools when I run "yum update" even though nss and nss-tools isn't listed in https://rhn.redhat.com/rhn/errata/details/Details.do?eid=8266

Comment 6 James Antill 2009-02-04 11:55:26 EST
Ok, 2009-0256 is in the data I see now ... just spelled 2009:0256, trying to see what's happening on the yum side.
Comment 7 James Antill 2009-02-04 12:02:05 EST
 Ok, here's the problem ... the metadata has:

<package name="nss" version="" release="4.el5" epoch="0" arch="rpm" src="nss-">

...and arch="rpm" means that the plugin filters everything out as not an applicable arch.
Comment 8 James Antill 2009-02-04 12:26:47 EST
# xmllint --format /var/cache/yum/rhel-x86_64-server-5/updateinfo.xml.gz | fgrep 'arch="rpm"' | nl
     1          <package name="sysstat" version="7.0.2" release="3.el5" epoch="0
" arch="rpm" src="sysstat-7.0.2-3.el5.src.rpm">
  3902	        <package name="freetype-demos" version="2.2.1" release="19.el5" epoch="0" arch="rpm" src="freetype-2.2.1-19.el5.src.rpm">
Comment 11 Mark J. Cox (Product Security) 2009-02-06 10:06:19 EST
An update to the RHN metadata generation code to correct this issue is currently being tested.  The current plan is to deploy this update as soon as possible after it passes the QA process.
Comment 12 James Antill 2009-02-06 10:36:22 EST
It is worth noting that internal testing has confirmed that older versions of yum-security are not affected by this bug, because they do not look at the arch information in the updateinfo data. So downgrading yum-security is a viable workaround.
Comment 13 Mark J. Cox (Product Security) 2009-02-09 05:21:17 EST
This was addressed by an update made to RHN live on Friday (6th Feb).  Metadata being served today looks good.

kbrede, please reopen this ticket if you still encounter any problems.

Note You need to log in before you can comment on or make changes to this bug.