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.