Bug 487604

Summary:	readonlyroot and updating /etc/mtab
Product:	Red Hat Enterprise Linux 6	Reporter:	Brian J. Murrell <brian>
Component:	util-linux-ng	Assignee:	Karel Zak <kzak>
Status:	CLOSED WONTFIX	QA Contact:	Ben Levenson <benl>
Severity:	medium	Docs Contact:
Priority:	low
Version:	6.0	CC:	atodorov, notting, steve.rotolo
Target Milestone:	rc	Keywords:	Reopened
Target Release:	---
Hardware:	All
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2010-06-09 11:50:16 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:	214891
Bug Blocks:	513462

Description Brian J. Murrell 2009-02-26 22:24:38 UTC

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 14:37:35 UTC

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.

Thanx.

Comment 2 Bill Nottingham 2009-02-27 16:23:15 UTC


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

Comment 3 Brian J. Murrell 2009-02-27 17:19:28 UTC

(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 21:12:54 UTC


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

Comment 5 Alexander Todorov 2009-08-24 10:31:53 UTC

This is incorrectly closed as duplicate. 214891 is against rawhide not RHEL.

Moving to RHEL6 for tracking purposes as per:
https://bugzilla.redhat.com/show_bug.cgi?id=214891#c26

Comment 6 RHEL Program Management 2009-08-24 10:35:51 UTC

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
inclusion.

Comment 7 Steve Rotolo 2009-12-16 22:52:04 UTC

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 22:54:17 UTC

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-17 01:07:36 UTC

/var/lock isn't necessarily there during rc.sysinit.

Comment 10 Steve Rotolo 2009-12-17 13:59:58 UTC

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 17:28:24 UTC

Correct.

Comment 12 Karel Zak 2010-01-29 14:50:29 UTC

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 17:36:19 UTC

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.