Comment 30 for bug 158918

Teej - you're welcome. Just holler if there's anything else I can gather to help out.

As a final anecdote, I was able to work around the problem for this particular system by hacking on mdadm's hook in initramfs. Because I don't need to have the system boot from a RAID array, I was able to just ignore whatever it is that the mdadm hook is trying to do by stuffing an "exit 0" at the head of the script.

In case it helps anyone else in a similar situation, this is what I came up with (both to restore a buggered system and to tweak things to avoid the problem for now). The following instructions assume for the sake of brevity that you've already opened a terminal and are pretending to be root with "sudo bash" or similar (prepend "sudo" to all the command-line stuff otherwise).

1. Boot with the 9.10 live CD.

2. Mount the relevant partition. In this case, I've been messing with /dev/sdb1, but whatever floats your board:

> mount /dev/sdb1 /mnt

3. To make life easier for a bit, chroot to the mounted drive:

> chroot /mnt

4. Modify the mdadm hook in initramfs so that it has no effect. Open /usr/share/initramfs-tools/hooks/mdadm and insert "exit 0" on line 8.

4a: To ensure I wouldn't get bitten again until I wanted to, I made the mdadm hook read-only and made it immutable. This may cause a future upgrade of mdadm to fail - you could lock down the version of mdadm as well with apt or synaptic if you so wished.

> chmod -r /usr/share/initramfs-tools/hooks/mdadm
> chattr +i /usr/share/initramfs-tools/hooks/mdadm

5. Rebuild the relevant initrd to your kernel. I haven't updated yet, so I'm still on 2.6.31-14-generic at this time - change this to match whatever kernel you're currently running:

> update-initramfs -k 2.6.31-14-generic -u

6. Bail from the chroot and update grub to pick up the new ramdisk image. You'll need to supply the mount point for your partition and the root device name for that partition. Mine were /mnt and /dev/sdb respectively:

> exit
> grub-install --root-directory=/mnt /dev/sdb

Assuming there were no errors, you can now reboot. The system should come up as normal, and mdadm will be usable. Also, any future updates to the ramdisk image won't result in the changes being blown away, which is why I didn't just take a copy of the ramdisk image and restore that.

Again, not that this procedure is *only* applicable to systems that don't boot from a RAID array, but are interested in using one after the kernel is started.