Bug 487604 - readonlyroot and updating /etc/mtab
readonlyroot and updating /etc/mtab
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: util-linux-ng (Show other bugs)
All Linux
low Severity medium
: rc
: ---
Assigned To: Karel Zak
Ben Levenson
: Reopened
Depends On: 214891
Blocks: 513462
  Show dependency treegraph
Reported: 2009-02-26 17:24 EST by Brian J. Murrell
Modified: 2010-06-09 07:50 EDT (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2010-06-09 07:50:16 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Brian J. Murrell 2009-02-26 17:24:38 EST
When one configure's one system(s) to use the readonlyroot facility, /etc/mtab updates fail because a lock file is attempted which is on the readonly root, while of course /etc/mtab is still writable as it's bind mounted from the writable space.  Here's the symptoms:

can't create lock file /etc/mtab~692: Read-only file system (use -n flag to override)

Which results from the various mounts done in rc.sysinit such as:

+ mount -f /
+ mount -a -t nonfs,nfs4,smbfs,ncpfs,cifs,gfs -O no_netdev
Mounting other filesystems:  can't create lock file /etc/mtab~977: Read-only file system (use -n flag to override)

These all probably need to take the advise to use "-n" when readonlyroot is set.
Comment 1 Brian J. Murrell 2009-02-27 09:37:35 EST
Hrm.  I tried to close this as a duplicate of 214819 but it seems, even though I opened the bug, I cannot close it.

Somebody please close this as a dup of 214819.

Comment 2 Bill Nottingham 2009-02-27 11:23:15 EST

*** This bug has been marked as a duplicate of bug 214819 ***
Comment 3 Brian J. Murrell 2009-02-27 12:19:28 EST
(In reply to comment #1)
> Somebody please close this as a dup of 214819.

Oops.  A little lysdexic this morning.  That should be 214891, not ...19.

My apologies.
Comment 4 Bill Nottingham 2009-02-27 16:12:54 EST

*** This bug has been marked as a duplicate of bug 214891 ***
Comment 5 Alexander Todorov 2009-08-24 06:31:53 EDT
This is incorrectly closed as duplicate. 214891 is against rawhide not RHEL.

Moving to RHEL6 for tracking purposes as per:
Comment 6 RHEL Product and Program Management 2009-08-24 06:35:51 EDT
This request was evaluated by Red Hat Product Management for inclusion in a Red
Hat Enterprise Linux major release.  Product Management has requested further
review of this request by Red Hat Engineering, for potential inclusion in a Red
Hat Enterprise Linux Major release.  This request is not yet committed for
Comment 7 Steve Rotolo 2009-12-16 17:52:04 EST
Perhaps a good solution is to have mount write mtab locks under /var/lock instead  of in /etc.  /var/lock is already in /etc/rwtab.  Then one would not have to use mount -n, and actually get a usable /etc/mtab file.
Comment 8 Steve Rotolo 2009-12-16 17:54:17 EST
I forgot to mention that I am having this problem on RHEL 5.4.  And there seems to be a fair number of init.d scripts that have this problem.
Comment 9 Bill Nottingham 2009-12-16 20:07:36 EST
/var/lock isn't necessarily there during rc.sysinit.
Comment 10 Steve Rotolo 2009-12-17 08:59:58 EST
When READONLY root is used with the default /etc/rwtab, rc.sysinit creates /var/lock as a bind-mount into /var/lib/stateless/writable.  I believe all mounts in rc.sysinit prior to that are done with mount -n anyway.

I guess the problem is when READONLY is not set, huh?  Then something may get mounted on /var later...
Comment 11 Bill Nottingham 2009-12-17 12:28:24 EST
Comment 12 Karel Zak 2010-01-29 09:50:29 EST
Well, if init scripts use "mount -n" then we can close this bug, right? I'm not sure what change is expected in mount(8).

For more details why we cannot move the mtab lock file see #214891.
Comment 13 Bill Nottingham 2010-01-29 12:36:19 EST
Oof, it seems weird to have to every time we call mount to try and decide whether or not we should pass -n, depending on the state of /etc.

Honestly... union mounts are the way to go.

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