Description of problem:
I'm doing a fresh install of FC5, followed by "yum update." Yum
wants to install the i686 version of 2.6.16-1.2096_FC5, but wants
the i586 version of kernel-devel.
Version-Release number of selected component (if applicable):
How reproducible: Very
Steps to Reproduce:
1. Fresh install of FC5
2. Run "yum update"
Packages offered include:
bind-config i386 30:9.3.2-16.FC5 updates-released 50 k
replacing caching-nameserver.noarch 7.3-5.FC5
kernel i686 2.6.16-1.2096_FC5 updates-released 13 M
kernel-devel i586 2.6.16-1.2096_FC5 updates-released 4.6 M
Both kernel and kernel-devel should be i686
This worked fine in FC3 and FC4
send the output of these things:
yum list kernel\*
[root@kickstart5 ~]# cat /etc/rpm/platform
[root@kickstart5 ~]# uname -a
Linux kickstart5.ih.lucent.com 2.6.15-1.2054_FC5 #1 Tue Mar 14 15:48:33 EST 2006
i686 i686 i386 GNU/Linux
[root@kickstart5 ~]# yum list kernel\*
Setting up repositories
base 100% |=========================| 1.1 kB 00:00
updates-released 100% |=========================| 951 B 00:00
extras 100% |=========================| 1.1 kB 00:00
Reading repository metadata in from local files
kernel.i686 2.6.15-1.2054_FC5 installed
kernel-devel.i686 2.6.16-1.2096_FC5 installed
kernel.i686 2.6.16-1.2096_FC5 updates-released
kernel.i586 2.6.16-1.2096_FC5 updates-released
kernel-debuginfo.i686 2.6.16-1.2096_FC5 updates-released
kernel-debuginfo.i586 2.6.16-1.2096_FC5 updates-released
kernel-devel.i586 2.6.16-1.2096_FC5 updates-released
kernel-doc.noarch 2.6.16-1.2096_FC5 updates-released
kernel-kdump.i686 2.6.16-1.2096_FC5 updates-released
kernel-kdump-devel.i686 2.6.16-1.2096_FC5 updates-released
kernel-smp.i586 2.6.16-1.2096_FC5 updates-released
kernel-smp.i686 2.6.16-1.2096_FC5 updates-released
kernel-smp-devel.i686 2.6.16-1.2096_FC5 updates-released
kernel-smp-devel.i586 2.6.16-1.2096_FC5 updates-released
kernel-xen0.i686 2.6.16-1.2096_FC5 updates-released
kernel-xen0-devel.i686 2.6.16-1.2096_FC5 updates-released
kernel-xenU.i686 2.6.16-1.2096_FC5 updates-released
kernel-xenU-devel.i686 2.6.16-1.2096_FC5 updates-released
A couple additional notes:
1) The problem can be "repaired" using
yum remove kernel-devel
yum install kernel-devel
In my previous note (with the output of "yum list kernel\*" that fix has
been made. I'll have to do a fresh install to get back to the state where
the i586 kernel-devel is installed.
2) I'm wondering if this is really an anaconda problem. I thought I checked
this before writing the bug report, but the i586 version of kernel-devel
was actually installed by the kickstart. So, if the i586 version of
kernel-devel was already installed, maybe yum is doing the "right" thing by
updating to the newer i586 version.
Yes, If yum finds a package previous installed with a architecture, it merely
updates that as this is arguably the most logical thing to do. While installing
a fresh package, it verifies the architecture and installs a appropriate package.
One could argue that yum should verify and fix any architecture issues even on
package updates but with multi architecture packages this might not be easy or
If you havent specified a architecture explicts in kickstart and Anaconda
installed a wrong kernel package, please open a new bug report against Anaconda
and refer to this report.
I will leave this report open for the package maintainer's decision on this.
Yeah, I think that keeping to what's installed is almost certainly the "right"
thing so that people can more easily tailor a filesystem for, eg, nfsroot usage
or things of that nature.
Note that this is a completely fresh install (no "previously installed"
packages). I agree that it's not yum's responsibility to fix the problem, so
maybe this bug should be tagged to anaconda instead of yum. Why is the
kickstart installing the 686 version of kernel and the 586 version of kernel-devel?
I didn't realize there was a way to specify the architecture in the kickstart
file (how do I do that??) but shouldn't it default to using 686 for everything
if that't the actual hardware it's running on?
You can specify the arch in kickstart (name.arch, just like on the yum command
line). And there was a bug in anaconda in FC5 where this situation could
happen, but we fixed it a month or two ago.
Do you have a reference for the bug mentioned in comment 7? It's not clear what
is meant by "this situation" getting fixed, but it sounds like it could be related.