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

netztier netztier at bluewin.ch
Tue Aug 19 17:52:34 UTC 2008

I suffered a similar problem, see my question linked to this Bug or

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

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


# 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
You received this bug notification because you are a member of Kernel
Bugs, which is subscribed to initramfs-tools in ubuntu.

More information about the kernel-bugs mailing list