Bug 137072 - diskdruid needs "nomanage" option by default for /etc/fstab
diskdruid needs "nomanage" option by default for /etc/fstab
Product: Fedora
Classification: Fedora
Component: hal (Show other bugs)
i386 Linux
medium Severity high
: ---
: ---
Assigned To: David Zeuthen
Mike McLean
Depends On:
  Show dependency treegraph
Reported: 2004-10-25 13:43 EDT by John Reiser
Modified: 2013-03-05 22:41 EST (History)
4 users (show)

See Also:
Fixed In Version: 0.4.0-8
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2004-10-26 16:09:26 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 John Reiser 2004-10-25 13:43:01 EDT
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.3)
Gecko/20041012 Epiphany/1.4.4

Description of problem:
Now that hald and fstab-sync are automatically finding and mounting
all disk partitions at every multiuser boot, then DiskDruid must adapt
in order to prevent partitions that are not selected during install
from being mounted at boot.  Among other things, this is necessary to
prevent data corruption, because being mounted by a new system can
destroy operability by an old system (bug 137068, where ext_attr gets
added by surprise to ext3).  This matters to ISVs (independent
software vendors) who support their customers by multi-booting various
old systems on one box.

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:
1. Chooose manual partitioning by DiskDruid during install.

Actual Results:  All un-selected partitions (at install) get mounted
anyway (at boot) by hald and fstab-sync.

Expected Results:  Un-selected partitions at install should not be
mounted at boot; or there should be an explicit "do not mount/manage"
option, and that should be the default if manual partitioning does not
select a mount point for a partition.

Additional info:

I suppose a workaround would be to hand-edit /etc/fstab when install
finishes, but before firstboot.  This requires remembering to do it,
and can be tedious if there are many partitions involved.

Entering as high severity because not-mounted ext3 partitions (at
install) become "corrupted" when discovered and mounted [they cannot
be used by multibooted RH9 or earlier].
Comment 1 Jeremy Katz 2004-10-25 13:58:36 EDT
This is a hal bug.

anaconda has *NEVER* written anything about every partition on the
system.  We list what you say to mount and not the others.  I haven't
even been doing removable devices as that had moved to kudzu (which is
a far more sensible place to do it).  Then, it moved to hal and it's
started doing ... more.

If a change is done other than in hal then there are still the same
opportunities for problems on an upgrade, piecemeal updating of
packages and in other circumstances as well.
Comment 2 John Reiser 2004-10-25 15:59:44 EDT
The operational end of this issue is bug 137068 -- ext3 filesystem
gets ext_attr by surprise, and it kills multi-booting
inter-operability on Redhat 9 and below.

The software environment is FC3test3 with

After multiuser boot, then I see all existing filesystems in
/etc/fstab, even ones that I did not select to be mounted at install.
 The added lines look like
   /dev/hda13  /media/idedisk2  ext3  pamconsole,exec,noauto,managed 0 0
and those filesystems _do_ get mounted read-write; they are
accessible, and show up in the output from 'df'.  [What does 'noauto'
mean here?]
Comment 3 David Zeuthen 2004-10-26 10:40:05 EDT
Comment 1:
> This is a hal bug.

No, sorry, this is a bug with ext3 and older kernels.

Comment 2:
> ... and those filesystems _do_ get mounted read-write;

Only when you log into GNOME, g-v-m will mount them - you can disable
this from Preferences->Removable Storage (disable automounting).

> What does 'noauto' mean here?

noauto only means that they shouldn't get mounted on bootup.

I agree this is a severe bug, I'm not sure what to do with it as it
will apply to any ext3 filesystem from a disk being attached to a
system, be it IDE, Firewire, USB etc. Actually, just a few weeks ago I
took the disk from my old FC1 server and put it in a USB enclosure so
I could copy my mailfolders - I'm sure it also got ext_xattr too. My
point is that we only see the bug much faster now that hal/fstab-sync
adds entries for existing disks. Which is good so we can fix it.

As already reported the operational details are tracked in bug 137068.
One stop-gap option at this point would be to change the default
storage policy to add mount option 'ro' for entries with ext3
filesystems in the /etc/fstab? I can make this change very quickly.

Comment 4 John Reiser 2004-10-26 12:19:41 EDT
I am in favor of the stopgap mentioned in Comment 3: add mount option
'ro' [read-only] by default for storage policy on
automatically-discovered ext3 filesystems.  I'm assuming that this
actually will prevent ext_attr from being added to a filesystem that
doesn't have it already, and that the 'ro' will persist (from install
through firstboot, GNOME login, shutdown, reboot, GNOME re-login,
etc.) regardless of subsequent hal/fstab-sync/GNOME actions, until
explicitly changed by the system administrator.  I recognize that the
stopgap may be removed or changed if/when the underlying issue gets
Comment 5 David Zeuthen 2004-10-26 16:09:26 EDT
Right. However.

So, I've actually built a new hal package, version 0.4.0-8, that
refuses to add entries for non-hotpluggable fixed drives; such as IDE
disks. The reason for this policy change is not entirely this bug (it
also has to do with incomplete support for ataraid controllers; e.g.
raid members could be added to the fstab). 

Notwithstanding it has the effect, though, of not affecting users,
like you, with a multiboot system on non-hotpluggable drives. 

That package is here


and it will hopefully make FC3.

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