Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.
Bug 512796 - mounting /dev/pts and /proc fail annoyance
Summary: mounting /dev/pts and /proc fail annoyance
Keywords:
Status: CLOSED WONTFIX
Alias: None
Product: Fedora
Classification: Fedora
Component: initscripts
Version: 12
Hardware: All
OS: Linux
low
medium
Target Milestone: ---
Assignee: Bill Nottingham
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks: THINCLIENT
TreeView+ depends on / blocked
 
Reported: 2009-07-20 19:30 UTC by Warren Togami
Modified: 2014-03-17 03:19 UTC (History)
6 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2010-12-05 06:42:04 UTC


Attachments (Terms of Use)

Description Warren Togami 2009-07-20 19:30:58 UTC
initscripts-8.95-1.i586

Netboot via dracut...

# Mount all other filesystems (except for NFS and /proc, which is already
# mounted). Contrary to standard usage,
# filesystems are NOT unmounted in single user mode.
if [ "$READONLY" != "yes" ] ; then
        action $"Mounting local filesystems: " mount -a -t nonfs,nfs4,smbfs,ncpfs,cifs,gfs,gfs2 -O no_netdev
else
        action $"Mounting local filesystems: " mount -a -n -t nonfs,nfs4,smbfs,ncpfs,cifs,gfs,gfs2 -O no_netdev
fi

Mounting local filesystems:  mount: devpts already mounted or /dev/pts busy
mount: according ot mtab, /dev/pts is already mounted on /dev/pts
                                                           [ FAILED ]

Not fatal, but ugly upon every boot.

Comment 1 Bill Nottingham 2009-07-20 19:38:47 UTC
How does dracut mount /dev/pts, vs. mkinitrd?

Comment 2 Warren Togami 2009-07-20 20:23:46 UTC
Investigating the difference between mkinitrd and dracut.

Comment 3 Warren Togami 2009-07-20 20:44:57 UTC
Both mkinitrd and dracut mount /dev/pts with:
mount -t devpts -o gid=5,mode=620 /dev/pts /dev/pts

initscripts uses:
mount -a -n -t nonfs,nfs4,smbfs,ncpfs,cifs,gfs,gfs2 -O no_netdev

/etc/fstab contains:
/dev/root  /         auto    defaults,noatime 0 0
devpts     /dev/pts  devpts  gid=5,mode=620   0 0
tmpfs      /dev/shm  tmpfs   defaults         0 0
proc       /proc     proc    defaults         0 0

dracut:
If I comment out the devpts line, booting the initrd still has [FAILED] on this step, but mount doesn't print an error message.  Commenting out both devpts and proc lines causes it to boot [OK].

mkinitrd:
It boots with [FAILED] without mount complaints.  Commenting out the proc line alone allows it to boot [OK].

Comment 4 Bill Nottingham 2009-07-20 20:50:59 UTC
So, the difference is actually in how they mount /proc?

Comment 5 Warren Togami 2009-07-20 21:00:48 UTC
No, /proc failing is a separate problem that happens simultaneously with initscript's mount command.

Comment 6 Warren Togami 2009-07-20 21:04:45 UTC
if [ ! -e /proc/mounts ]; then
        mount -n -t proc /proc /proc
        mount -n -t sysfs /sys /sys >/dev/null 2>&1
fi

Earlier in rc.sysinit it already mounted /proc, the subsequent mount during "Mounting local filesystems" fails due to this /proc.

No clue why dracut but not mkinitrd causes an error for /dev/pts/.

Comment 7 Bill Nottingham 2009-07-20 21:09:45 UTC
So, dracut mounts no filesystems for the resulting root filesystem?

Comment 8 Warren Togami 2009-07-20 21:32:39 UTC
Found a difference between mkinitrd and dracut:

nash.c switchrootCommand() unmounts /dev /proc and /sys.

switch_root in dracut mount moves /dev, /proc and /sys into $NEWROOT before switching.

Comment 9 Warren Togami 2009-07-20 21:36:38 UTC
It would be undesirable to delete those lines from /etc/fstab to workaround bugs in initscripts.  For the READONLY case, perhaps we want it to skip remounting /proc, /sys and /dev/pts.  But we do not want it to skip mounting arbitrary other things that might be defined in /etc/fstab.

Any suggestions?

Comment 10 Bill Nottingham 2009-07-20 21:39:21 UTC
Is it only failing in the readonly case?

Comment 11 Warren Togami 2009-07-20 21:53:49 UTC
It seems so.

Comment 12 Karel Zak 2009-07-30 21:28:20 UTC
(In reply to comment #6)
> Earlier in rc.sysinit it already mounted /proc, the subsequent mount during
> "Mounting local filesystems" fails due to this /proc.

The mount(8) uses /etc/mtab to check for already mounted filesystems. It's necessary to create a proper mtab before you call "mount -a".

For example by -f (fake) mount:

if [ -e /proc/mounts ]; then
   mount -f proc /proc /proc
   ...
fi

or create the initial mtab as copy of /proc/mounts.

Comment 13 Bill Nottingham 2009-07-31 00:53:05 UTC
If this is only in the readonly case... any reason the system mtab can't already have these?

Comment 14 Warren Togami 2009-07-31 04:45:56 UTC
The /etc/mtab mounted read-write by rwtab is a blank file.

It seems the mount -f solution during rc.sysinit prior to mount -a is good?

Comment 15 Bill Nottingham 2009-07-31 13:37:33 UTC
See bug 433702; this was explicitly disabled for read-only root, due to locking errors. What I'm saying about the pre-existing mtab is that if you're prepping an image, it doesn't *need* to be blank.

Comment 16 Warren Togami 2009-07-31 13:56:08 UTC
Hmm, in my case I had already symlinked /etc/mtab to ../proc/mounts.

That RHEL advisory says:
* having a read-only NFS-mounted root file system caused several scripts to
fail, and unnecessary time outs. This update resolves these issues, and
prevents "/etc/mtab" being written to.

Should I be using /etc/mtab as a symlink or pre-populated?

Is the Fedora initscript differing from this RHEL fix?

Comment 17 Warren Togami 2009-07-31 14:23:58 UTC
Bill,

If the pre-existing /etc/mtab is non-blank, then I can't make it read-write either using rwtab, since doing so makes it blank again.

Comment 18 Bill Nottingham 2009-07-31 15:55:15 UTC
(In reply to comment #16)
> Hmm, in my case I had already symlinked /etc/mtab to ../proc/mounts.
> 
> That RHEL advisory says:
> * having a read-only NFS-mounted root file system caused several scripts to
> fail, and unnecessary time outs. This update resolves these issues, and
> prevents "/etc/mtab" being written to.
> 
> Should I be using /etc/mtab as a symlink or pre-populated?

Either would work.

> Is the Fedora initscript differing from this RHEL fix?  

No.

Making it read/write with rwtab should not blank it, as long as you use 'files' and not 'empty'.

Comment 19 Warren Togami 2009-07-31 17:01:25 UTC
>> Should I be using /etc/mtab as a symlink or pre-populated?
> Either would work.

I have been using /etc/mtab as a symlink to ../proc/mounts.  mount -a is failing as noted in comment #0.

Comment 20 Bug Zapper 2009-11-16 11:02:18 UTC
This bug appears to have been reported against 'rawhide' during the Fedora 12 development cycle.
Changing version to '12'.

More information and reason for this action is here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping

Comment 23 Bill Nottingham 2010-01-19 17:53:56 UTC
Does this still happen with F12 final?

Comment 24 Bug Zapper 2010-11-04 10:44:12 UTC
This message is a reminder that Fedora 12 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 12.  It is Fedora's policy to close all
bug reports from releases that are no longer maintained.  At that time
this bug will be closed as WONTFIX if it remains open with a Fedora 
'version' of '12'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version prior to Fedora 12's end of life.

Bug Reporter: Thank you for reporting this issue and we are sorry that 
we may not be able to fix it before Fedora 12 is end of life.  If you 
would still like to see this bug fixed and are able to reproduce it 
against a later version of Fedora please change the 'version' of this 
bug to the applicable version.  If you are unable to change the version, 
please add a comment here and someone will do it for you.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events.  Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

The process we are following is described here: 
http://fedoraproject.org/wiki/BugZappers/HouseKeeping

Comment 25 Bug Zapper 2010-12-05 06:42:04 UTC
Fedora 12 changed to end-of-life (EOL) status on 2010-12-02. Fedora 12 is 
no longer maintained, which means that it will not receive any further 
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of 
Fedora please feel free to reopen this bug against that version.

Thank you for reporting this bug and we are sorry it could not be fixed.


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