Feisty Fawn and Software RAID
April 12, 2007 – 2:13 pmIt turns out there’s a race condition in Feisty Fawn, which can cause software RAID sets to not be set up on boot. This is problematic if you have your root partition on software RAID
Bug #75681 discusses this in some detail, although there are several suggestions on how to fix it.
I first hit this bug on a local machine, then had to the same upgrade on a machine in a different country. Needless to say I wanted to get it right. I’m archiving my notes here as I’m sure I’ll need them eventually. This race condition has probably already been fixed in Feisty, but it’s not worth risking on a remote machine.
First of all, there is some new management involved in setting up software RAID under feisty, so you need to make sure you read the documentation for the mdadm package. Every time an initramfs is generated it will generate a warning:
cp: cannot stat `/etc/udev/rules.d/85-brltty.rules’: No such file or directory
W: mdadm: unchecked configuration file: /etc/mdadm/mdadm.conf
W: mdadm: please read /usr/share/doc/mdadm/README.upgrading-2.5.3.gz .
W: mdadm: no arrays defined in configuration file.
W: mdadm: falling back to emergency procedure in initramfs.
Following those instructions, you are told to check the configuration in /etc/mdadm/mdadm.conf and compare with the output of /usr/share/mdadm/mkconf. Once you’ve done that, you can remove /var/lib/mdadm/CONF-UNCHECKED and re-run update-initramfs -u -k all to regenerate your initramfs images.
The particular race condition that I mentioned above occurs because udev hasn’t had time to stabilise before mdadm tries to create the array, which means mdadm can’t find the devices and fails. The fix suggested in the bug report is to insert udevsettle into the initramfs at an appropriate point, and recreate the initramfs images:
# update-initramfs -u -k all
This works, at least as of today. I don’t know if the bug is actually still a problem or not - I didn’t want to risk it./