2009-07-07
RHEL/CentOS bi-arch problems
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.
See also Unifying config file syntaxes with nesting
See also Why is VoIP/SIP so hard?
See also init script generators
Permalink
Roguelazer said,
July 7, 2009 at 11:46 CEST (+0200)
I’m surprised that this is the first time you’ve run into this. Many libraries (e.g., tclx) come in both 32- and 64-bit versions, try to install both in /usr/lib/, and use the same exact filename. rpm seems to have no problems with installing both and just silently overwriting whichever one is installed first. >.<
sven said,
July 7, 2009 at 13:32 CEST (+0200)
No, I didn’t really have this issue for the first time, but I also had the problem of two packages sharing a file with different content (though it was a whitespace-only change in a text based configuration – and no, whitespace was not relevant to syntax) not being installed side-by-side because of that differing content.
Perhaps overwriting is only done when installing the exact same package (name and version), with just the architecture differing, but if package names differ, the contents are checked for differences…
Stupid in many ways IMHO. Though I can’t offer a less stupid, working solution. Except such packages to declare some conflict with other architecture versions of themself. Not sure how conflicts get resolved in the RPM world though, I just know dpkg/deb is rock-solid in this regard.
Anonymous said,
July 7, 2009 at 16:14 CEST (+0200)
RHEL barely supports *one* architecture at a time.
sven said,
July 8, 2009 at 07:35 CEST (+0200)
Unfortunately, I agree with you. However, in medium to big companies, you really need the guarantee for commercial support. Be it for software like Oracle which is only officially supported on certain operating systems or for hardware like fibre channel adapters which only has official drivers for certain versions of certain operating systems….
So all in all, there isn’t much choice there…