Bug 139656 - initscripts-7.96-1, /dev/pts already mounted or busy
initscripts-7.96-1, /dev/pts already mounted or busy
Product: Fedora
Classification: Fedora
Component: initscripts (Show other bugs)
All Linux
medium Severity medium
: ---
: ---
Assigned To: Bill Nottingham
: 139642 141749 (view as bug list)
Depends On:
Blocks: FC4Blocker
  Show dependency treegraph
Reported: 2004-11-17 04:03 EST by Lars G
Modified: 2014-03-16 22:50 EDT (History)
7 users (show)

See Also:
Fixed In Version: 8.01-1
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2004-12-06 15:32:02 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
Workaround for 'pts busy' and other problems described in my comment above. (1.99 KB, patch)
2004-11-17 14:24 EST, Mickey Stein
no flags Details | Diff
a patch to get correct mounts in startup (1.49 KB, patch)
2004-11-28 14:44 EST, Michal Jaegermann
no flags Details | Diff
much simpler changes (421 bytes, patch)
2004-11-29 14:58 EST, Bill Nottingham
no flags Details | Diff
changes simpler but not too simple (908 bytes, patch)
2004-12-01 01:42 EST, Michal Jaegermann
no flags Details | Diff

  None (edit)
Description Lars G 2004-11-17 04:03:12 EST
initscripts-7.96-1 says /dev/pts is already mounted or busy at boot.
nevertheless /dev/pts devices are present after boot.
the same was with /sys, but commenting it out in /etc/fstab resolved
this error and
/sys is still mounted for me.

this version greatly improved startup time, good work!!


ps. a second thing was that i had to move the wep encryption key
string from keys-ethX file to ifcfg-ethX, to get my wireless card
connect to the router again.
maybe i will bugzilla this as a seperate entry.
Comment 1 Joel Rittvo 2004-11-17 04:59:45 EST
I also get the "already mounted or busy" comment for FAT32 and NTFS
drives that I mount through fstab entries, but they also are mounting
correctly and working fine despite the error message during bootup.
Comment 2 Mickey Stein 2004-11-17 14:22:09 EST
Count me in as well: I came up with a workaround and a potential
reason. I'll attach the patch so someone that understands the things
done between where I moved the mount -a * * * statements from in the
old version *to* in the new version can comment on it. 

The other two symptoms following 'busy pts' for me were that although
my 2nd disk (/d2 mount point) was mounted rw and could be accessed, it
was not in the /etc/mtab table and was failing on the mount -a
statement. The last problem I noticed was that my swapfile was not
mounted correctly. All of this was 'cured' by moving the "mount -a
nonfs,* * * *" statement & swapon statement down below the mount -n
statements that only put entries into mtab.  It also looks as if the
mtab needs to be cleared before the mount -a.

I'm not sure I can attach & comment (or walk and chew gum) at once, so
I'll attach the workaround I came up after this comment. 
Comment 3 Mickey Stein 2004-11-17 14:24:13 EST
Created attachment 106904 [details]
Workaround for 'pts busy' and other problems described in my comment above. 

Ok, I see now I could have combined this entire mess into one, but since I
didn't know, the information regarding this workaround is in my previous
Comment 4 Bill Nottingham 2004-11-17 15:43:52 EST
OK, this is just because all the mounting is done before the root FS
is read-write, so /etc/mtab is all wrong.
Comment 5 Mickey Stein 2004-11-17 16:51:30 EST
I'd come up with that by putting a $cp /etc/mtab /etc/mtab.sav, along
with an $echo $state right after this:

---- cut from rc.sysinit ---

# Remount the root filesystem read-write.
update_boot_stage RCmountfs
state=`LC_ALL=C awk '/ \/ / && ($3 !~ /rootfs/) { print $4 }'
[ "$state" != "rw" -a "$READONLY" != "yes" ] && \
  action $"Remounting root filesystem in read-write mode: " mount -n
-o remount,
rw /


The $echo $state showed 'ro' during boot and the content of
/etc/mtab.sav was :

/dev/hda6 / ext3 rw 0 0
none /proc proc rw 0 0

But, doesn't this still mean that the $mount -a *** has to be done
after the series of $mount -f's that setup the now writeable /etc/mtab? 
Comment 6 Bill Nottingham 2004-11-24 15:42:43 EST
Fixed in 7.99-1.
Comment 7 Bill Nottingham 2004-11-24 15:42:48 EST
Fixed in 7.99-1.
Comment 8 Mickey Stein 2004-11-25 09:35:55 EST
In 7.99-1, the previous problems are gone and in their place, "/" (or
root) doesn't show up in output of 'mount' or "df -v". I'm off for
holiday in a few hours, but this bug isn't fixed, only changed. When
dismounting, umount/umount2 can't dismount / since they think its not

It still seems like a new variant on mtab being in an incorrect state.
That old patch ^^ up there where I moved the mount -a past the cleared
mtab in the prior version still works fine (the technique, not that
specific patch anymore). 
Comment 9 Joel Rittvo 2004-11-25 19:59:23 EST
And for me, 7.99-1 eliminates the message, but it doesn't mount the 3
ntfs/vfat partitions listed in my fstab anymore, which were the
subject of the messages.  Throwing out the baby with the bathwater?!?
 ;)  I went back to 7.98-1 for now. 
Comment 10 Michal Jaegermann 2004-11-27 18:22:59 EST
While previous variants of initscripts had annoying quirks
the 7.99-1 release is thoroughly broken to the point of making
machines unusuable and X instantly locking up (because it is
unable to find any fonts).  The problem is that _none_
of disk based file systems but / ends up mounted and what is
written to /etc/mtab has a very tenous relationship with
reality totally confusing programs like 'mount' or 'df'.

If you dumped everything in / then you may not notice the
problem; otherwise sizeable portions of a system will not work.

A way to recover on a machine stricken by initscripts-7.99-1
is to boot to level 1, remount / read-write, do something like
'umount -a -t ext3' (it will likely protest that most of what
you are trying to unmount is not mounted) followed by 'mount -a'
and check if the mess was more or less recovered.  If no then
you have to do further cleanup.  If yes then you can do
'telinit 5' and then it should boot.

It looks that what I described in comments to bug #139642
as a rough way to recover to some more-or-less usable state
is not good enough for 7.99-1.
Comment 11 Michal Jaegermann 2004-11-28 00:52:01 EST
Ok, here is the disaster area.  In /etc/rc.sysinit there are these

# Enter mounted filesystems into /etc/mtab
mount -a -f

Before these lines and before clearing it /etc/mtab actually looks
quite sane.  After these lines we get in /etc/mtab all kinds of file
systems which actually are not there.  In my case 'df' in that
moment shows:

 Filesystem            Size  Used Avail Use% Mounted on 
 /dev/sda10            966M  589M  329M  65% /boot 
 none                  249M  152K  249M   1% /dev/shm 
 /dev/sda14            966M  589M  329M  65% /home 
 /dev/sda13            966M  589M  329M  65% /opt 
 /dev/sda12            966M  589M  329M  65% /usr 
 /usr/tmp.real         966M  589M  329M  65% /var/tmp

which means that "all" file systems on disk are actually the same as
/ which, for a change, is missing.  From that moment on we are in
trouble because any executables from /usr/{bin,sbin} used in further
stages of startup are not available and 'mount -a' will not mount
anything.  OTOH if you will try 'umount /usr' then you will get
"umount: /dev/sda12: not mounted"

Addition of 'mount -a' before 'mount -a -f' solves an immediate
problem of making the system bootable and somewhat fit for use.
There is still missing / in /etc/mtab so it does not show up in 'df'
output.  I do not see an obvious way of adding that without parsing
/etc/fstab to construct proper arguments for 'mount -f ...'.  Other
ideas?  Another one which is missing is /dev but this does not seem
to be overly important if not exactly right.

OTOH, to make up for the ebove, in /proc/mounts we end with double
lines 'none /dev tmpfs rw 0 0' and '/proc /proc proc rw,nodiratime 0 0'
and there are some "already mounted" complaints in a startup; likely
from 'mount -a'.
Comment 12 Michal Jaegermann 2004-11-28 13:08:18 EST
When I wrote yesterday about parsing /etc/fstab I had in mind a code
in /etc/rc.d/rc.sysinit like that:
# Remove stale backups
rm -f /etc/mtab~ /etc/mtab~~

# enter / into mtab
add_to_mtab () {
    local opts
    case "$1" in
        '#'*) return 1 ;;
    # only / gets "special treatment"
    [ "$2" != '/' ] && return 1
    case "$opts" in
        LABEL*) opts="-L ${opts#*=}"
        UUID*)  opts="-U ${opts#*=}"
    mount -f -t $3 $opts $2

if [ -r /etc/fstab ] ; then
    while read line ; do
        add_to_mtab $line && break
    done < /etc/fstab

# mount what can mount 
mount -a >/dev/null 2>&1

# Enter mounted filesystems into /etc/mtab
mount -a -f

With those changes my system at least boots, starts X, and /etc/mtab
and an outptut of df look approximately sane.
Comment 13 Michal Jaegermann 2004-11-28 14:44:25 EST
Created attachment 107515 [details]
a patch to get correct mounts in startup

Looking closer at rc.sysinit I see that I should be somewhat more careful
what I am mounting and where.  My current change to rc.sysinit is attached.
With this I am booting correctly and without excessive wailing during
a startup and a shutdown.

I am not entering now /dev into /etc/mtab as this is causing "busy" complaints
on a shutdown.	Of course the other way around would be to delete '/dev' entry
from /etc/mtab in /etc/rc.d/init.d/halt before trying unmounts.
Comment 14 Bill Nottingham 2004-11-29 14:58:10 EST
Created attachment 107569 [details]
much simpler changes

OK, so, the change in 7.99-1 is just complete crack.

This should work much better.
Comment 15 Michal Jaegermann 2004-11-29 20:33:36 EST
Hm, I thought that I tried 'mount -f /'. Obviously not as it does
the right thing.  Maybe it was 'mount -f / /'?  Close but not quite.

In such case I have another propositon for changes which does not
require an explicit knowledge what was already mounted.  Directly
after 'mount -f /' do 

action $"Mounting local filesystems: " ....

but with "no list" expanded by 'sysfs,devpts'.  This followed by
'mount -a -f' like in a patch from comment #13.  AFAICS this works
as desired both when starting and shutting down.

I have, for example, a machine with USB so broken that either
it or X can be used; otherwise an instant lockup.  This means
that things like /proc/bus/usb are by no means guaranteed. :-)
Comment 16 Joel Rittvo 2004-11-29 20:52:28 EST
The patch in comment 14 applied to 7.99-1 works for me.
Comment 17 Michal Jaegermann 2004-12-01 01:42:08 EST
Created attachment 107692 [details]
changes simpler but not too simple

With initscripts-8.00-1 I immediately got on my test system (USB not active):

Remounting root filesystem in read-write mode:		   [  OK  ]
mount: can't find /proc/bus/usb in /etc/fstab or /etc/mtab
Mounting local filesystems:    

and three times "/usr: file system busy", or something to that effect, when
shutting down.	I am not sure why the later.

With an attached patch on the top of initscripts-8.00-1 everything
works correctly regardless if USB happens to be active or not.
Comment 18 Bill Nottingham 2004-12-01 11:24:57 EST
The mount -f calls should just be redirected (as they were before.)

The /usr thing is probably something different.
Comment 19 Bill Nottingham 2004-12-03 16:10:13 EST
*** Bug 141749 has been marked as a duplicate of this bug. ***
Comment 20 Michal Jaegermann 2004-12-05 17:13:27 EST
With the current test kernels ("rawhide" but somebody else wrote
that he is seeing the same for recent FC3 test kernels from Dave)
I am seeing 

mount: can't find /proc/bus/usb in /etc/fstab or /etc/mtab

does not matter if there is 'nousb' in boot parameters or not.

'mount -a -f' is not causing such messages but /proc/bus/usb
is not showing up in /etc/mtab either even if it is listed in
Comment 21 Bill Nottingham 2004-12-06 14:50:42 EST
The error message is from the mount -f call.
Comment 22 Bill Nottingham 2004-12-06 15:32:02 EST
/dev/null redirection added in 8.01-1.
Comment 23 Karel Zak 2005-03-22 04:42:05 EST
*** Bug 139642 has been marked as a duplicate of this bug. ***

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