It seems everybody is out of ideas why yum is not updating the kernel. The following kernels are installed in /boot:
vmlinuz-2.6.18-8.1.14.el5 vmlinuz-2.6.18-8.el5
I originally installed CentOS 5.0 via CD. Yum automatically updated to 5.1 including kernel-2.6.18-8.1.14.el5.
I have traced the kernels from kernel-2.6.18-8.el5 to kernel-2.6.18-8.1.14.el5. Yum stopped updating at this point. kernel-2.6.18-8.1.14.el5 was installed Oct 10, 2007 according to yum.log. It seems I installed rpmforge.repo around October 13, 2007. The installation included two files. rpmforge.repo and mirrors-rpmforge. The contents of rpmforge.repo is:
# Name: RPMforge RPM Repository for Red Hat Enterprise 5 - dag # URL: http://rpmforge.net/ [rpmforge] name = Red Hat Enterprise $releasever - RPMforge.net - dag #baseurl = http://apt.sw.be/redhat/el5/en/$basearch/dag mirrorlist = http://apt.sw.be/redhat/el5/en/mirrors-rpmforge #mirrorlist = file:///etc/yum.repos.d/mirrors-rpmforge enabled = 1 priority = 99 protect = 0 gpgkey = file:///etc/pki/rpm-gpg/RPM-GPG-KEY-rpmforge-dag gpgcheck = 1
Other than the priority is not needed, does any of the previous ring a bell? Still frustrated.
I received the following this morning:
/etc/cron.daily/yum.cron:
Error: Cannot find a valid baseurl for repo: base Could not retrieve mirrorlist http://mirrorlist.centos.org/?release=5&arch=i386&repo=os error was [Errno 14] HTTP Error 505: DNS lookup error Could not retrieve mirrorlist http://mirrorlist.centos.org/?release=5&arch=i386&repo=os error was [Errno 14] HTTP Error 506: Failure To Connect To Web Server
Has CentOS.org changed their url?
On Fri, Feb 22, 2008 at 1:02 PM, Bob Taylor bob8221@gmail.com wrote:
It seems everybody is out of ideas why yum is not updating the kernel. The following kernels are installed in /boot:
vmlinuz-2.6.18-8.1.14.el5 vmlinuz-2.6.18-8.el5
I originally installed CentOS 5.0 via CD. Yum automatically updated to 5.1 including kernel-2.6.18-8.1.14.el5.
The kernel that came with CentOS 5.1 was kernel-2.6.18-53. Could you post your:
/etc/yum.repos.d/CentOS-Base.repo
Akemi
On Fri, 2008-02-22 at 14:41 -0800, Akemi Yagi wrote:
On Fri, Feb 22, 2008 at 1:02 PM, Bob Taylor bob8221@gmail.com wrote:
It seems everybody is out of ideas why yum is not updating the kernel. The following kernels are installed in /boot:
vmlinuz-2.6.18-8.1.14.el5 vmlinuz-2.6.18-8.el5
I originally installed CentOS 5.0 via CD. Yum automatically updated to 5.1 including kernel-2.6.18-8.1.14.el5.
The kernel that came with CentOS 5.1 was kernel-2.6.18-53. Could you post your:
/etc/yum.repos.d/CentOS-Base.repo
I misspoke. Yum installed kernel-2.6.18-8.1.14 October 13, 2007 according to yum.log. So, yum appears to have worked *once* updating the kernel. Looking in CentOS vault, I saw .15 which gives me a time frame for what it's worth. All I did was add rpmforge. I have removed it with no help. I will post any file related to this mystery when requested. Time wise, I have spent at least 4 days attempting to locate this failure. Here is the file you requested:
# CentOS-Base.repo # # This file uses a new mirrorlist system developed by Lance Davis for CentOS. # The mirror system uses the connecting IP address of the client and the # update status of each mirror to pick mirrors that are updated to and # geographically close to the client. You should use this for CentOS updates # unless you are manually picking other mirrors. # # If the mirrorlist= does not work for you, as a fall back you can try the # remarked out baseurl= line instead. # #
[base] name=CentOS-$releasever - Base mirrorlist=http://mirrorlist.centos.org/?release=$releasever&arch= $basearch&repo =os #baseurl=http://mirror.centos.org/centos/$releasever/os/$basearch/ gpgcheck=1 gpgkey=http://mirror.centos.org/centos/RPM-GPG-KEY-CentOS-5 priority=1 protect=1
#released updates [updates] name=CentOS-$releasever - Updates mirrorlist=http://mirrorlist.centos.org/?release=$releasever&arch= $basearch&repo =updates #baseurl=http://mirror.centos.org/centos/$releasever/updates/$basearch/ gpgcheck=1 gpgkey=http://mirror.centos.org/centos/RPM-GPG-KEY-CentOS-5 priority=1 protect=1
#packages used/produced in the build but not released [addons] name=CentOS-$releasever - Addons mirrorlist=http://mirrorlist.centos.org/?release=$releasever&arch= $basearch&repo =addons #baseurl=http://mirror.centos.org/centos/$releasever/addons/$basearch/ gpgcheck=1 gpgkey=http://mirror.centos.org/centos/RPM-GPG-KEY-CentOS-5 priority=1 protect=0 #additional packages that may be useful [extras] name=CentOS-$releasever - Extras mirrorlist=http://mirrorlist.centos.org/?release=$releasever&arch= $basearch&repo =extras #baseurl=http://mirror.centos.org/centos/$releasever/extras/$basearch/ gpgcheck=1 gpgkey=http://mirror.centos.org/centos/RPM-GPG-KEY-CentOS-5 priority=1 protect=0
#additional packages that extend functionality of existing packages [centosplus] name=CentOS-$releasever - Plus mirrorlist=http://mirrorlist.centos.org/?release=$releasever&arch= $basearch&repo =centosplus #baseurl=http://mirror.centos.org/centos/$releasever/centosplus/$basearch/ gpgcheck=1 enabled=1 gpgkey=http://mirror.centos.org/centos/RPM-GPG-KEY-CentOS-5 priority=2 protect=0
On Fri, 2008-02-22 at 15:37 -0800, Bob Taylor wrote:
On Fri, 2008-02-22 at 14:41 -0800, Akemi Yagi wrote:
On Fri, Feb 22, 2008 at 1:02 PM, Bob Taylor bob8221@gmail.com wrote:
<snip>
<snip>
# CentOS-Base.repo # # This file uses a new mirrorlist system developed by Lance Davis for CentOS. # The mirror system uses the connecting IP address of the client and the # update status of each mirror to pick mirrors that are updated to and # geographically close to the client. You should use this for CentOS updates # unless you are manually picking other mirrors. # # If the mirrorlist= does not work for you, as a fall back you can try the # remarked out baseurl= line instead. # #
[base] name=CentOS-$releasever - Base mirrorlist=http://mirrorlist.centos.org/?release=$releasever&arch= $basearch&repo =os #baseurl=http://mirror.centos.org/centos/$releasever/os/$basearch/ gpgcheck=1 gpgkey=http://mirror.centos.org/centos/RPM-GPG-KEY-CentOS-5 priority=1 protect=1
Priority *and* protect? Supposed to be a no-no.
Worse, it's on the updates too. I would carefully examine all your repo defs and have *either* protect or priority, but not both. Also make sure the settings are appropriate sionce you've add some other repos.
I've been using Rpmforge for a long time, NP. But at the time I established priorities, I disabled all protect settings.
And there are a couple exclude and include setups for a few special instances.
#released updates [updates] name=CentOS-$releasever - Updates mirrorlist=http://mirrorlist.centos.org/?release=$releasever&arch= $basearch&repo =updates #baseurl=http://mirror.centos.org/centos/$releasever/updates/$basearch/ gpgcheck=1 gpgkey=http://mirror.centos.org/centos/RPM-GPG-KEY-CentOS-5 priority=1 protect=1
Conflict?
<snip>
HTH
On Fri, 2008-02-22 at 19:56 -0500, William L. Maltby wrote:
On Fri, 2008-02-22 at 15:37 -0800, Bob Taylor wrote:
On Fri, 2008-02-22 at 14:41 -0800, Akemi Yagi wrote:
On Fri, Feb 22, 2008 at 1:02 PM, Bob Taylor bob8221@gmail.com wrote:
<snip>
<snip>
[snip]
Priority *and* protect? Supposed to be a no-no.
Worse, it's on the updates too. I would carefully examine all your repo defs and have *either* protect or priority, but not both. Also make sure the settings are appropriate sionce you've add some other repos.
Thanks for your response, Bill. I added the protect lines attempting to locate this problem. I've removed all protect lines.
I've been using Rpmforge for a long time, NP. But at the time I established priorities, I disabled all protect settings.
And there are a couple exclude and include setups for a few special instances.
Mind telling me what these are?
Bob Taylor wrote:
On Fri, 2008-02-22 at 19:56 -0500, William L. Maltby wrote:
On Fri, 2008-02-22 at 15:37 -0800, Bob Taylor wrote:
On Fri, 2008-02-22 at 14:41 -0800, Akemi Yagi wrote:
On Fri, Feb 22, 2008 at 1:02 PM, Bob Taylor bob8221@gmail.com wrote:
<snip>
<snip>
[snip]
Priority *and* protect? Supposed to be a no-no.
Worse, it's on the updates too. I would carefully examine all your repo defs and have *either* protect or priority, but not both. Also make sure the settings are appropriate sionce you've add some other repos.
Thanks for your response, Bill. I added the protect lines attempting to locate this problem. I've removed all protect lines.
I've been using Rpmforge for a long time, NP. But at the time I established priorities, I disabled all protect settings.
And there are a couple exclude and include setups for a few special instances.
Mind telling me what these are?
"protect=N" is part of the protectbase plugin. You do not want to install the protectbase and priorities plugins on the same machine.
Looking at your output of yum-* you do not seem to have yum-protectbase installed, so the settings by themselves should not matter.
On Fri, 2008-02-22 at 23:45 -0800, Bob Taylor wrote:
On Fri, 2008-02-22 at 19:56 -0500, William L. Maltby wrote:
On Fri, 2008-02-22 at 15:37 -0800, Bob Taylor wrote:
On Fri, 2008-02-22 at 14:41 -0800, Akemi Yagi wrote:
On Fri, Feb 22, 2008 at 1:02 PM, Bob Taylor bob8221@gmail.com wrote:
<snip>
<snip>
[snip]
Priority *and* protect? Supposed to be a no-no.
Worse, it's on the updates too. I would carefully examine all your repo defs and have *either* protect or priority, but not both. Also make sure the settings are appropriate sionce you've add some other repos.
Thanks for your response, Bill. I added the protect lines attempting to locate this problem. I've removed all protect lines.
I've been using Rpmforge for a long time, NP. But at the time I established priorities, I disabled all protect settings.
And there are a couple exclude and include setups for a few special instances.
Mind telling me what these are?
S/B nothing of interest, but here's a condensed version.
============== Useless/uninteresting lines snipped ===================== [rpmforge] name = Red Hat Enterprise $releasever - RPMforge.net - dag mirrorlist = http://apt.sw.be/redhat/el4/en/mirrors-rpmforge enabled = 1 gpgkey = file:///etc/pki/rpm-gpg/RPM-GPG-KEY-rpmforge-dag gpgcheck = 1 # NEXT LINE WRAPPED - CAREFUL protect=0 priority=10 includepkgs=bittorrent.noarch, bittorrent- gui.noarch, python-khashmir.noarch, python-crypto.i386 rtorrent, libtorrent.i386, libtorrent-devel.i386, libsigc*, mplayer.i386, mplayer- docs.i386, mplayer-fonts.noarch, mplayerplug-in.i386, aalib.i386, faac.i386, lame.i386, libXvMCW.i386, libdvdnav.i386, libmad.i386, libmpcdec.i386, lirc.i386, lzo.i386, openal.i386, x264.i386, xvidcore.i386, libmp4v2.i386 gkrellm.i386 # mplayer-skins.noarch, ==========================================================================
Some of the above may not be appropriate any more - I've not looked in awhile.
On Sat, 2008-02-23 at 06:25 -0500, William L. Maltby wrote:
On Fri, 2008-02-22 at 23:45 -0800, Bob Taylor wrote:
[snip]
============== Useless/uninteresting lines snipped ===================== [rpmforge] name = Red Hat Enterprise $releasever - RPMforge.net - dag mirrorlist = http://apt.sw.be/redhat/el4/en/mirrors-rpmforge enabled = 1 gpgkey = file:///etc/pki/rpm-gpg/RPM-GPG-KEY-rpmforge-dag gpgcheck = 1 # NEXT LINE WRAPPED - CAREFUL protect=0 priority=10 includepkgs=bittorrent.noarch, bittorrent- gui.noarch, python-khashmir.noarch, python-crypto.i386 rtorrent, libtorrent.i386, libtorrent-devel.i386, libsigc*, mplayer.i386, mplayer- docs.i386, mplayer-fonts.noarch, mplayerplug-in.i386, aalib.i386, faac.i386, lame.i386, libXvMCW.i386, libdvdnav.i386, libmad.i386, libmpcdec.i386, lirc.i386, lzo.i386, openal.i386, x264.i386, xvidcore.i386, libmp4v2.i386 gkrellm.i386 # mplayer-skins.noarch, ==========================================================================
Some of the above may not be appropriate any more - I've not looked in awhile.
Someone just said *not* to use protect and priority together.
Red Hat has a propensity to remove any documentation on a package that does not have a man page. Sometimes it's included in /usr/share/doc and sometimes in /usr/lib and sometimes it's just not there. There is, hopefully *some* documentation on plugins other than how to write one. I would like to know *what* plugins actually *do*.
Someone just said *not* to use protect and priority together.
Red Hat has a propensity to remove any documentation on a package that does not have a man page. Sometimes it's included in /usr/share/doc and sometimes in /usr/lib and sometimes it's just not there. There is, hopefully *some* documentation on plugins other than how to write one. I would like to know *what* plugins actually *do*.
At this point I don't think it even matters. You need to just get back to the simplest configuration possible. That means:
* Remove ALL plugins * Disable ALL third party repo's. * Do a yum clean all * Revert to the default CentOS .repo files * Revert to default yum.conf file
If it works in this configuration, you can start adding things back one at a time.
Maybe you've already tried this, I don't know. It's been a long thread. :)
Ray
On Sat, 2008-02-23 at 10:54 -0800, Ray Van Dolson wrote:
- Remove ALL plugins
- Disable ALL third party repo's.
- Do a yum clean all
- Revert to the default CentOS .repo files
- Revert to default yum.conf file
If it works in this configuration, you can start adding things back one at a time.
I reached the same conclusion Saturday myself. I yum remove yum and reinstalled yum & pirut from my installation CD. The yum refused to update the kernel. I gave up on yum and downloaded the current kernel rpm. I rpm -i kernel* and received the following error message from rpm:
package kernel-2.6.18-53.1.13.el5 is intended for a i686 architecture
There is my problem! uname -ipm results in i686 i686 i386. It looks like yum is looking at uname -i.
Maybe you've already tried this, I don't know. It's been a long thread. :)
I agree. Waaay to long. Now what do the experts have to say about this? All packages *except* the kernel files are i386. I want to end this, please?
I reached the same conclusion Saturday myself. I yum remove yum and reinstalled yum & pirut from my installation CD. The yum refused to update the kernel. I gave up on yum and downloaded the current kernel rpm. I rpm -i kernel* and received the following error message from rpm:
package kernel-2.6.18-53.1.13.el5 is intended for a i686 architecture
There is my problem! uname -ipm results in i686 i686 i386. It looks like yum is looking at uname -i.
Mine reports the same as yours and I have no problem updating kernels.
Maybe you've already tried this, I don't know. It's been a long thread. :)
I agree. Waaay to long. Now what do the experts have to say about this? All packages *except* the kernel files are i386. I want to end this, please?
Something is missing. It's probably something very simple. I still think you should let someone log in as root into your box and figure it out for you. :)
Ray
On Monday 25 February 2008, Ray Van Dolson wrote:
I reached the same conclusion Saturday myself. I yum remove yum and reinstalled yum & pirut from my installation CD. The yum refused to update the kernel. I gave up on yum and downloaded the current kernel rpm. I rpm -i kernel* and received the following error message from rpm:
package kernel-2.6.18-53.1.13.el5 is intended for a i686 architecture
This is a very good clue, even rpm dislikes the concept of upgrading (installing) your kernel. :-). Was this an error message (package was not installed) or a warning (package was installed), check with rpm -q kernel.
...
I agree. Waaay to long. Now what do the experts have to say about this? All packages *except* the kernel files are i386. I want to end this, please?
Something is missing. It's probably something very simple. I still think you should let someone log in as root into your box and figure it out for you. :)
That was the dumbest piece of advice so far.
/Peter
On Sun, 2008-02-24 at 22:55 -0800, Ray Van Dolson wrote:
[snip]
Mine reports the same as yours and I have no problem updating kernels.
Sigh! So I have the same problem with rpm? It rejects installing an i686 rpm.
[snip]
Something is missing. It's probably something very simple. I still think you should let someone log in as root into your box and figure it out for you. :)
I would love this. However I don't know what my IP is nor how to find out. It's been too long and too much has changed.
Something is missing. It's probably something very simple. I still think you should let someone log in as root into your box and figure it out for you. :)
I would love this. However I don't know what my IP is nor how to find out. It's been too long and too much has changed.
Seriously?
ifconfig will tell you your IP address. Or just go to www.whatsmyip.org or some similar site...
Or, just reinstall :)
On Mon, 2008-02-25 at 00:19 -0800, Ray Van Dolson wrote:
I would love this. However I don't know what my IP is nor how to find out. It's been too long and too much has changed.
Seriously?
ifconfig will tell you your IP address. Or just go to www.whatsmyip.org or some similar site...
Wow! Thanks Ray
Or, just reinstall :)
I *do* have a sense of humor. :-)
Bob Taylor wrote:
On Mon, 2008-02-25 at 00:19 -0800, Ray Van Dolson wrote:
I would love this. However I don't know what my IP is nor
how to find
out. It's been too long and too much has changed.
Seriously?
ifconfig will tell you your IP address. Or just go to www.whatsmyip.org or some similar site...
Wow! Thanks Ray
Or, just reinstall :)
I *do* have a sense of humor. :-)
Bob,
Lets get this fixed so we can kill this thread.
Can you include the output of these commands:
# cat /etc/redhat-release
# yum list installed '*yum*'
# cat /etc/yum.conf
# cat /etc/yum.repos.d/CentOS-Base.repo
From these we should be able to determine if your base installation
is correct.
If it isn't a config problem then we can look at permissions and network next.
-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.
On Mon, 2008-02-25 at 12:41 -0500, Ross S. W. Walker wrote:
[snip]
Bob,
Lets get this fixed so we can kill this thread.
I agree totally! The problem is with rpm. It refuses to install a non i386 rpm. I have verified this by downloading the latest kernel rpm. I had to use --ignorearch flag to get rpm to install it. Now how do I get this flag to yum? I have exactarch=0 in /etc/yum.conf which I presumed was to fix this. It does not work. I have tried to pass this flag via /root/.rpmmacros with no help. So, why do only myself apparently have this problem? One other item. I made *no* changes to any yum files after installation except the addition of (maybe) rpmforge. One kernel was updated around this time. My guess is the problem started around the update to 5.1. Anybody have any input as to why at least one person does not have this problem? What could he have that is different from me regarding yum and rpm? Reading this I apologize for the ramble.
Oct 10 09:14:15 Installed: kernel.i686 2.6.18-8.1.14.el5 Last kernel update. A lot of activity Oct 12-15. Possible 5.1 update during this period.
Can you include the output of these commands:
# cat /etc/redhat-release
# yum list installed '*yum*'
# cat /etc/yum.conf
# cat /etc/yum.repos.d/CentOS-Base.repo
I removed yum and reinstalled then yum update yum with no help. No sense to include these again here.
From these we should be able to determine if your base installation
is correct.
It is *not* a yum config problem.
If it isn't a config problem then we can look at permissions and network next.
See above.
I agree totally! The problem is with rpm. It refuses to install a non i386 rpm. I have verified this by downloading the latest kernel rpm. I had to use --ignorearch flag to get rpm to install it. Now how do I get this flag to yum? I have exactarch=0 in /etc/yum.conf which I presumed was to fix this. It does not work. I have tried to pass this flag via /root/.rpmmacros with no help. So, why do only myself apparently have this problem? One other item. I made *no* changes to any yum files after installation except the addition of (maybe) rpmforge. One kernel was updated around this time. My guess is the problem started around the update to 5.1. Anybody have any input as to why at least one person does not have this problem? What could he have that is different from me regarding yum and rpm? Reading this I apologize for the ramble.
Oct 10 09:14:15 Installed: kernel.i686 2.6.18-8.1.14.el5 Last kernel update. A lot of activity Oct 12-15. Possible 5.1 update during this period.
Well, exactarch=0 might work around this from a yum standpoint (as far as downloading the updates), but if RPM is complaining this is beyond the control of yum. As someone else mentioned, taking a look at your ~/.rpmmacros file would be interesting.
Also, could you post the output of:
rpm -q --queryformat '%{NAME}-%{VERSION}-%{RELEASE}.%{ARCH}\n' kernel
Ray
On Mon, 2008-02-25 at 12:10 -0800, Ray Van Dolson wrote:
[snip]
Well, exactarch=0 might work around this from a yum standpoint (as far as downloading the updates), but if RPM is complaining this is beyond the control of yum. As someone else mentioned, taking a look at your ~/.rpmmacros file would be interesting.
It was empty.
Also, could you post the output of:
rpm -q --queryformat '%{NAME}-%{VERSION}-%{RELEASE}.%{ARCH}\n' kernel
kernel-2.6.18-8.el5.i686 kernel-2.6.18-8.1.14.el5.i686 kernel-2.6.18-53.1.13.el5.i686
The last kernel was installed manually using --ignorearch.
Bob Taylor wrote:
On Mon, 2008-02-25 at 12:10 -0800, Ray Van Dolson wrote:
[snip]
Well, exactarch=0 might work around this from a yum
standpoint (as far
as downloading the updates), but if RPM is complaining this
is beyond
the control of yum. As someone else mentioned, taking a
look at your
~/.rpmmacros file would be interesting.
It was empty.
Also, could you post the output of:
rpm -q --queryformat
'%{NAME}-%{VERSION}-%{RELEASE}.%{ARCH}\n' kernel
kernel-2.6.18-8.el5.i686 kernel-2.6.18-8.1.14.el5.i686 kernel-2.6.18-53.1.13.el5.i686
The last kernel was installed manually using --ignorearch.
Bob,
What's the output of,
# rpm -q --queryformat '%{NAME}-%{VERSION}-%{RELEASE}.%{ARCH}\n' rpm
The contents of,
# cat /etc/rpm/platform
And the output of,
# rpm --eval '%_arch'
Also, did you re-install rpm by forcing an upgrade in place of rpm with,
# rpm -Uvh --force rpm-4.4.2-47.el5.i386.rpm
Just some more things to try,
-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.
On Mon, 2008-02-25 at 23:44 -0500, Ross S. W. Walker wrote:
Bob Taylor wrote:
On Mon, 2008-02-25 at 12:10 -0800, Ray Van Dolson wrote:
[snip]
Well, exactarch=0 might work around this from a yum
standpoint (as far
as downloading the updates), but if RPM is complaining this
is beyond
the control of yum. As someone else mentioned, taking a
look at your
~/.rpmmacros file would be interesting.
It was empty.
Also, could you post the output of:
rpm -q --queryformat
'%{NAME}-%{VERSION}-%{RELEASE}.%{ARCH}\n' kernel
kernel-2.6.18-8.el5.i686 kernel-2.6.18-8.1.14.el5.i686 kernel-2.6.18-53.1.13.el5.i686
The last kernel was installed manually using --ignorearch.
Bob,
What's the output of,
# rpm -q --queryformat '%{NAME}-%{VERSION}-%{RELEASE}.%{ARCH}\n' rpm
rpm-4.4.2-47.el5.i386
The contents of,
# cat /etc/rpm/platform
i386-redhat-linux
And the output of,
# rpm --eval '%_arch'
i386
Also, did you re-install rpm by forcing an upgrade in place of rpm with,
I ran yum remove yum. I did not remove rpm nor did an rpm --force.
Bob Taylor wrote:
On Mon, 2008-02-25 at 23:44 -0500, Ross S. W. Walker wrote:
Bob Taylor wrote:
On Mon, 2008-02-25 at 12:10 -0800, Ray Van Dolson wrote:
[snip]
Well, exactarch=0 might work around this from a yum
standpoint (as far
as downloading the updates), but if RPM is complaining this
is beyond
the control of yum. As someone else mentioned, taking a
look at your
~/.rpmmacros file would be interesting.
It was empty.
Also, could you post the output of:
rpm -q --queryformat
'%{NAME}-%{VERSION}-%{RELEASE}.%{ARCH}\n' kernel
kernel-2.6.18-8.el5.i686 kernel-2.6.18-8.1.14.el5.i686 kernel-2.6.18-53.1.13.el5.i686
The last kernel was installed manually using --ignorearch.
Bob,
What's the output of,
# rpm -q --queryformat '%{NAME}-%{VERSION}-%{RELEASE}.%{ARCH}\n' rpm
rpm-4.4.2-47.el5.i386
Good
The contents of,
# cat /etc/rpm/platform
i386-redhat-linux
Good
And the output of,
# rpm --eval '%_arch'
i386
Good
Also, did you re-install rpm by forcing an upgrade in place
of rpm with,
I ran yum remove yum. I did not remove rpm nor did an rpm --force.
Don't remove rpm, just run an 'rpm -Uvh --force rpm-4.4.2-47.el5.i386.rpm' this should replace any configs/macros that might have been damaged.
Outside of that, I dunno, I would probably do an rpm audit for all packages that have changed files and re-install those packages on top of themselves, making sure to move all the '*.rpmnew' on top of the existing files. Then verify your Internet connection works properly with yum (are you behind a proxy server?), and see what that does.
-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.
On Tue, Feb 26, 2008 at 12:25:32AM -0500, Ross S. W. Walker alleged:
Bob Taylor wrote:
On Mon, 2008-02-25 at 23:44 -0500, Ross S. W. Walker wrote:
The contents of,
# cat /etc/rpm/platform
i386-redhat-linux
Good
Isn't that the problem? All of my machines say i686, athlon, ia32e, x86_64, etc. None of them say i386.
Garrick Staples wrote:
On Tue, Feb 26, 2008 at 12:25:32AM -0500, Ross S. W. Walker alleged:
Bob Taylor wrote:
On Mon, 2008-02-25 at 23:44 -0500, Ross S. W. Walker wrote:
The contents of,
# cat /etc/rpm/platform
i386-redhat-linux
Good
Isn't that the problem? All of my machines say i686, athlon, ia32e, x86_64, etc. None of them say i386.
Ooops, I saw i686 when I looked the first time, yes, this should be i686-redhat-linux. Good catch.
Bob, can you try manually changing this to say i686-redhat-linux, I believe this is auto-generated at boot so it isn't a permanent fix, but lets see if it updates after this by booting into the older kernel (may need to manually change this file again), removing the newer kernel and then try a '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.
On Tue, 2008-02-26 at 00:43 -0500, Ross S. W. Walker wrote:
Garrick Staples wrote:
On Tue, Feb 26, 2008 at 12:25:32AM -0500, Ross S. W. Walker alleged:
Bob Taylor wrote:
On Mon, 2008-02-25 at 23:44 -0500, Ross S. W. Walker wrote:
The contents of,
# cat /etc/rpm/platform
i386-redhat-linux
Good
Isn't that the problem? All of my machines say i686, athlon, ia32e, x86_64, etc. None of them say i386.
Ooops, I saw i686 when I looked the first time, yes, this should be i686-redhat-linux. Good catch.
Bob, can you try manually changing this to say i686-redhat-linux, I believe this is auto-generated at boot so it isn't a permanent fix, but lets see if it updates after this by booting into the older kernel (may need to manually change this file again), removing the newer kernel and then try a 'yum update'.
Will try this tomorrow. rpm won't let me remove the kernel it installed.
Garrick Staples wrote:
On Tue, Feb 26, 2008 at 12:25:32AM -0500, Ross S. W. Walker alleged:
Bob Taylor wrote:
On Mon, 2008-02-25 at 23:44 -0500, Ross S. W. Walker wrote:
The contents of,
# cat /etc/rpm/platform
i386-redhat-linux
Good
Isn't that the problem? All of my machines say i686, athlon, ia32e, x86_64, etc. None of them say i386.
yeah.
# cat /etc/rpm/platform i686-redhat-linux
# cat /proc/cpuinfo processor : 0 vendor_id : GenuineIntel cpu family : 6 model : 8 model name : Pentium III (Coppermine) stepping : 6 cpu MHz : 807.984 ...
(oldest thing I've put C5 on)
On Tue, 2008-02-26 at 00:25 -0500, Ross S. W. Walker wrote:
[snip]
Then verify your Internet connection works properly with yum (are you behind a proxy server?), and see what that does.
Dunno about proxy server. I'm behind an HughesNet satellite modem. Most likely that thingy that changes your IP periodically (my database retrieval program is totally busted!). :-)
on 2/25/2008 9:25 PM Ross S. W. Walker spake the following:
Bob Taylor wrote:
On Mon, 2008-02-25 at 23:44 -0500, Ross S. W. Walker wrote:
Bob Taylor wrote:
On Mon, 2008-02-25 at 12:10 -0800, Ray Van Dolson wrote:
[snip]
Well, exactarch=0 might work around this from a yum
standpoint (as far
as downloading the updates), but if RPM is complaining this
is beyond
the control of yum. As someone else mentioned, taking a
look at your
~/.rpmmacros file would be interesting.
It was empty.
Also, could you post the output of:
rpm -q --queryformat
'%{NAME}-%{VERSION}-%{RELEASE}.%{ARCH}\n' kernel
kernel-2.6.18-8.el5.i686 kernel-2.6.18-8.1.14.el5.i686 kernel-2.6.18-53.1.13.el5.i686
The last kernel was installed manually using --ignorearch.
Bob,
What's the output of,
# rpm -q --queryformat '%{NAME}-%{VERSION}-%{RELEASE}.%{ARCH}\n' rpm
rpm-4.4.2-47.el5.i386
Good
The contents of,
# cat /etc/rpm/platform
i386-redhat-linux
Good
Shouldn't this be i686-redhat-linux ?
On Tue, 2008-02-26 at 10:33 -0800, Scott Silva wrote:
[snip]
The contents of,
# cat /etc/rpm/platform
i386-redhat-linux
Good
Shouldn't this be i686-redhat-linux ?
Bingo! Better late than never! :-) That is exactly the problem!
Bob Taylor wrote:
On Mon, 2008-02-25 at 23:44 -0500, Ross S. W. Walker wrote:
Bob Taylor wrote:
On Mon, 2008-02-25 at 12:10 -0800, Ray Van Dolson wrote:
[snip]
Well, exactarch=0 might work around this from a yum
standpoint (as far
as downloading the updates), but if RPM is complaining this
is beyond
the control of yum. As someone else mentioned, taking a
look at your
~/.rpmmacros file would be interesting.
It was empty.
Also, could you post the output of:
rpm -q --queryformat
'%{NAME}-%{VERSION}-%{RELEASE}.%{ARCH}\n' kernel
kernel-2.6.18-8.el5.i686 kernel-2.6.18-8.1.14.el5.i686 kernel-2.6.18-53.1.13.el5.i686
The last kernel was installed manually using --ignorearch.
Bob,
What's the output of,
# rpm -q --queryformat '%{NAME}-%{VERSION}-%{RELEASE}.%{ARCH}\n' rpm
rpm-4.4.2-47.el5.i386
The contents of,
# cat /etc/rpm/platform
i386-redhat-linux
And the output of,
# rpm --eval '%_arch'
i386
Also, did you re-install rpm by forcing an upgrade in place of rpm with,
I ran yum remove yum. I did not remove rpm nor did an rpm --force.
what happens if you edit /etc/rpm/platform and change it too:
i686-redhat-linux
On Tue, 2008-02-26 at 08:14 -0600, Johnny Hughes wrote:
[snip]
what happens if you edit /etc/rpm/platform and change it too:
i686-redhat-linux
Nothing.
I downloaded the current rpm file this morning and ran rpm -Uvh --force /home/brtaylor/rpm-4.4.2-47.el5.i386.rpm.
Rpm seems to behave oddly. I had downloaded the current kernel rpm and installed it with the command rpm -ivh --ignorearch [file] successfully. I can not remove it with the command rpm -e kernel-2.6.18-53.1.13 but can if I add .el5 to the end it does. Before I deleted it I ran the command rpm -ql kernel and all three kernels rpm files were listed including the kernel rpm which rpm -e said wasn't installed. This doesn't make sense to me.
I have done the following:
rpm -Uvh --force /home/brtaylor/rpm-4.4.2-47.el5.i386.rpm edit /etc/rpm/platform to i686-redhat-linux rpm -e kernel-2.6.18-53.1.13.el5 yum clean all yum upgrade kernel returned Installed: kernel.i686 0:2.6.18-53.1.13.el5 Complete!
It looks like the problem may be in rpm after 4.4.2-37. Before I go to the rpm people, I need to confer with Ray Van Dolson who says his is the same as mine and he has no problem updating kernels. After Ray and I resolve this issue, I will send a last email to the list hopefully ending this subject with the resolution to this problem.
On Tue, Feb 26, 2008 at 11:19:36AM -0800, Bob Taylor alleged:
I can not remove it with the command rpm -e kernel-2.6.18-53.1.13 but can if I add .el5 to the end it does. Before I deleted it I ran the
That's correct. 53.1.13 is the not same as 53.1.13.el5.
The version is 2.6.18 and the release is 53.1.13.el5. You can specify the version or version-release, but not different substrings.
On Tue, 2008-02-26 at 11:22 -0800, Garrick Staples wrote:
On Tue, Feb 26, 2008 at 11:19:36AM -0800, Bob Taylor alleged:
I can not remove it with the command rpm -e kernel-2.6.18-53.1.13 but can if I add .el5 to the end it does. Before I deleted it I ran the
That's correct. 53.1.13 is the not same as 53.1.13.el5.
The version is 2.6.18 and the release is 53.1.13.el5. You can specify the version or version-release, but not different substrings.
Ah! Mystery resolved. Thanks!
I have done the following:
rpm -Uvh --force /home/brtaylor/rpm-4.4.2-47.el5.i386.rpm edit /etc/rpm/platform to i686-redhat-linux rpm -e kernel-2.6.18-53.1.13.el5 yum clean all yum upgrade kernel returned Installed: kernel.i686 0:2.6.18-53.1.13.el5 Complete!
It looks like the problem may be in rpm after 4.4.2-37. Before I go to the rpm people, I need to confer with Ray Van Dolson who says his is the same as mine and he has no problem updating kernels. After Ray and I resolve this issue, I will send a last email to the list hopefully ending this subject with the resolution to this problem.
Bob, so it appears the above did work?
I don't recall what exactly I said was the same on my system as yours... but, my /etc/rpm/platform is:
i686-redhat-linux
rpm is:
rpm-4.4.2-47.el5
And I am running a Pentium 4 CPU, so there is a significant difference there obviously. :)
$ cat /proc/cpuinfo processor : 0 vendor_id : GenuineIntel cpu family : 15 model : 2 model name : Intel(R) Pentium(R) 4 CPU 1.80GHz stepping : 7 cpu MHz : 1793.473 cache size : 512 KB fdiv_bug : no hlt_bug : no f00f_bug : no coma_bug : no fpu : yes fpu_exception : yes cpuid level : 2 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe up cid xtpr bogomips : 3588.95
Ray
On Tue, 2008-02-26 at 11:51 -0800, Ray Van Dolson wrote:
[snip]
It looks like the problem may be in rpm after 4.4.2-37. Before I go to the rpm people, I need to confer with Ray Van Dolson who says his is the same as mine and he has no problem updating kernels. After Ray and I resolve this issue, I will send a last email to the list hopefully ending this subject with the resolution to this problem.
Bob, so it appears the above did work?
It did.
I don't recall what exactly I said was the same on my system as yours... but, my /etc/rpm/platform is:
Mine reports the same as yours and I have no problem updating kernels.
I believe this was in reference to uname -imp which mine results in
i686 i686 i386
Notice the processor. By all accounts it should be i686.
Bob Taylor wrote:
On Tue, 2008-02-26 at 08:14 -0600, Johnny Hughes wrote:
[snip]
what happens if you edit /etc/rpm/platform and change it too:
i686-redhat-linux
Nothing.
I downloaded the current rpm file this morning and ran rpm -Uvh --force /home/brtaylor/rpm-4.4.2-47.el5.i386.rpm.
Rpm seems to behave oddly. I had downloaded the current kernel rpm and installed it with the command rpm -ivh --ignorearch [file] successfully. I can not remove it with the command rpm -e kernel-2.6.18-53.1.13 but can if I add .el5 to the end it does. Before I deleted it I ran the command rpm -ql kernel and all three kernels rpm files were listed including the kernel rpm which rpm -e said wasn't installed. This doesn't make sense to me.
I have done the following:
rpm -Uvh --force /home/brtaylor/rpm-4.4.2-47.el5.i386.rpm edit /etc/rpm/platform to i686-redhat-linux rpm -e kernel-2.6.18-53.1.13.el5 yum clean all yum upgrade kernel returned Installed: kernel.i686 0:2.6.18-53.1.13.el5 Complete!
It looks like the problem may be in rpm after 4.4.2-37. Before I go to the rpm people, I need to confer with Ray Van Dolson who says his is the same as mine and he has no problem updating kernels. After Ray and I resolve this issue, I will send a last email to the list hopefully ending this subject with the resolution to this problem.
The problem was most likely the /etc/rpm/platform
if it is i386 and not i686 then is will not allow i686 RPMS to be installed.
That file should only be updated IF anaconda does an install or upgrade.
It should only be i386 of it is installed on a pentium classic processor (or equivalent).
That is the only cause of the "incompatible arch".
Nothing in centos except an install/upgrade via anaconda should ever tough that file, so once you change it, it should remain changed.
Reboot a couple times and makes sure it (/etc/rpm/platform) stays the same.
If it changes we need to figure out why.
Johnny Hughes wrote:
Bob Taylor wrote:
On Tue, 2008-02-26 at 08:14 -0600, Johnny Hughes wrote:
[snip]
what happens if you edit /etc/rpm/platform and change it too:
i686-redhat-linux
Nothing.
I downloaded the current rpm file this morning and ran rpm -Uvh --force /home/brtaylor/rpm-4.4.2-47.el5.i386.rpm.
Rpm seems to behave oddly. I had downloaded the current kernel rpm and installed it with the command rpm -ivh --ignorearch [file] successfully. I can not remove it with the command rpm -e kernel-2.6.18-53.1.13 but can if I add .el5 to the end it does. Before I deleted it I ran the command rpm -ql kernel and all three kernels rpm files were listed including the kernel rpm which rpm -e said wasn't installed. This doesn't make sense to me.
I have done the following:
rpm -Uvh --force /home/brtaylor/rpm-4.4.2-47.el5.i386.rpm edit /etc/rpm/platform to i686-redhat-linux rpm -e kernel-2.6.18-53.1.13.el5 yum clean all yum upgrade kernel returned Installed: kernel.i686 0:2.6.18-53.1.13.el5 Complete!
It looks like the problem may be in rpm after 4.4.2-37. Before I go to the rpm people, I need to confer with Ray Van Dolson who says his is the same as mine and he has no problem updating kernels. After Ray and I resolve this issue, I will send a last email to the list hopefully ending this subject with the resolution to this problem.
The problem was most likely the /etc/rpm/platform
if it is i386 and not i686 then is will not allow i686 RPMS to be installed.
That file should only be updated IF anaconda does an install or upgrade.
Good to note, I was under the impression that it might be set in the initrd in case a different kernel image is installed.
It should only be i386 of it is installed on a pentium classic processor (or equivalent).
Would anaconda even allow C5 to install on such a class cpu?
That is the only cause of the "incompatible arch".
Nothing in centos except an install/upgrade via anaconda should ever tough that file, so once you change it, it should remain changed.
Reboot a couple times and makes sure it (/etc/rpm/platform) stays the same.
If it changes we need to figure out why.
I think there may be a case or two of bad packages updating that file I believe these are some dumb Mozilla plugins though, googling got me these:
http://dnmouse.webs.com/playdvdsmore.htm
and here:
The OP had a lot of kitchen sinks installed maybe a broken plugin was the cause of all that grief. Probably right around the time he installed that repo and things stopped working.
-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.
Ross S. W. Walker wrote:
Johnny Hughes wrote:
Bob Taylor wrote:
On Tue, 2008-02-26 at 08:14 -0600, Johnny Hughes wrote:
[snip]
what happens if you edit /etc/rpm/platform and change it too:
i686-redhat-linux
Nothing.
<snip>
The problem was most likely the /etc/rpm/platform
if it is i386 and not i686 then is will not allow i686 RPMS to be installed.
That file should only be updated IF anaconda does an install or upgrade.
Good to note, I was under the impression that it might be set in the initrd in case a different kernel image is installed.
It should only be i386 of it is installed on a pentium classic processor (or equivalent).
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)
That is the only cause of the "incompatible arch".
Nothing in centos except an install/upgrade via anaconda should ever tough that file, so once you change it, it should remain changed.
Reboot a couple times and makes sure it (/etc/rpm/platform) stays the same.
If it changes we need to figure out why.
I think there may be a case or two of bad packages updating that file I believe these are some dumb Mozilla plugins though, googling got me these:
http://dnmouse.webs.com/playdvdsmore.htm
and here:
The OP had a lot of kitchen sinks installed maybe a broken plugin was the cause of all that grief. Probably right around the time he installed that repo and things stopped working.
In both cases it seems that unixODBC-devel.i386 is the thing that possibly makes /etc/rpm/paltform angry.
Let me research that.
Johnny Hughes wrote:
Ross S. W. Walker wrote:
Johnny Hughes wrote:
Bob Taylor wrote:
On Tue, 2008-02-26 at 08:14 -0600, Johnny Hughes wrote:
[snip]
what happens if you edit /etc/rpm/platform and change it too:
i686-redhat-linux
Nothing.
<snip>
The problem was most likely the /etc/rpm/platform
if it is i386 and not i686 then is will not allow i686 RPMS to be installed.
That file should only be updated IF anaconda does an install or upgrade.
Good to note, I was under the impression that it might be set in the initrd in case a different kernel image is installed.
It should only be i386 of it is installed on a pentium classic processor (or equivalent).
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)
That is the only cause of the "incompatible arch".
Nothing in centos except an install/upgrade via anaconda
should ever
tough that file, so once you change it, it should remain changed.
Reboot a couple times and makes sure it (/etc/rpm/platform) stays the same.
If it changes we need to figure out why.
I think there may be a case or two of bad packages updating
that file
I believe these are some dumb Mozilla plugins though, googling got me these:
http://dnmouse.webs.com/playdvdsmore.htm
and here:
The OP had a lot of kitchen sinks installed maybe a broken plugin was the cause of all that grief. Probably right around the time he installed that repo and things stopped working.
In both cases it seems that unixODBC-devel.i386 is the thing that possibly makes /etc/rpm/paltform angry.
Let me research that.
I did a quick test and adding unixODBC-devel did nothing to my platform file on both Intel and AMD, so maybe it had a problem in the past and now it has become an urban legend.
Maybe some other third party repo package mangled it. The OP's yum log should show what packages were installed when, so just need to trace it back to when it stopped working and look at what packages were installed and from where and test them out.
-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.
Ross S. W. Walker wrote:
Johnny Hughes wrote:
Ross S. W. Walker wrote:
Johnny Hughes wrote:
Bob Taylor wrote:
On Tue, 2008-02-26 at 08:14 -0600, Johnny Hughes wrote:
[snip]
what happens if you edit /etc/rpm/platform and change it too:
i686-redhat-linux
Nothing.
<snip>
The problem was most likely the /etc/rpm/platform
if it is i386 and not i686 then is will not allow i686 RPMS to be installed.
That file should only be updated IF anaconda does an install or upgrade.
Good to note, I was under the impression that it might be set in the initrd in case a different kernel image is installed.
It should only be i386 of it is installed on a pentium classic processor (or equivalent).
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)
That is the only cause of the "incompatible arch".
Nothing in centos except an install/upgrade via anaconda
should ever
tough that file, so once you change it, it should remain changed.
Reboot a couple times and makes sure it (/etc/rpm/platform) stays the same.
If it changes we need to figure out why.
I think there may be a case or two of bad packages updating
that file
I believe these are some dumb Mozilla plugins though, googling got me these:
http://dnmouse.webs.com/playdvdsmore.htm
and here:
The OP had a lot of kitchen sinks installed maybe a broken plugin was the cause of all that grief. Probably right around the time he installed that repo and things stopped working.
In both cases it seems that unixODBC-devel.i386 is the thing that possibly makes /etc/rpm/paltform angry.
Let me research that.
I did a quick test and adding unixODBC-devel did nothing to my platform file on both Intel and AMD, so maybe it had a problem in the past and now it has become an urban legend.
Maybe some other third party repo package mangled it. The OP's yum log should show what packages were installed when, so just need to trace it back to when it stopped working and look at what packages were installed and from where and test them out.
Actually one quick test to see if the platform file was mistakenly packaged in some third party rpm is to do a:
# rpm -qf /etc/rpm/platform
On a default environment it should come back that no package owns that file. If a package does own it then there is the culprit.
Of course that doesn't take into account rpm scripts that could modify it, but that would have had to be done on purpose and who would do that?
-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.
On Tue, 2008-02-26 at 17:30 -0500, Ross S. W. Walker wrote:
[snip]
# rpm -qf /etc/rpm/platform
rpm -qf /etc/rpm/platform file /etc/rpm/platform is not owned by any package
On a default environment it should come back that no package owns that file. If a package does own it then there is the culprit.
[snip]
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!
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
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. :-(
On Wed, Feb 27, 2008 at 11:30 AM, Bob Taylor bob8221@gmail.com wrote:
On Wed, 2008-02-27 at 06:29 -0600, Johnny Hughes wrote:
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. :-(
-- Bob Taylor
Uncle Bob, :-D
I apologize in advance for asking this question but... Are you certain that you did not edit / touch the /etc/rpm/platform file yourself?
Akemi
On Wed, 2008-02-27 at 12:19 -0800, Akemi Yagi wrote:
On Wed, Feb 27, 2008 at 11:30 AM, Bob Taylor bob8221@gmail.com wrote:
On Wed, 2008-02-27 at 06:29 -0600, Johnny Hughes wrote:
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. :-(
-- Bob Taylor
Uncle Bob, :-D
I'm both an uncle *and* a grandfather. You have my permission to address me as Uncle Bob. :-)
I apologize in advance for asking this question but... Are you certain that you did not edit / touch the /etc/rpm/platform file yourself?
Prior to my changing i386 to i686 as previously stated. Frankly, I was unaware of the contents of /etc/rpm as I hadn't had time. Sigh!
Uncle Bob
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.
On Wed, 2008-02-27 at 15:27 -0500, Ross S. W. Walker wrote:
[big snip]
I'd be interested in seeing a complete /var/log/yum.log file and the date of the last successful yum update.
I have attached both yum.log files. Possible dates of interest are:
Oct 10 09:14:15 Installed: kernel.i686 2.6.18-8.1.14.el5
Oct 24 05:43:29 Updated: kernel-headers.i386 2.6.18-8.1.15.el5 Dec 03 11:10:12 Updated: kernel-headers.i386 2.6.18-53.1.4.el5
I wonder if you can find a culprit?
On Tue, 2008-02-26 at 15:27 -0500, Ross S. W. Walker wrote:
[snip]
I think there may be a case or two of bad packages updating that file I believe these are some dumb Mozilla plugins though, googling got me these:
http://dnmouse.webs.com/playdvdsmore.htm
and here:
The OP had a lot of kitchen sinks installed maybe a broken plugin was the cause of all that grief. Probably right around the time he installed that repo and things stopped working.
I presume this comment is in regards to the above references?
On Tue, 2008-02-26 at 14:16 -0600, Johnny Hughes wrote:
Bob Taylor wrote:
On Tue, 2008-02-26 at 08:14 -0600, Johnny Hughes wrote:
[snip]
what happens if you edit /etc/rpm/platform and change it too:
i686-redhat-linux
Nothing.
I downloaded the current rpm file this morning and ran rpm -Uvh --force /home/brtaylor/rpm-4.4.2-47.el5.i386.rpm.
Rpm seems to behave oddly. I had downloaded the current kernel rpm and installed it with the command rpm -ivh --ignorearch [file] successfully. I can not remove it with the command rpm -e kernel-2.6.18-53.1.13 but can if I add .el5 to the end it does. Before I deleted it I ran the command rpm -ql kernel and all three kernels rpm files were listed including the kernel rpm which rpm -e said wasn't installed. This doesn't make sense to me.
I have done the following:
rpm -Uvh --force /home/brtaylor/rpm-4.4.2-47.el5.i386.rpm edit /etc/rpm/platform to i686-redhat-linux rpm -e kernel-2.6.18-53.1.13.el5 yum clean all yum upgrade kernel returned Installed: kernel.i686 0:2.6.18-53.1.13.el5 Complete!
It looks like the problem may be in rpm after 4.4.2-37. Before I go to the rpm people, I need to confer with Ray Van Dolson who says his is the same as mine and he has no problem updating kernels. After Ray and I resolve this issue, I will send a last email to the list hopefully ending this subject with the resolution to this problem.
The problem was most likely the /etc/rpm/platform
I agree.
if it is i386 and not i686 then is will not allow i686 RPMS to be installed.
That file should only be updated IF anaconda does an install or upgrade.
It should only be i386 of it is installed on a pentium classic processor (or equivalent).
I have a Pentium Classic or equivalent? I want to verify if I've found a bug or ? in rpm. After thought: I seem to be running OK on the i686 kernel. It would seem to me, if I *do* have one of those, it would be a mistake to put i386 in /etc/rpm/platform.
That is the only cause of the "incompatible arch".
Nothing in centos except an install/upgrade via anaconda should ever tough that file, so once you change it, it should remain changed.
Reboot a couple times and makes sure it (/etc/rpm/platform) stays the same.
Will do as soon as I have a chance. This has caused me to lose much time.
If it changes we need to figure out why.
I will post a message if so. Better not! :-)
Bob Taylor wrote:
On Mon, 2008-02-25 at 12:41 -0500, Ross S. W. Walker wrote:
[snip]
Bob,
Lets get this fixed so we can kill this thread.
I agree totally! The problem is with rpm. It refuses to install a non i386 rpm. I have verified this by downloading the latest kernel rpm. I
If rpm is broken, why not try to upgrade rpm on top of itself?
rpm -Uvh --force rpm-4.4.2-47.el5.rpm
You will need to manually download the rpm package again.
had to use --ignorearch flag to get rpm to install it. Now how do I get this flag to yum? I have exactarch=0 in /etc/yum.conf which I presumed was to fix this. It does not work. I have tried to pass this flag via /root/.rpmmacros with no help. So, why do only myself apparently have this problem? One other item. I made *no* changes to any yum files after installation except the addition of (maybe) rpmforge. One kernel was updated around this time. My guess is the problem started around the update to 5.1. Anybody have any input as to why at least one person does not have this problem? What could he have that is different from me regarding yum and rpm? Reading this I apologize for the ramble.
Bob,
I wouldn't muck with any more options, try to undo the changes you have made.
I didn't see what the rpm error was you got when you tried to install it, did you post it to the thread?
You said you re-installed yum, how did you remove yum?
If you did a rpm -e yum, then the yum plugins may have still been left behind. Here is the list you provided earlier:
yum-3.0.5-1.el5.centos.5 yum-cron-0.6-1.el5.centos yum-downloadonly-1.0.4-3.el5.centos.2 yumex-2.0.3-2.el5.centos yum-fastestmirror-1.0.4-3.el5.centos.2 yum-metadata-parser-1.0-8.fc6 yum-priorities-1.0.4-3.el5.centos.2 yum-repolist-1.0.4-3.el5.centos.2 yum-skip-broken-1.0.4-3.el5.centos.2 yum-updatesd-3.0.5-1.el5.centos.5 yum-utils-1.0.4-3.el5.centos.2 yum-versionlock-1.0.4-3.el5.centos.2
Here are the yum and plugins I have installed:
yum-3.0.5-1.el5.centos.5 yum-changelog-1.0.4-3.el5.centos.2 yum-metadata-parser-1.0-8.fc6 yum-priorities-1.0.4-3.el5.centos.2 yum-updatesd-3.0.5-1.el5.centos.5
Besides 'yum-fastestmirror' I would make sure the others are removed and their configs cleared out from /etc/yum/pluginconf.d unless you know you have a real need for any of them.
The yum plugin that catches my attention is 'yum-versionlock'
Oct 10 09:14:15 Installed: kernel.i686 2.6.18-8.1.14.el5 Last kernel update. A lot of activity Oct 12-15. Possible 5.1 update during this period.
Can you include the output of these commands:
# cat /etc/redhat-release
# yum list installed '*yum*'
# cat /etc/yum.conf
# cat /etc/yum.repos.d/CentOS-Base.repo
I removed yum and reinstalled then yum update yum with no help. No sense to include these again here.
From these we should be able to determine if your base installation
is correct.
It is *not* a yum config problem.
Can you post the rpm error you got before?
If it isn't a config problem then we can look at permissions and network next.
See above.
______________________________________________________________________ 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.
On Mon, 2008-02-25 at 16:34 -0500, Ross S. W. Walker wrote:
Bob Taylor wrote:
On Mon, 2008-02-25 at 12:41 -0500, Ross S. W. Walker wrote:
[snip]
Bob,
Lets get this fixed so we can kill this thread.
I agree totally! The problem is with rpm. It refuses to install a non i386 rpm. I have verified this by downloading the latest kernel rpm. I
If rpm is broken, why not try to upgrade rpm on top of itself?
rpm -Uvh --force rpm-4.4.2-47.el5.rpm
You will need to manually download the rpm package again.
had to use --ignorearch flag to get rpm to install it. Now how do I get this flag to yum? I have exactarch=0 in /etc/yum.conf which I presumed was to fix this. It does not work. I have tried to pass this flag via /root/.rpmmacros with no help. So, why do only myself apparently have this problem? One other item. I made *no* changes to any yum files after installation except the addition of (maybe) rpmforge. One kernel was updated around this time. My guess is the problem started around the update to 5.1. Anybody have any input as to why at least one person does not have this problem? What could he have that is different from me regarding yum and rpm? Reading this I apologize for the ramble.
Bob,
I wouldn't muck with any more options, try to undo the changes you have made.
Didn't make any except possibly rpmforge.repo.
I didn't see what the rpm error was you got when you tried to install it, did you post it to the thread?
You said you re-installed yum, how did you remove yum?
yum remove yum Installed yum from my installation CD, ran yum update yum with no change.
If you did a rpm -e yum, then the yum plugins may have still been left behind. Here is the list you provided earlier:
None.
[snip]
The yum plugin that catches my attention is 'yum-versionlock'
enabled=0
Hello
unfortunately other users can change to my user name with sudo, how I can prevent it ? is there a command to prevent to change to only my user name ?
Thanks
Centos wrote:
Hello
unfortunately other users can change to my user name with sudo, how I can prevent it ? is there a command to prevent to change to only my user name ?
if you allow users open access to sudo, they can do anything that root can, which is just about anything.
the alternative is to allow only very restrictive use of sudo, running very specific commands as specific users only. this is all controlled via /etc/sudoers, see the man pages.
Centos wrote:
Hello
unfortunately other users can change to my user name with sudo, how I can prevent it ? is there a command to prevent to change to only my user name ?
DO NOT HIJACK THREADS ON A MAILING LIST. Post a "fresh" mail to centos@centos.org, don't just blindly reply to some mail and just change the subject.
And yes, any user which is allowed to switch to root can also switch to any other user on the system. That's what root is allowed to do. See the manual page of /etc/sudoers on how to just enable specific commands (why do all of those users need to be root anyway?).
Ralph
On Monday 25 February 2008, Ross S. W. Walker wrote:
Lets get this fixed so we can kill this thread.
Good initiative, but since the layer beneath also fails (rpm) maybe we should start there. rpm -qi kernel or maybe bad stuff in /etc/sysconfig kernel.
The interesting error from RPM suggests that it thinks the machine is an i586 (or atleast not i686).
/Peter
Can you include the output of these commands:
# cat /etc/redhat-release
# yum list installed '*yum*'
# cat /etc/yum.conf
# cat /etc/yum.repos.d/CentOS-Base.repo
Peter Kjellstrom wrote:
On Monday 25 February 2008, Ross S. W. Walker wrote:
Lets get this fixed so we can kill this thread.
Good initiative, but since the layer beneath also fails (rpm) maybe we should start there. rpm -qi kernel or maybe bad stuff in /etc/sysconfig kernel.
The interesting error from RPM suggests that it thinks the machine is an i586 (or atleast not i686).
indeed, lets add....
$ cat /proc/cpuinfo
to the possibly interesting info to post here...
John R Pierce wrote:
Peter Kjellstrom wrote:
On Monday 25 February 2008, Ross S. W. Walker wrote:
Lets get this fixed so we can kill this thread.
Good initiative, but since the layer beneath also fails
(rpm) maybe we should
start there. rpm -qi kernel or maybe bad stuff in
/etc/sysconfig kernel.
The interesting error from RPM suggests that it thinks the
machine is an i586
(or atleast not i686).
indeed, lets add....
$ cat /proc/cpuinfoto the possibly interesting info to post here...
Sure, C5 kernels only come in the i686 or x86_64 variety.
Maybe the OP's rpm thinks it's on x86_64?
'package kernel-2.6.18-53.1.13.el5 is intended for a i686 architecture'
is the kind of error one would see when installing i386 on x86_64, the kernel rpm file has a list of unsupported architectures and it will spit out this error when installing i386 on x86_64.
-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.
On Mon, 2008-02-25 at 13:19 -0800, John R Pierce wrote:
Peter Kjellstrom wrote:
On Monday 25 February 2008, Ross S. W. Walker wrote:
Lets get this fixed so we can kill this thread.
Good initiative, but since the layer beneath also fails (rpm) maybe we should start there. rpm -qi kernel or maybe bad stuff in /etc/sysconfig kernel.
The interesting error from RPM suggests that it thinks the machine is an i586 (or atleast not i686).
indeed, lets add....
$ cat /proc/cpuinfo
processor : 0 vendor_id : GenuineIntel cpu family : 6 model : 5 model name : Pentium II (Deschutes) stepping : 1 cpu MHz : 398.296 cache size : 512 KB fdiv_bug : no hlt_bug : no f00f_bug : no coma_bug : no fpu : yes fpu_exception : yes cpuid level : 2 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 mtrr pge mca cmov pat pse36 mmx fxsr up bogomips : 797.12
On Mon, 2008-02-25 at 21:22 +0100, Peter Kjellstrom wrote:
On Monday 25 February 2008, Ross S. W. Walker wrote:
Lets get this fixed so we can kill this thread.
Good initiative, but since the layer beneath also fails (rpm) maybe we should start there. rpm -qi kernel or maybe bad stuff in /etc/sysconfig kernel.
Where I am confused is the original kernel and ONE update is in the /var/log/yum.log then nada.
I seem to recall a discussion many months ago regarding an i686 kernel being installed from an i386 directory. If you look at http://isodirect.centos.org/centos/5/updates you will not see an i686 directory, just i386 and ia-64. All rpms in the i386 directory are i386 except the kernels and very few others.
/etc/sysconfig/kernel: # UPDATEDEFAULT specifies if new-kernel-pkg should make # new kernels the default UPDATEDEFAULT=yes
# DEFAULTKERNEL specifies the default kernel package type DEFAULTKERNEL=kernel
The interesting error from RPM suggests that it thinks the machine is an i586 (or atleast not i686).
uname -imp:
i686 i686 i386
Don't know why the kernel says it's an i386. Kernel bug? Gateway purchase?
Bob Taylor wrote:
On Mon, 2008-02-25 at 21:22 +0100, Peter Kjellstrom wrote:
On Monday 25 February 2008, Ross S. W. Walker wrote:
Lets get this fixed so we can kill this thread.
Good initiative, but since the layer beneath also fails
(rpm) maybe we should
start there. rpm -qi kernel or maybe bad stuff in
/etc/sysconfig kernel.
Where I am confused is the original kernel and ONE update is in the /var/log/yum.log then nada.
I seem to recall a discussion many months ago regarding an i686 kernel being installed from an i386 directory. If you look at http://isodirect.centos.org/centos/5/updates you will not see an i686 directory, just i386 and ia-64. All rpms in the i386 directory are i386 except the kernels and very few others.
/etc/sysconfig/kernel: # UPDATEDEFAULT specifies if new-kernel-pkg should make # new kernels the default UPDATEDEFAULT=yes
# DEFAULTKERNEL specifies the default kernel package type DEFAULTKERNEL=kernel
The interesting error from RPM suggests that it thinks the
machine is an i586
(or atleast not i686).
uname -imp:
i686 i686 i386
Don't know why the kernel says it's an i386. Kernel bug? Gateway purchase?
i386 is the architecture, in there you have processor flavors which can be i386 (generic), i486, i586 and i686 tuned. C5 only carries the generic i386 (default compile options) and the i686 tuned binaries, i586 tuned binaries are no longer being supported after C4.
Currently C5 only supports i386 and x86_64 architectures. They are working on ia64 and ppc, maybe sparc too.
The uname output is valid for your install, the question now is why rpm refuses to install valid architecture binaries on your system.
-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.
On Tue, 2008-02-26 at 00:19 -0500, Ross S. W. Walker wrote:
Bob Taylor wrote:
[snip]
uname -imp:
i686 i686 i386
Don't know why the kernel says it's an i386. Kernel bug? Gateway purchase?
i386 is the architecture, in there you have processor flavors which can be i386 (generic), i486, i586 and i686 tuned. C5 only carries the generic i386 (default compile options) and the i686 tuned binaries, i586 tuned binaries are no longer being supported after C4.
What does this say my cpu is:
vendor_id : GenuineIntel cpu family : 6 model : 5 model name : Pentium II (Deschutes)
[snip]
The uname output is valid for your install, the question now is why rpm refuses to install valid architecture binaries on your system.
So, my cpu is not an i686?
Bob Taylor wrote:
On Tue, 2008-02-26 at 00:19 -0500, Ross S. W. Walker wrote:
Bob Taylor wrote:
[snip]
uname -imp:
i686 i686 i386
Don't know why the kernel says it's an i386. Kernel bug? Gateway purchase?
i386 is the architecture, in there you have processor flavors which can be i386 (generic), i486, i586 and i686 tuned. C5 only carries the generic i386 (default compile options) and the i686 tuned binaries, i586 tuned binaries are no longer being supported after C4.
What does this say my cpu is:
vendor_id : GenuineIntel cpu family : 6 model : 5 model name : Pentium II (Deschutes)
[snip]
The uname output is valid for your install, the question now is why rpm refuses to install valid architecture binaries on your system.
So, my cpu is not an i686?
a P-II should be. i686 is everything from the Pentium Pro onwards, including P-II, P-III, P4, core, and the various clones. it does NOT include the original Pentiums (p5 and p54) or 'pentium w/ MMX', those are i586.
On Mon, 2008-02-25 at 22:46 -0800, John R Pierce wrote:
Bob Taylor wrote:
On Tue, 2008-02-26 at 00:19 -0500, Ross S. W. Walker wrote:
Bob Taylor wrote:
[snip]
uname -imp:
i686 i686 i386
Don't know why the kernel says it's an i386. Kernel bug? Gateway purchase?
i386 is the architecture, in there you have processor flavors which can be i386 (generic), i486, i586 and i686 tuned. C5 only carries the generic i386 (default compile options) and the i686 tuned binaries, i586 tuned binaries are no longer being supported after C4.
What does this say my cpu is:
vendor_id : GenuineIntel cpu family : 6 model : 5 model name : Pentium II (Deschutes)
[snip]
The uname output is valid for your install, the question now is why rpm refuses to install valid architecture binaries on your system.
So, my cpu is not an i686?
a P-II should be. i686 is everything from the Pentium Pro onwards, including P-II, P-III, P4, core, and the various clones. it does NOT include the original Pentiums (p5 and p54) or 'pentium w/ MMX', those are i586.
What is model : 5 above compared to p5?
Bob Taylor wrote:
On Mon, 2008-02-25 at 22:46 -0800, John R Pierce wrote:
Bob Taylor wrote:
On Tue, 2008-02-26 at 00:19 -0500, Ross S. W. Walker wrote:
Bob Taylor wrote:
[snip]
uname -imp:
i686 i686 i386
Don't know why the kernel says it's an i386. Kernel bug? Gateway purchase?
i386 is the architecture, in there you have processor flavors which can be i386 (generic), i486, i586 and i686 tuned. C5 only carries the generic i386 (default compile options) and the i686 tuned binaries, i586 tuned binaries are no longer being supported after C4.
What does this say my cpu is:
vendor_id : GenuineIntel cpu family : 6 model : 5 model name : Pentium II (Deschutes)
[snip]
The uname output is valid for your install, the question now is why rpm refuses to install valid architecture binaries on your system.
So, my cpu is not an i686?
a P-II should be. i686 is everything from the Pentium Pro onwards, including P-II, P-III, P4, core, and the various clones. it does NOT include the original Pentiums (p5 and p54) or 'pentium w/ MMX', those are i586.
What is model : 5 above compared to p5?
The model refers to "Pentium II", the family '6' refers to i686, the stepping is the sub-version of "Pentium II" which for yours has the nick name "Deschutes".
Here is the cpu info of a more recent quad core Intel.
processor : 0 vendor_id : GenuineIntel cpu family : 6 model : 15 model name : Intel(R) Xeon(R) CPU X3220 @ 2.40GHz stepping : 7
This model is 10 cpu designs ahead, but still part of the i686 family, of course these 10 designs do not show the separate Pentium/Xeon/Pro tree lineages. I think they gave up giving the steppings nick names a long long time ago.
-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.
Ross S. W. Walker wrote:
Here is the cpu info of a more recent quad core Intel.
processor : 0 vendor_id : GenuineIntel cpu family : 6 model : 15 model name : Intel(R) Xeon(R) CPU X3220 @ 2.40GHz stepping : 7
This model is 10 cpu designs ahead, but still part of the i686 family, of course these 10 designs do not show the separate Pentium/Xeon/Pro tree lineages. I think they gave up giving the steppings nick names a long long time ago.
indeed, "Xeon" further confuses things, this is simply a brand name for a 'Server' CPU. There have been Xeon's that were Pentium-III based, then Pentium-4 based, and now new ones like that are Core2Duo based.
and, further confusing things, the Pentium-4 variants weren't really P6 core based, they had a completely different internal architecture known as NetBurst, but Intel decided not to give it a seperate family designation for who-knows-what reason. The newest "Core" based CPUs are in fact derived from the Pentium-M laptop processor, which in turn was based on a redesign of the P6 (Pentium-III) guts, discarding the Netburst architecture.
The problem which began this long an laborious thread has been solved with an edit of /etc/rpm/platform replacing i386 with i686. Whatever created this file thinks my cpu is not an i686.
Many thanks to all who helped track this down!
Hitler is dead. End of thread!
On Sat, Feb 23, 2008 at 10:51 AM, Bob Taylor bob8221@gmail.com wrote:
Someone just said *not* to use protect and priority together.
Red Hat has a propensity to remove any documentation on a package that does not have a man page. Sometimes it's included in /usr/share/doc and sometimes in /usr/lib and sometimes it's just not there. There is, hopefully *some* documentation on plugins other than how to write one. I would like to know *what* plugins actually *do*.
You can count on the CentOS wiki:
http://wiki.centos.org/PackageManagement/Yum
and follow the links in there to learn all about yum plugins.
Akemi
-- Bob Taylor
On Sat, 2008-02-23 at 10:51 -0800, Bob Taylor wrote:
On Sat, 2008-02-23 at 06:25 -0500, William L. Maltby wrote:
On Fri, 2008-02-22 at 23:45 -0800, Bob Taylor wrote:
[snip]
<snip>
Someone just said *not* to use protect and priority together.
Me. But I'm no authority on it. Just passing what Johnny et al has said several times in the past.
Red Hat has a propensity to remove any documentation on a package that does not have a man page. Sometimes it's included in /usr/share/doc and sometimes in /usr/lib and sometimes it's just not there. There is, hopefully *some* documentation on plugins other than how to write one. I would like to know *what* plugins actually *do*.
Well Google? But you must be, like me, lazy. So here's your sign. ;-)
http://www.duke.edu/search/?q=yum+package+manager
Enjoy.
I misspoke. Yum installed kernel-2.6.18-8.1.14 October 13, 2007 according to yum.log. So, yum appears to have worked *once* updating the kernel. Looking in CentOS vault, I saw .15 which gives me a time frame for what it's worth. All I did was add rpmforge. I have removed it with no help. I will post any file related to this mystery when requested.
What does the following command produce on your system?
yum --noplugins --disable '*' --enable updates list 'kernel*'
-Shad
On Fri, 2008-02-22 at 18:25 -0700, Shad L. Lords wrote:
I misspoke. Yum installed kernel-2.6.18-8.1.14 October 13, 2007 according to yum.log. So, yum appears to have worked *once* updating the kernel. Looking in CentOS vault, I saw .15 which gives me a time frame for what it's worth. All I did was add rpmforge. I have removed it with no help. I will post any file related to this mystery when requested.
What does the following command produce on your system?
yum --noplugins --disable '*' --enable updates list 'kernel*'
yum --noplugins --disable '*' --enable updates list 'kernel*' Setting up repositories updates 100% |=========================| 951 B 00:00 Reading repository metadata in from local files Installed Packages kernel.i686 2.6.18-8.1.14.el5 installed kernel.i686 2.6.18-8.el5 installed kernel-headers.i386 2.6.18-53.1.13.el5.cen installed Available Packages kernel-doc.noarch 2.6.18-53.1.13.el5 updates kernel-headers.i386 2.6.18-53.1.13.el5 updates
Doesn't look like the problem is in plug-ins but maybe updates?
Bob Taylor wrote:
On Fri, 2008-02-22 at 18:25 -0700, Shad L. Lords wrote:
I misspoke. Yum installed kernel-2.6.18-8.1.14 October 13, 2007 according to yum.log. So, yum appears to have worked *once* updating the kernel. Looking in CentOS vault, I saw .15 which gives me a time frame for what it's worth. All I did was add rpmforge. I have removed it with no help. I will post any file related to this mystery when requested.
What does the following command produce on your system?
yum --noplugins --disable '*' --enable updates list 'kernel*'
yum --noplugins --disable '*' --enable updates list 'kernel*' Setting up repositories updates 100% |=========================| 951 B 00:00 Reading repository metadata in from local files Installed Packages kernel.i686 2.6.18-8.1.14.el5 installed kernel.i686 2.6.18-8.el5 installed kernel-headers.i386 2.6.18-53.1.13.el5.cen installed Available Packages kernel-doc.noarch 2.6.18-53.1.13.el5 updates kernel-headers.i386 2.6.18-53.1.13.el5 updates
based on this output ... somehow your kernel is excluded in update set, even though it sees kernel-doc.noarch and kernel-headers.i386.
This leads me to believe that there is a "exclude=kernel" somewhere in a config file:
please check /etc/yum.conf again
On Sat, 2008-02-23 at 03:47 -0600, Johnny Hughes wrote:
Bob Taylor wrote:
[snip]
based on this output ... somehow your kernel is excluded in update set, even though it sees kernel-doc.noarch and kernel-headers.i386.
This leads me to believe that there is a "exclude=kernel" somewhere in a config file:
I just read man yum.conf again and I see this:
installonlypkgs List of packages that should only ever be installed, never updated. Kernels in particular fall into this category. Defaults to ‘kernel, kernel-smp, kernel-bigmem, kernel-enterprise, kernel-debug, kernel-unsupported’.
What I missed is "never updated". If this is my problem, how do I fix it?
please check /etc/yum.conf again
No exclude in any config file.
Thanks again!
installonlypkgs List of packages that should only ever be installed, never updated. Kernels in particular fall into this category. Defaults to ‘kernel, kernel-smp, kernel-bigmem, kernel-enterprise, kernel-debug, kernel-unsupported’.
What I missed is "never updated". If this is my problem, how do I fix it?
This just means that the newer kernels will be installed instead of replacing the old kernels packages. It doesn't mean that newer kernels will not be installed at all.
Sheesh, I thought you got your update issues sorted out a long time ago. :) Just give someone from this list root on your box already so we can see this for ourselves. :)
Ray
On Sat, Feb 23, 2008 at 10:24 AM, Ray Van Dolson rayvd@bludgeon.org wrote:
installonlypkgs List of packages that should only ever be installed, never updated. Kernels in particular fall into this category. Defaults to 'kernel, kernel-smp, kernel-bigmem, kernel-enterprise, kernel-debug, kernel-unsupported'.
What I missed is "never updated". If this is my problem, how do I fix it?
This just means that the newer kernels will be installed instead of replacing the old kernels packages. It doesn't mean that newer kernels will not be installed at all.
Sheesh, I thought you got your update issues sorted out a long time ago. :) Just give someone from this list root on your box already so we can see this for ourselves. :)
Yes, that seems to be the best solution at this point. You can definitely trust Johnny Hughes if you ask who that someone should be.
Akemi
-
Akemi Yagi -
Alfred von Campe -
Bob Taylor -
Centos -
Garrick Staples -
John R Pierce -
Johnny Hughes -
Peter Kjellstrom -
Ralph Angenendt -
Ray Van Dolson -
Ray Van Dolson -
Ross S. W. Walker -
Scott Silva -
Shad L. Lords -
William L. Maltby