Red Hat Bugzilla – Bug 139642
mount in a startup complains "already mounted or busy"
Last modified: 2007-11-30 17:10:54 EST
Description of problem:
Afer recent rawhide updates I am greeted during a startup
with numerous message of that sort:
none already mounted or /dev/pts busy
/dev/sda10 already mounted or /boot busy
It turns out that 'mount' changed its behaviour. Before
'mount -a' was not trying to mount already mounted file
systems and was just silent. Currently doing 'mount -a' results
in something like that:
mount: /dev/sda10 already mounted or /boot busy
mount: /dev/sda14 already mounted or /home busy
mount: /dev/sda13 already mounted or /opt busy
mount: /dev/sda12 already mounted or /usr busy
This is not really a fault of 'mount' as the current version
of 'util-linux' package was installed on 2004/Oct/15, i.e.
a month ago. The last series of updates includes a lot of
different packages but 'glibc-2.3.3-77' seems to be the most
likely candidate to cause that ruckus.
Version-Release number of selected component (if applicable):
Further checks reveal is that an actual problem is that an output
of 'mount' is "loosing" some file systems. This is independent
from a kernel used or from an arch.
Replacing /etc/mtab with a symlink to /proc/mounts makes (apart
of other potential problems :-) 'mount -a' to compain now in
mount: none already mounted or /sys busy
mount: according to mtab, /sys is already mounted on /sys
but not troubles with anything else. That is because there
is the following line in /proc/mounts
/sys /sys sysfs rw 0 0
After 'umount /sys; mount -a' all further 'mount -a' are quiet
as "/sys" line now is replaced with:
none /sys sysfs rw 0 0
OTOH with such hack every "bind" mount gets repeated on each
'mount -a', which is really expected. So the real issue
is that for some reasons a content of /etc/mtab gets garbled
and nothing seems to add missing entries.
Forgot to add, what should be obvious, that 'df' is also rather
unhappy with the current arrangement.
might be related, if you do "cat /proc/mounts > /etc/mtab"
and then proceed to mount/umount partitions, everything seems to work
ok. This could mean that the problem is in the initscripts.
Created attachment 107029 [details]
patch to make 'mount' and 'df' behave better
The attached change in rc.sysinit makes only a small mess on my system
(a bunch of inconsequential complaints on a shutdown) instead of a serious
one when things misbehave while running.
To filter /etc/mtab to remove duplicates of thigs like /proc or /sys,
as that seem to be responsible for remaining troubles, would not be
too hard while using unly tools from /bin and /sbin. 'sort -u -k 3,3 /etc/mtab'
gives a crude first approximation. Why such hacks are suddenly needed?
Sounds like the source of the problems is /etc/mtab going wonky.
/etc/mtab must stay separate from /proc/mounts, so we need to find the
source of the /etc/mtab "corruption".
See long discussione in bug #139656. I believe that this is it.
*** This bug has been marked as a duplicate of 139656 ***