Bug 139642 - mount in a startup complains "already mounted or busy"
mount in a startup complains "already mounted or busy"
Status: CLOSED DUPLICATE of bug 139656
Product: Fedora
Classification: Fedora
Component: util-linux (Show other bugs)
rawhide
All Linux
medium Severity medium
: ---
: ---
Assigned To: Karel Zak
Ben Levenson
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2004-11-16 23:42 EST by Michal Jaegermann
Modified: 2007-11-30 17:10 EST (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2005-03-22 04:41:58 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
patch to make 'mount' and 'df' behave better (1.16 KB, patch)
2004-11-19 00:16 EST, Michal Jaegermann
no flags Details | Diff

  None (edit)
Description Michal Jaegermann 2004-11-16 23:42:00 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):
util-linux-2.12a-16

How reproducible:
100%
Comment 1 Michal Jaegermann 2004-11-17 01:03:44 EST
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
this way:

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.
Comment 2 Michal Jaegermann 2004-11-17 01:06:35 EST
Forgot to add, what should be obvious, that 'df' is also rather
unhappy with the current arrangement.
Comment 3 Ricardo Veguilla 2004-11-17 18:54:26 EST
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.  
Comment 4 Michal Jaegermann 2004-11-19 00:16:54 EST
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?
Comment 5 Elliot Lee 2004-12-01 18:23:57 EST
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".
Comment 6 Michal Jaegermann 2004-12-01 19:15:28 EST
See long discussione in bug #139656.  I believe that this is it.
Comment 7 Karel Zak 2005-03-22 04:41:58 EST

*** This bug has been marked as a duplicate of 139656 ***

Note You need to log in before you can comment on or make changes to this bug.