Hi All,
I just upgraded a machine from CentOS 5.3 32-bit to CentOS 5.5 x86_64 using the updater on the release disk. Now that the machine is running 64-bit, I notice that Yum is broken, failing with the following error: ~~~ There was a problem importing one of the Python modules required to run yum. The error leading to this problem was: /usr/lib/python2.4/site-packages/rpm/_rpmmodule.so: wrong ELF class: ELFCLASS32 ~~~
OK, so I thought I could fix this by installing the dependency. After digging through a bunch of cascading dependencies using rpm, I got to the elfutils, which didn't want to install until I used the --ignorearch switch on rpm. However, when I try to install the 64-bit version of rpm-libs on top of that, I still get the complaint about the failed dependency on elfutils.
My first question is: Would I be better off just wiping the machine and installing from scratch at this point, or is there some sane way to get yum reconstructed?
And the second question: did I make a mistake by assuming that the upgrade system would work as it should, or is this just a bug in the upgrade system? And to my first question, does anyone know what else the updater is likely to have broken?
Thanks, --Bill
At Sun, 15 Aug 2010 16:09:13 -0700 CentOS mailing list centos@centos.org wrote:
Hi All,
I just upgraded a machine from CentOS 5.3 32-bit to CentOS 5.5 x86_64 using the updater on the release disk. Now that the machine is running 64-bit, I notice that Yum is broken, failing with the following error:
There was a problem importing one of the Python modules required to run yum. The error leading to this problem was: /usr/lib/python2.4/site-packages/rpm/_rpmmodule.so: wrong ELF class: ELFCLASS32
Is there really an updater that goes from 32-bit to 64-bit? Or is it a CentOS 5.3 64-bit to CentOS 5.5 64-bit?
I don't believe you *really* don't want to do a 'live update' from 32-bit to 64-bit. You should make a backup and do a fresh install of the 64-bit system.
OK, so I thought I could fix this by installing the dependency. After digging through a bunch of cascading dependencies using rpm, I got to the elfutils, which didn't want to install until I used the --ignorearch switch on rpm. However, when I try to install the 64-bit version of rpm-libs on top of that, I still get the complaint about the failed dependency on elfutils.
My first question is: Would I be better off just wiping the machine and installing from scratch at this point, or is there some sane way to get yum reconstructed?
You probably should do a fresh install.
And the second question: did I make a mistake by assuming that the upgrade system would work as it should, or is this just a bug in the upgrade system? And to my first question, does anyone know what else the updater is likely to have broken?
Again, are you sure the updater migrates from 32-bit to 64-bit and NOT just 64-bit < 5.5 to 64-bit 5.5?
Thanks, --Bill
CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
On Sun, 15 Aug 2010 19:57:04 -0400, Robert Heller wrote
At Sun, 15 Aug 2010 16:09:13 -0700 CentOS mailing list centos@centos.org wrote:
<snip>
Is there really an updater that goes from 32-bit to 64-bit? Or is it a CentOS 5.3 64-bit to CentOS 5.5 64-bit?
Well, the system was 32-bit, and it came up running a 64-bit kernel after the upgrade...
I don't believe you *really* don't want to do a 'live update' from 32-bit to 64-bit. You should make a backup and do a fresh install of the 64-bit system.
That's the way I'm leaning...
<snip>
And the second question: did I make a mistake by assuming that the upgrade system would work as it should, or is this just a bug in the upgrade system? And to my first question, does anyone know what else the updater is likely to have broken?
Again, are you sure the updater migrates from 32-bit to 64-bit and NOT just 64-bit < 5.5 to 64-bit 5.5?
Not certain of anything, we're not dealing with a documented commercial product here. ;-) I just ran it to see if it would work as advertised on the installation menu.
Thanks, --Bill
On Sun, Aug 15, 2010 at 5:16 PM, listmail listmail@entertech.com wrote:
On Sun, 15 Aug 2010 19:57:04 -0400, Robert Heller wrote
At Sun, 15 Aug 2010 16:09:13 -0700 CentOS mailing list centos@centos.org wrote:
<snip> > Is there really an updater that goes from 32-bit to 64-bit? Or is > it a CentOS 5.3 64-bit to CentOS 5.5 64-bit?
Well, the system was 32-bit, and it came up running a 64-bit kernel after the upgrade...
I don't believe you *really* don't want to do a 'live update' from 32-bit to 64-bit. You should make a backup and do a fresh install of the 64-bit system.
That's the way I'm leaning...
It might help if you gave us some real information, like what hardware you're running, which actual version of CentOS and the kernel you are (and were) running, etc. Otherwise we're stabbing for a needle in a haystack.
I don't ever remember running a 'yum update' when I was using the 32-bit version and having it update me to a 64-bit kernel. I had to make that choice on my own first.
Mark
On Sun, 15 Aug 2010 17:20:41 -0700, Mark wrote
It might help if you gave us some real information, like what hardware you're running, which actual version of CentOS and the kernel you are (and were) running, etc. Otherwise we're stabbing for a needle in a haystack.
I don't ever remember running a 'yum update' when I was using the 32-bit version and having it update me to a 64-bit kernel. I had to make that choice on my own first.
Hardware: Supermicro with Intel 64-bit CPU
The OS was CentOS 5.3 32-bit. I upgraded with the CentOS 5.5 x86_64 DVD, as stated earlier. I did not do the upgrade using yum, the upgrade broke yum.
Cheers, --Bill
At Sun, 15 Aug 2010 17:30:31 -0700 CentOS mailing list centos@centos.org wrote:
On Sun, 15 Aug 2010 17:20:41 -0700, Mark wrote
It might help if you gave us some real information, like what hardware you're running, which actual version of CentOS and the kernel you are (and were) running, etc. Otherwise we're stabbing for a needle in a haystack.
I don't ever remember running a 'yum update' when I was using the 32-bit version and having it update me to a 64-bit kernel. I had to make that choice on my own first.
Hardware: Supermicro with Intel 64-bit CPU
The OS was CentOS 5.3 32-bit. I upgraded with the CentOS 5.5 x86_64 DVD, as stated earlier. I did not do the upgrade using yum, the upgrade broke yum.
You should not have done this. I guessing that the CentOS 5.5 installer is not bulleted proofed for this case (eg it assumed that you know what you were doing). In any case, this is not a supported way to go (documented or not). The 'updater' on the CentOS 5.5 x86_64 DVD is meant to go from CentOS < 5.5 x86_64 to CentOS 5.5 x86_64, NOT CentOS < 5.5 32-bit to CentOS 5.5 x86_64.
You should have made a backup and then did a fresh install.
The only good way to properly fix things is to backup your stuff (eg /home/ and stuff like /var/www/ (if you are running a web server)). Maybe backup selected files under /etc/ (eg passwd, shadow, group, etc.) and then do a fresh install (*reformat* /, /boot, /usr, etc.).
Cheers, --Bill _______________________________________________ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
On Sun, 15 Aug 2010 20:46:04 -0400, Robert Heller wrote
You should not have done this. I guessing that the CentOS 5.5 installer is not bulleted proofed for this case (eg it assumed that you know what you were doing). In any case, this is not a supported way to go (documented or not). The 'updater' on the CentOS 5.5 x86_64 DVD is meant to go from CentOS < 5.5 x86_64 to CentOS 5.5 x86_64, NOT CentOS < 5.5 32-bit to CentOS 5.5 x86_64.
You should have made a backup and then did a fresh install.
The only good way to properly fix things is to backup your stuff (eg /home/ and stuff like /var/www/ (if you are running a web server)). Maybe backup selected files under /etc/ (eg passwd, shadow, group, etc.) and then do a fresh install (*reformat* /, /boot, /usr, etc.).
Oh well, it would have been nice if it worked. I'll scrub the system and restore a few things from the backups, although I intended to re-purpose the host anyway.
Thanks for your input.
--Bill