First boot with 20040908 changes

David Zeuthen david at fubar.dk
Sat Sep 11 07:33:58 UTC 2004


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 at buildhost root]# ls /media/
> idedisk  idedisk1  scsidisk  scsidisk1
> 
> [root at buildhost root]# service haldaemon stop
> Stopping HAL daemon:                                       [FAILED]
> [root at buildhost root]# udevstart
> [root at 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





More information about the fedora-devel-list mailing list