Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 98675 - reboot: /dev busy, can't unmount root
Summary: reboot: /dev busy, can't unmount root
Status: RESOLVED FIXED
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: [OLD] baselayout (show other bugs)
Hardware: x86 Linux
: High normal (vote)
Assignee: Gentoo's Team for Core System packages
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2005-07-11 07:23 UTC by Eugene Pavlovsky
Modified: 2005-09-13 20:17 UTC (History)
2 users (show)

See Also:
Package list:
Runtime testing required: ---


Attachments
umount: respect -n when specified with -r (util-linux-2.12q-remount-respect-nomtab.patch,416 bytes, patch)
2005-09-13 02:12 UTC, Derick Swanepoel
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Eugene Pavlovsky 2005-07-11 07:23:54 UTC
Sometimes, when I reboot, unmounting filesystems tells me that /dev is busy, and
then it can't unmount (remount ro) the root filesystem, and asks for the root
password for maintenance. What can be the problem?

Reproducible: Sometimes
Steps to Reproduce:
1.reboot

Actual Results:  
/dev busy
can't unmount(remount read-only) root 

Expected Results:  
clean reboot
Comment 1 Stian Skjelstad 2005-07-11 07:45:35 UTC
What program has devices in /dev open ?

lsof | grep /dev/
Comment 2 Eugene Pavlovsky 2005-07-12 01:52:41 UTC
sorry, i didn't have time to enter my password - this "emergency maintenace,
enter root password or press CTRL+D" prompt hanged for a couple of seconds, then
the machine rebooted.  will try to check if the problem shows again.
Comment 3 Martin Schlemmer (RETIRED) gentoo-dev 2005-07-13 02:39:07 UTC
USB keyboard via modules?
Comment 4 Eugene Pavlovsky 2005-07-13 04:14:57 UTC
no, it's a laptop. i've got a usb mouse, though.
Comment 5 Derick Swanepoel 2005-09-12 06:26:39 UTC
I think I have discovered a reason why this could happen. If the 
mount_readonly() function in /etc/init.d/halt.sh fails to unmount a 
filesystem, it is run a second and third time. On the third try, 
mount_readonly() uses "umount -n -r" and fails with /dev because for some 
reason it tries to create a /etc/mtab~xxxx lock file (even though the -n 
option is used) and by that time / has already been remounted readonly. At 
that stage the whole process fails and dumps you back in the shell. 
 
The reason this happened to me is because I have an entry in my /etc/fstab 
which bind-mounts /proc to some other location (which doesn't always exist). 
Because mount_readonly() only specifies the mountpoint to mount/unmount, mount 
tries to remount the wrong /proc (which has a non-existent mountpoint), 
causing it to fail which then screws up the whole unmounting process. 
 
Perhaps this is a bug in umount (it doesn't seem to honour the -n option when 
-r is used). My problem can be solved, however, by specifying both the 
filesystem and mountpoint to mount in /etc/init.d/halt.sh's mount_readonly() 
function. 
 
Reproducible: Always 
Steps to Reproduce: 
1. Add the following line to /etc/fstab: 
/proc            /nowhere       none          bind,noauto    0 0 
 
2. Reboot 
 
Actual results: 
umount: udev busy - remounted read-only 
can't create lock file /etc/mtab~4628: Read-only file system (use -n flag to 
override) 
Comment 6 SpanKY gentoo-dev 2005-09-12 18:45:06 UTC
what version of util-linux ?  umount with 2.12q-r1 seems to only read /etc/mtab
although i can confirm that your /proc bind entries does cause issues ...
Comment 7 Derick Swanepoel 2005-09-13 00:30:48 UTC
util-linux-2.12i-r1 
baselayout-1.11.13-r1 
 
I will try with util-linux-2.12q-r1. 
Comment 8 Derick Swanepoel 2005-09-13 02:12:33 UTC
Created attachment 68338 [details, diff]
umount: respect -n when specified with -r

Actually, it seems umount does write to /etc/mtab (see mount/umount.c:358),
which is exactly the place that causes this failure. With the -n and -r options
specified, the logic there seems to be:

1. Try to unmount
2. If it failed, try to remount ro
3. If ro remount succeeded, update mtab

The problem is that it tries to update mtab regardless of the -n option. I've
attached a simple patch that fixes the problem.
Comment 9 SpanKY gentoo-dev 2005-09-13 20:17:29 UTC
just need to tweak the check with mtab_is_writable() and patch is good to go

added to cvs, thanks