Comment 3 for bug 244421

I suffered a similar problem, see my question linked to this Bug or https://answers.launchpad.net/ubuntu/+question/42403

On ubuntuforums.org (http://ubuntuforums.org/redirect.php?t=772107), had found suggestions that dmraid was somehow conflicting with initrd accessing drives via /dev/disk/by-uuid/<uuid-of-disk>. However, I positively know that I never installed dmraid on my machine. Yet, I was curious and removed all disks forming arrays from the system, and voilà, it booted straight.

The thread on ubuntuforums.org suggested that while accessing drives by UUID would not work, accessing them via /dev/mapper/sdX would still work.

This I wanted to know: I reconnected the PATA drive pair (RAID1), rebooted and let it drop into a busybox, then manually mounted /dev/mapper/sda1 to /root and typed "exit", so the busybox would continue the boot process - which it happily did!

I then went ahead and changed /boot/grub/menu.lst, so that the kernel options no longer read:

# kopt=root=UUID=68cc229b-41c2-4a7b-b190-e261f92aca2c ro

but

# kopt=root=/dev/mapper/sdc1 ro

(my boot drive becomes sdc when the SATA drives are connected)

Running update-grub then made sure that all grub menu entries now reference the root partition like this and no longer by UUID. Reconnected my SATA RAID drive pair as well and rebooted: all is well.

I have too little knowledge to know if this problem is related to initramfs-tools, the kernel or to grub - maybe someone with more insight can jump in here. I think that accessing the drive by it's UUID is the better approach, so I'd think it were cool if we could get that functionality back.