Bug 512796

Summary: mounting /dev/pts and /proc fail annoyance
Product: [Fedora] Fedora Reporter: Warren Togami <wtogami>
Component: initscriptsAssignee: Bill Nottingham <notting>
Status: CLOSED WONTFIX QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: medium Docs Contact:
Priority: low    
Version: 12CC: amcnabb, harald, iarlyy, kzak, notting, rvokal
Target Milestone: ---Keywords: Triaged
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2010-12-05 06:42:04 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On:    
Bug Blocks: 512800, 516998    

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.