Bug 129886 - Readonly-root needs to work with HAL
Readonly-root needs to work with HAL
Product: Fedora
Classification: Fedora
Component: distribution (Show other bugs)
All Linux
medium Severity medium
: ---
: ---
Assigned To: Bill Nottingham
Bill Nottingham
Depends On:
Blocks: ReadOnlyFS
  Show dependency treegraph
Reported: 2004-08-13 15:31 EDT by Dave Malcolm
Modified: 2014-03-16 22:47 EDT (History)
6 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2007-09-18 15:17:10 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 Dave Malcolm 2004-08-13 15:31:10 EDT
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

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 15:48:22 EDT
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 16:05:43 EDT
John and David, please can you comment on this?
Comment 3 David Zeuthen 2004-08-20 16:33:21 EDT
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

I think that's pretty much it?
Comment 4 Mark McLoughlin 2004-08-24 08:36:07 EDT
I thought symlinking /etc/mtab to /proc/mounts was the accepted
solution to this?

Alex ?
Comment 5 David Zeuthen 2004-08-24 08:51:15 EDT
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 11:31:07 EDT
I'd love to have it specifically tested and quantified with what
breaks, though. :)
Comment 7 John Thacker 2006-10-29 17:00:28 EST
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 05:53:00 EST
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 ?

Comment 9 Matthew Miller 2007-04-06 11:22:12 EDT
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 15:17:10 EDT
This isn't really relevant any more.

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