[Bug 244421] Re: hardy mounting on root file system failed device or resource busy

[netztier]

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.

-- 
hardy mounting on root file system failed device or resource busy
https://bugs.launchpad.net/bugs/244421
You received this bug notification because you are a member of Kernel
Bugs, which is subscribed to initramfs-tools in ubuntu.