[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: remount removeable drive in Lenny - how?



On 2009-07-20_17:13:36, Tiago Saboga wrote:
> 
> Paul E Condon:
> > > But, for hal-mounted devices, the umount also deletes the
> > > mount-point.
> Andrei Popescu:
> > The problem seems to be with the volume manager as this does not
> > happen under Xfce. Maybe the volume manager of your DE also triggers
> > an "eject" (or something similar)?
> 
> Probably. I think KDE even says, for usb sticks, that it "could not
> eject the device". But  would this make udev/hal remove the device file
> along with the mount-point?
> 

I think that the device file is NOT removed. This is what I
observe. When I umount /dev/sdxn, the mount-point /media/MMMPPP is
removed, and the device file is remains. This is GOOD because the
reason for umount is so that I can run e2fsck. So, from observation, a
supposition held by some is false.

Having run e2fsck, I now want to mount the filesystem again. But at
this time, I have no mount point available, and making one manually
screws up subsequent hot-plugging.

I now have three suggestions for programs that are claimed to re-do
the hot-plug activity without actually unplugging and re-plugging the
physical connector.  In my testing 'blockdev --rereadpt <device>' and
'partprobe' both work.  'partprobe' is ever-so-slightly more
convenient because it does not require that the <device> be
given. (and wide cards don't work in blockdev because it barfs on a
device that that is already mounted).

In my testing 'udevadm trigger && udevadm settle' seems to be
equivalent to 'sleep 2'. The man page seems to indicate that it should
do something useful, but, for me, its a YMMV-type situation.

I am using Gnome. The fact that behavior is noticably different in
Xfce is interesting and, to me, indicates that the behavior is not
determined by fixed nature of a single module. I think I should look
into switching from Gnome.

This has been interesting and educational. 

Thanks for all the input.

-- 
Paul E Condon           
pecondon@mesanetworks.net


Reply to: