Red Hat Bugzilla – Bug 137072
diskdruid needs "nomanage" option by default for /etc/fstab
Last modified: 2013-03-05 22:41:50 EST
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): anaconda-10.0.3.15-1 How reproducible: Always Steps to Reproduce: 1. Chooose manual partitioning by DiskDruid during install. 2. 3. 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].
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.
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 kernel-2.6.9-1.640 hal-0.4.0-5 initscripts-7.93-1 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 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. David
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 resolved.
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 http://people.redhat.com/davidz/dist/ and it will hopefully make FC3.