Bug 129886

Summary:	Readonly-root needs to work with HAL
Product:	[Fedora] Fedora	Reporter:	Dave Malcolm <dmalcolm>
Component:	distribution	Assignee:	Bill Nottingham <notting>
Status:	CLOSED RAWHIDE	QA Contact:	Bill Nottingham <notting>
Severity:	medium	Docs Contact:
Priority:	medium
Version:	3	CC:	alexl, davidz, johnp, markmc, mattdm, rvokal
Target Milestone:	---
Target Release:	---
Hardware:	All
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2007-09-18 19:17:10 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:	124120

Description Dave Malcolm 2004-08-13 19:31:10 UTC

Description of problem:

Testing of the readonly-root package has so far been done before the
addtion of the Hardware Abstraction Layer.  There will probably be
problems that arise when we try to run both.  

For example, the readonly-root script current set up /etc/fstab to be
writable, but /etc/mtab is readonly (due to locking problems with a
readonly /etc); however, I believe HAL relies on having a writable
/etc/mtab

This bug is here as a reminder that we need to check that the two
packages work together, and fix the problems that arise.

Comment 1 Bill Nottingham 2004-08-13 19:48:22 UTC

Surely hal wants to write to fstab. Or is it running
mount() at the system call level and editing mtab itself?

Comment 2 Dave Malcolm 2004-08-20 20:05:43 UTC

John and David, please can you comment on this?

Comment 3 David Zeuthen 2004-08-20 20:33:21 UTC

Hi, hal itself isn't concerned with either mount(1) or mount(2),
because hal stays out of policy. gnome-volume-manager OTOH invokes
mount(1) that modifies /etc/mtab and hal does poll on /etc/mtab (using
dnotify) in order to update the properties on the hal device object.
So you want to make sure that /etc/mtab is on a tmpfs of some sort.

Btw, there is an issue in fstab-sync (which hal invokes), insofar that
the temporary file used to implement the atomic update is in /etc
itself. That should be in /tmp instead. I'll make sure to change this
for the next release. fstab-sync also relies on flock(2) to work on
/etc/fstab.

I think that's pretty much it?

Comment 4 Mark McLoughlin 2004-08-24 12:36:07 UTC

I thought symlinking /etc/mtab to /proc/mounts was the accepted
solution to this?

Alex ?

Comment 5 David Zeuthen 2004-08-24 12:51:15 UTC

These files are different; may break userspace apps - IIRC mount(1)
expects to be able to write to /etc/mtab. Also /proc/mounts is
per-process while /etc/mtab is system-wide.

Comment 6 Bill Nottingham 2004-08-24 15:31:07 UTC

I'd love to have it specifically tested and quantified with what
breaks, though. :)

Comment 7 John Thacker 2006-10-29 22:00:28 UTC

Changing version to correct one.  (test1 -> fc3test1, and some were filed as
test3 accidentally instead; but clearly must be fc3test1 given the date of filing.)

Comment 8 Christian Iseli 2007-01-22 10:53:00 UTC

This report targets the FC3 or FC4 products, which have now been EOL'd.

Could you please check that it still applies to a current Fedora release, and
either update the target product or close it ?

Thanks.

Comment 9 Matthew Miller 2007-04-06 15:22:12 UTC

Fedora Core 3 and Fedora Core 4 are no longer supported. If you could retest
this issue on a current release or on the latest development / test version, we
would appreciate that. Otherwise, this bug will be marked as CANTFIX one month
from now. Thanks for your help and for your patience.

Comment 10 Bill Nottingham 2007-09-18 19:17:10 UTC

This isn't really relevant any more.