Fighting the dmraid/mdadm battles in initrd for RHEL/Centos 5.x

dmraid is a technology to turn on-board fake-RAID (fRAID) systems into usable/bootable linux machines. It works for what it does, but you do need to be careful, as many of the fRAID chipsets have interesting … er … features. Yeah. Thats it, features. mdadm is a pure software version, requiring no assist from the bios. It can handle setting up RAID devices, and is our preferred way of creating RAID in software. These two systems are incompatible, and if you don’t have fRAID support on your motherboard, you really can’t use dmraid. mdadm has a mode for RAIDing full drives rather than partitions, which is roughly akin to what fRAID does. Ok, so why is this a problem?

mkinitrd, the 5.x versions in RHEL/Centos 5.x, only seem to know dmraid. Not mdadm. Which means when you install a new kernel, and create the initrd for that kernel, there is a fairly good probability that you will get a kernel panic on boot with the new kernel. The reason for this is the dependence upon dmraid, which is hardwired into the mkinitrd. Good news and bad news. As of 6.x, mkinitrd now does the right thing. It pulls mdadm and /etc/mdadm.conf into the initrd. Bad part of this is, that without serious surgery … a couple of ‘rpm -ivh –force –nodeps …’ it won’t work. Other potentially good news is dracut looks like it will do “the right thing(&TM;)” correctly, and in a cross distribution manner. So it will get better, eventually. But until then, we are stuck with fRAID dmraid and mdadm software RAID not playing nice in mkinitrd. We might simply have to patch this ourselves, and maintain our own mkinitrd script which also does the right thing. Sigh.