On Fri, 2004-09-10 at 10:27 -0700, Steve G wrote:
The damage comes from xattr. Suppose I have a machine that boots
Mandrake,
debian, and FC3. I use the /opt as a pass between the the various OS's. It is on
its own partition. One of these days, the mount count triggers a fsck. I don't
want it to write anything to the drive if it can mess it up. Again, the problem
is xattrs and the older OS's not handling them.
<rant> Its too late now, but I think allowing xattrs into ext3 was a big mistake
from a backwards compatibility stance. It should have been ext4. Sure, the bugs
in ext3 would still be there waiting to bite you, but you won't face them every
single day.</rant>
Can you detect a ext3 drive that doesn't have xattrs applied? If so, the work
around is not to write anything related to xattrs to that drive.
It sounds to me like this should be fixed in the kernel.
>I'm not sure how well turning off media detection works
presently
Something changed after yesterday's updates. I set everything to false yesterday
and there were no entries in /media and fstab. Today they are there.
>(I test it once in a while though) and I think g-v-m
>ignores the automount hint. When Nautilus and GNOME VFS is ready, this
>will be supported as well [1].
Then the answer is not to make the drive available. There should probably be a
configuration option that says do not update fstab with detected media and
another for do not create mount points for detected media.
Maintaining mountpoints == maintaining /etc/fstab. There will be a
configuration for fstab-sync to specify whether a drive or media should
be ignored. So you'll be able to say something like
block.device="/dev/hda7", ignore
storage.serial="CLP225F2G3UR4A", ignore
block.device="/dev/hda2", mount_point="/mnt/my_own_mount_point"
volume.label="CANON_DC", mount_point="/mnt/my_camera",
options="noauto,user,exec,noatime,sync"
or something - need to work out the exact format but it will be simple
and probably like the udev rules.
This way, people that
cannot afford to get a corrupted partition from xattrs being written to a
partition that a NON-SE Linux OS must access can avoid damage.
I'm not sure how to best work around the xattr issue and I'm wary at
adding special casing code at the hal level for this - I'm more of the
opinion that this should be solved at the kernel level and I'm curious
at what other people think.
>There is supposed to be a /media/cdrom mount point if you got a
CD-ROM drive;
OK, I don't see one. The following is from an earlier e-mail to the list that I
didn't get a chance to answer:
Right.
>This should work. What does 'udevinfo -r -q name -p
/block/hdc' say?
/dev/hdc
Looks good.
>Does running 'service haldaemon stop; udevstart; service
>haldaemon start' solve your problem?
No.
[root@buildhost root]# ls /media/
idedisk idedisk1 scsidisk scsidisk1
[root@buildhost root]# service haldaemon stop
Stopping HAL daemon: [FAILED]
[root@buildhost root]# udevstart
[root@buildhost root]# service haldaemon start
Starting HAL daemon: [ OK ]
/etc/init.d/haldaemon: line 31: /var/run/hald/pid: No such file or directory
>Otherwise you need to file a bug against hal to we can fix it
Does the above look like a bug? If so I will file one.
It indeed looks like hald crashed - haven't seen that in some time
though :-). Yes, please submit a bug report; I wrote down some
information about what to capture here
http://freedesktop.org/Software/HalTraces
Many thanks,
David