[CentOS] Yum not updating kernel

Ross S. W. Walker rwalker at medallion.com
Wed Feb 27 20:27:26 UTC 2008


Bob Taylor wrote:
> On Wed, 2008-02-27 at 06:29 -0600, Johnny Hughes wrote:
> > Bob Taylor wrote:
> 
> [snip]
> 
> > > 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 again Johnny for the info. The only non-rpm I recall installing
> was the cups *.tgs for my printer which I had to compile. :-(

I'd be interested in seeing a complete /var/log/yum.log file
and the date of the last successful yum update.

-Ross

______________________________________________________________________
This e-mail, and any attachments thereto, is intended only for use by
the addressee(s) named herein and may contain legally privileged
and/or confidential information. If you are not the intended recipient
of this e-mail, you are hereby notified that any dissemination,
distribution or copying of this e-mail, and any attachments thereto,
is strictly prohibited. If you have received this e-mail in error,
please immediately notify the sender and permanently delete the
original and any copy or printout thereof.




More information about the CentOS mailing list