It 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:
[code]
update-initramfs: Generating /boot/initrd.img-2.6.20-14-generic
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.
[/code]
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:
[code]
# echo “/sbin/udevsettle –timeout=10” >> /usr/share/initramfs-tools/scripts/init-premount/udev
# update-initramfs -u -k all
[/code]
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./
One reply on “Feisty Fawn and Software RAID”
I ran into the same problem (race condition) with a more or less current (2013-09-20) daily Debian-Installer build. There at least, it also worked to append “rootdelay=5” to the kernel command line parameters. This parameter is evaluated for example by the udev hook. Its already there, so no invasive changes to system files (like initramfs-hooks) are necessary, that might be overwritten by future updates. That might not have been there 6 and a half years ago though :).
Thanks for your help anyway. Sad that the problem is still there for some of us.