2009-07-07

RHEL/CentOS bi-arch problems

Posted in Computers, Personal, PlanetDebian, rant at 10:57 CEST (+0200) by sven

Oh well, I think RHELs support for multiple architectures installed at the same time (and thus the same support in CentOS) really needs some rethinking.
While the following might not be able to happen with the default installation media (I didn’t verify), it still can happen if you run your own mirrors and actually need both architectures listed in your yum repositories…
Anyway, what happened today is just one example of how the multi-arch support caused problems for me:

On a Xen Dom0, I needed to apply a kernel upgrade (from 2.6.18-92something to 2.6.18-128something) and as a result, a reboot. At this point you should memorize that the old kernel worked quite fine and all I did was a yum update followed by a reboot. A procedure I did on quite a number of Dom0 machines in the past weeks.

Well, the reboot this time didn’t work, the kernel halted after printing:
request_module: runaway loop modprobe binfmt-464c

Well, reboot again, select old kernel, systems boots fine….

What happened was that both the x86_64 and i686 versions of the old kernel was installed, so yum update updated both, probably first the x86_64 version, then the i686 version (but I didn’t check). Well, while for the old kernel, grub booted the x86_64 kernel with the x86_64 initrd, for the new kernel it tried to boot the i686 kernel with the x86_64 initrd. (verified by unpacking the initrd and the vmlinuz kernel image and running file on the binaries therein)

Now the big question is: How could the stupid yum/rpm/postinstall script system end up doing this? It is supposed to warn about conflicts if two packages ship different versions of the same file AFAICT, but there is no way the i686 and x86_64 versions of /boot/vmlinuz* could be identical. So there should have been a warning about this. And after that, how come the mkinitrd tool doesn’t even try to check wether the kernel architecture and that of the initrd binaries match? It happily packed 64bit binaries and 64bit kernel modules(sic!) when run against a 32bit kernel….

OK, enough of my frustration….
I really wished I had to maintain not RHEL/CentOS machines but Debian (based distro) machines here at work. Unfortunately, that won’t happen for various reasons…

While the bi-arch support in RHEL/CentOS is helpful in many ways, RPM and the way bi-arch works on these distros caused almost as much trouble to me already as it helped avoid.