[root@elvis root]# up2date --show-channels
[root@elvis root]# up2date --showall | grep redhat-release-as
However, if you look at this packge, you'll see it's the
redhat-release package for 2.1AS for ia64 ('Derry' in
/etc/redhat-release, the ia64 release notes, etc.)
Not sure how this ended up in the i386 channel. What's in the i386 U4
tree is correct; as is the version Jay Turner posted to RHN via his
DIFF file at:
rpm -pqi redhat-release-as-2.1AS-11.noarch.rpm
Name : redhat-release-as Relocations: (not relocateable)
Version : 2.1AS Vendor: Red Hat, Inc.
Release : 11 Build Date: Wed 14 Apr
2004 03:28:53 PM EDT
Install date: (not installed) Build Host:
Group : System Environment/Base Source RPM:
Size : 117113 License: GPL
Signature : DSA/SHA1, Fri 16 Apr 2004 02:45:22 PM EDT, Key ID
219180cddb42a60ePackager : Red Hat, Inc.
Summary : Pensacola release file
Pensacola release file
If I recall correctly what happened was this package was originally
released for ia64 with that NVRE, then when the i386 errata was
released the release was not incremented and it conflicted when
uploaded. Somebody signed off on that as being ok (I guess since the
NVRE was the same) but in reality only the ia64 one was there and got
associated with the i386 channel since it was the package that was there.
I think the correction is to errata a newer redhat release for i386
that is the correct package but I'll defer to misa on that being the
correct course of action.
This is apparently breaking satellite provisioning kickstarts as well
now b/c of the headers differeing between the hdlist/anaconda and the
package in the channel.
The fix is as follows:
push the correct redhat-release package from the authoritative i386
tree into production RHN. This will allow satellites to
kickstart/provision correctly (with some possible minor resyncing on
This will however put the i386 package into the ia64 channel (since
they share an NVRE) We may want to fix this long term by errataing a
new version of the redhat-release package for both i386 and ia64 (or
potentially only ia64)