no devices found for /dev/md0 at startup

[Grégoire Cachet]

I'm running Feisty and linux-image-2.6.19-7-generic fails during the boot. My root partition is on /dev/md0 (raid1 over sda2 and sdb2). It works fine with linux-image-2.6.17-10-generic.

I have the same issue with linux-image-2.6.19-5-generic and linux-image-2.6.19-6-generic.

I get a BusyBox shell and this message when trying to run /scripts/local-top/mdadm by hand :

mdadm: no devices found for /dev/md0

I took a look at bug #71318 since I use a VIA chipset for my SATA drives. With linux 2.6.17, I use via82cxxx. I tried to add pata_via and pata_mpiix to /etc/initramfs-tools/modules and then regenerated the initrd image, but it does not fix the problem. Besides I looked for /etc/modprobe.d/blacklist-pata in my system and I don't have this file.

I don't really know about how initramfs works, so I can go deeper in it to see whether something is missing there or if it's in the kernel itself.

[Ben Collins (ben-collins)]

If you used the via82cxxx in edgy, then your drives were hda2 and hdb2, right?

More than likely you need to tell mdadm that you are using sda and sdb now. Check /etc/mdadm/mdadm.conf.

I suggest instead of device names, you use the UUID symlinks in /dev/disk/by-uuid/, so instead of /dev/sdb, you would use /dev/disk/by-uuid/XXXXXXXX-part2, for instance.

[Fabio Massimo Di Nitto (fabbione)]

can you please add a dmesg output from .17 and .19 ? that will help to understand what's happening.

Fabio

[Grégoire Cachet (greg-zwiffer)]

Ben> actually this is sda2 and sdb2 on my system ... And there is nothing in my mdadm.conf to tell about sda and sdb.

Fabio> I can't get a dmesg of linux 2.6.19 because it doesn't boot at all. Tell if I can get some interesting informations from the busybox shell, because I don't know how.

I included a result of dmesg for linux 2.6.17, a result of lshw with all my hardware devices, a lsmod of linux 2.6.17 so that you can know which modules are loaded, my mdadm.conf and a result of mdadm --detail /dev/md0.

[Ben Collins (ben-collins)]

Please retest against 2.6.20-2 when it is available in the feisty archive.

[Grégoire Cachet (greg-zwiffer)]

Well, I found something interesting ...

The kernel starts when I add quiet=n break=mount arguments to the boot command line in grub. Then, I hit Ctrl+D and it boots right. It works for 2.6.19 and 2.6.20.

If I remove quiet=n or break=mount, it just breaks like before.

I think there is an issue with a device that need more time to start. I haven't investigated further, but if you need some precise informations about what's going on, I can get them with some directions.

[Jonathan Hseu (vomjom-vomjom)]

Confirming that this bug exists and that it still happens on 2.6.20-2

[Sami J. Laine (sjlain)]

This bug seems to be still active in both linux-image-2.6.20-9-i386 and linux-image-2.6.20-generic.

With both images boot failes with RAID1 root. Updating initramfs doesn't seem to have any effect on this.

[Pascal Rolle (squale)]

I had the same problem. today's update fixed it for me (with 2.6.20-15-386 kernel image)

[Launchpad Janitor (janitor)]

[Expired for linux-source-2.6.20 (Ubuntu) because there has been no activity for 60 days.]