[CentOS] Yum not updating kernel

[Johnny Hughes]

Bob Taylor wrote:
> On Tue, 2008-02-26 at 16:09 -0600, Johnny Hughes wrote:
> 
> [snip]
>  
>>> Would anaconda even allow C5 to install on such a class cpu?
>> no ... and we have no i386 kernel ... no idea how that file got changed, 
>> but the only code to make it happen would be a pentium classic 
>> processor.  C5 would just die, as there is not one. (c4 too)
> 
> OK! Thanks Johnny. You just confirmed a bug here. Now I will, as time
> allows, see if I can discover why /etc/rpm/platform is incorrect. Since
> the file is in an rpm directory, shall I look at rpm? I promise *not* to
> begin another thread like this one! I'm a nice guy, really!
> 

This file (/etc/rpm/platform) is created by anaconda on install and is 
NOT owned by RPM or any other package.  It is USED by rpm to determine 
your real arch where there are possibly multiple arches (based on your 
processor type).

I[3,4,5,6]86 packages can coexist with each other in an i386 distro 
install, however you can not install an i386 package and another 
i[4,5,6]86 package with the same Name and Epoch-Version-Release (EVR) at 
the same time.  On Red Hat based distros, /etc/rpm/platform is used to 
define the main arch where more than one (based on the processor) could 
be main.

Also I[3,4,5,6]86 packages can exist in an x86_64 arch install and 
I[3,4,5,6]86 packages can exist in an ia64 arch install. These (x86_64 
and ia64) are 64bit/32bit library (aka multilib) arches.  They can have 
lib64 and lib directories and have both an i[3,4,5,6]86 package and an 
x86_64 (or ia64) package installed that have the same Name and EVR.

Other examples of 32bit/64bit (multilib) arches are s390 and s390x, ppc 
and ppc64, and finally sparc and sparc64.  In each of these you can have 
a 32bit (lib) and a 64bit (lib64) package of the same Name and EVR 
installed at the same time.


So, on x86_64, you CAN have glibc.x86_64 and glibc.i686. On sparc, you 
CAN have glibc.sparc and glibc.sparc64 .. but on i386 you CAN NOT have 
glibc.i386 and glibc.i686.

I can think of nothing that will (or should) change that file 
(/etc/rpm/platform) except running anaconda (the installer from a CentOS 
CD / DVD).

If something does modify that file it is definitely a bug.  Well, if you 
are BUILDING files with rpmbuild then sometimes on some of the multilib 
arches you might want to change /etc/rpm/platform to get specific 
results ... but that would be a controlled process and I know of no 
packages that do it automatically.

Some of the links by Ross seem to indicate that unixODBC-devel might 
impact /etc/rpm/platform ... however the version i386 version in 
centos-5 does not seem to as I have installed it several times for 
testing and it did not change my /etc/rpm/platform.

I have looked at several i386 machines, and all of them have an 
/etc/rpm/platform that is created on the install date, none of them have 
a file that has been modified.

If we can nail down something that changed /etc/rpm/platform it would be 
good, as that file should never change.

Thanks,
Johnny Hughes

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 252 bytes
Desc: OpenPGP digital signature
URL: <http://lists.centos.org/pipermail/centos/attachments/20080227/624154cc/attachment.sig>