boot on md raid drives fails

[Grégoire Cachet]

Binary package hint: initramfs-tools

I'm using initramfs-tools 0.85eubuntu1.

I can't boot my system without adding break=mount to the grub boot command.

A lot of bug reports say that these issues should be fixed with 0.85eubuntu1 and thus are marked "fix released", but it is not fixed here.

It looks like script/init-premount/udev is not finished to load my drives before script/init-top/mdadm is called which breaks the boot process :(. It explains why it does boot while adding break=mount to the grub boot command.

[nomenquis (philip-lawatsch)]

I can confirm this. Just updated my system from edgy and am hitting this bug now. The exact same workaround works for me. By the time my usb keyboard has initialised i can simply close the shell and the bootup will work.

[Jared Rhine (jared-wordzoo)]

Also confirmed. Happens on Feisty Herd 4-5 at least.

My configuration:

2 sata drives

sda1: /boot ext3, 1gb, bootable
sda2: /srv/spare ext3, 20gb
sda3: swap, 4gb
sda4: RAID physical, 134gb

sdb1: /srv/boot-backup ext3, 1gb
sdb2: /srv/spare2 ext3, 20gb
sdb3: swap, 4gb
sdb4: RAID physical, 134gb

md0: sda4+sdb4 RAID-0, root (/), ext3

Installation goes fine, no problems. On boot, the console shows:

* Mounting root file system
* Loading MD modules
* md: raid0 personality registered/Success: loaded module raid0.
* Begin: Assembling all MD arrays
* mdadm: No devices listed in conf file were found.
* Failure: failed to assemble all arrays
* Waiting for root file system...
[...]
* Mounting /root/dev on /dev/.static/dev failed: No such file...
* Target filesystem doesn't have /sbin/init

And drops into an initramfs prompt. At that prompt, I can 'mdadm --assemble /dev/md0' without problems.

Adding a 'break=mount' to the GRUB prompt, and then exiting when dropped into the prompt, allows the boot to proceed without any problem.

Happens on both a white-box server and a virtual machine running in Parallels.

For quite a while, I interpreted this behavior to mean that installing Ubuntu Feisty onto a RAID-0 root was not supported.

I'm reinstalling from scratch because my Edgy upgrade broke the machine in a way I interpreted as initrd driver issues. In retrospect, it was probably this bug that hit me during upgrade.

[Obi Bok (obibok)]

I can confirm this as well. I've tested Feisty daily images up to 20070411 and the same situation occurs. I'm not sure if the problem is with initramfs-tools or udev (or other package) but the bottom line is RAID/MD is broken.

Hoping for a fix before Feisty final release. Still using Dapper here but can't wait to go through the big upgrade to have the latest and the greatest.

[nomenquis (philip-lawatsch)]

I've also still got the problem, however i've (hopefully) some more information. The disks in the array are on a nvidia sata controller. So, I want the sata_nv module to be loaded before the mount scripts should try to mount the disks. However, I noticed that without any boot options the scripts simply stop before loading said module. If i pass a break=mount and then exit the shell again the sata_nv module is loaded by the time (because it looks like my usb keyboard is initialised after the sata_nv module is loaded so i can't exit earlier) and the bootup process works

[Martin Pitt (pitti)]

I have a similar problem: While testing expert install with the mdadm module, I put /boot on /dev/sda6 and a raid-1 on /dev/sda5 and /dev/sda7. Booting the installed system failed because apparently initramfs did not wait until the raid was completely assembled. There seems to be a race condition somewhere. At the prompt I can do 'mount -t ext3 /dev/md0 /root', press Ctrl+D and booting continues happily.

http://people.ubuntu.com/~pitti/tmp/raid1-bootfail-1.jpg and http://people.ubuntu.com/~pitti/tmp/raid1-bootfail-2.jpg show two screenshots of the booting.

[Matt Zimmerman (mdz)]

http://people.ubuntu.com/~scott/packages/initramfs-tools_0.85eubuntu10_all.deb fixes the problem for me, after manually reproducing it with a perverse udev configuration

[Quentin Stafford-Fraser (quentinsf)]

Matt - thanks - we were having the same problem and it certainly solved it for us.

[Taavi Ilves (ilvez)]

May this bug cause my raid1 swap partition not to be mounted correctly? I will try to make a more informative report later, not at home right now.

[Quentin Stafford-Fraser (quentinsf)]

Mmm. Actually - re my previous comment - there still seems to be about a 30% failure rate.

[Mike H (mike-heden)]

Does anyone have a fix for this yet?

I have the same problem on a newly built raid under Ubuntu Feisty 7.04 Desktop. The break=mount fix in the relevant kernel line in menu.lst always allows the system to boot, but it will rarely work without. My initramfs-tools is 0.85eubuntu10.

Mike