hardy mounting on root file system failed device or resource busy

Bug #244421 reported by Mark Carey
10
Affects Status Importance Assigned to Milestone
initramfs-tools (Ubuntu)
Expired
Undecided
Unassigned

Bug Description

Upgraded server from 6.06 LTS to 8.04 LTS using the instructions at https://help.ubuntu.com/community/HardyUpgrades

Power the machine down, power back up and some timed the machine fails to mount its root fs and drops me to a BusyBox shell, terminal output looks like (based on attached photo);

root (hd0,0)
 Filesystem type is ext2fs, partition type 0x83
kernel /vmlinuz-2.6.24-19-server root=UUID=159c98b4-db88-438e-8384-fb37d94b20b3 ro quiet
  [Linux-bzImage, setup=0x2a00, size=0x1e25b8]
initrd /initrd.img-2.6.24-19-server
  [Linux-initrd @ 0x1f84f000, 0x7a0522 bytes]

Loading, please wait...
[ 22.411768] 8139cp 0000:00:13.0: This (id 10ec:8139 rev 10) is not an 8139C+ compatible chip
[ 22.411828] 8139cp 0000:00:13.0: Try the "8139too" driver instead.
mount: Mounting /dev/disk/by-uuid/159c98b4-db88-438e-8384-fb37d94b20b3 on /root failed: Device or resource busy
mount: Mounting /root/dev on /dev/.static/dev failed: No such file or directory
mount Mounting /sys on /root/sys failed: No such file or directory
mount: Mounting /proc on /root/proc failed: No such file or directory
Target filesystem doesn't have /sbin/init

BusyBox v1.1.3 (Debian 1:1.1.3-5ubuntu12) Built-in shell (ash)

However sometimes the machine starts up fine, in which case the terminal output looks like (additional photo to follow)

root (hd0,0)
 Filesystem type is ext2fs, partition type 0x83
kernel /vmlinuz-2.6.24-19-server root=UUID=159c98b4-db88-438e-8384-fb37d94b20b3 ro quiet
  [Linux-bzImage, setup=0x2a00, size=0x1e25b8]
initrd /initrd.img-2.6.24-19-server
  [Linux-initrd @ 0x1f84f000, 0x7a0522 bytes]

Loading, please wait...
[ 22.411768] 8139cp 0000:00:13.0: This (id 10ec:8139 rev 10) is not an 8139C+ compatible chip
[ 22.411828] 8139cp 0000:00:13.0: Try the "8139too" driver instead.
* Setting the system clock

careys@jersey:~$ ls -lah /dev/disk/by-uuid/159c98b4-db88-438e-8384-fb37d94b20b3
lrwxrwxrwx 1 root root 10 2008-07-01 16:04 /dev/disk/by-uuid/159c98b4-db88-438e-8384-fb37d94b20b3 -> ../../sda6

I have examined the jumper settings of my HDDs as a bug suggested that libata is much more strict on timings for reply, even with Primary Master, Primary Slave and Secondary Master all jumpered correctly (no cable select) and in the correct positions on the IDE ribbon cables I still get this problem.

Any suggestions?

Revision history for this message
Mark Carey (careym) wrote :
Revision history for this message
Mark Carey (careym) wrote :
Revision history for this message
Marc Luethi (netztier) wrote :

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.

Revision history for this message
Phillip Susi (psusi) wrote :

8.04 has reached end of life and is no longer supported. Are you still having this issue in a supported release?

Changed in initramfs-tools (Ubuntu):
status: New → Incomplete
Revision history for this message
Launchpad Janitor (janitor) wrote :

[Expired for initramfs-tools (Ubuntu) because there has been no activity for 60 days.]

Changed in initramfs-tools (Ubuntu):
status: Incomplete → Expired
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.