Re: volume mgmt w/o gnome

On Sat, Dec 01, 2007 at 06:42:09PM -0500, Mark Grieveson wrote:
Hello. I use fluxbox most of the time. But, when I plug in my hp315
photosmart camera, I rely upon gnome to find it, and automagically
mount it for me. Is it possible to completely remove gnome, and just
mount this camera (or other USB storage devices) myself? Or, and even
better, find a utility that, sans gnome, can automagically mount the
camera itself?

Funny you should mention this, I've been working on this problem
myself lately. As a fluxboxer, I have been somewhat envious with the
ease with which the gnome/kde folk are able to use USB MSDs.

For some time my approach was to write a udev rule for each new device
to give it a consistant name, write an autofs map for that device, and
set up a link in /media to the autofs mount. That way I could just plug
in my drive, cd to /media/whatever, do my thing, cd out of
/media/whatever, wait a few seconds for the automount to time out, and
unplug the drive. This is really convenient to use, but a PITA to set
up each time I got a new USB toy. Plus, my /media was filling up with
rarely used symlinks.

I finally got fed up with this and came up with the following
solution. When I plug in a USB device, udev calls a script which
writes an autofs map for that device and then reloads autofs. While
writing this I found the --ghost option which makes the symlink
creation unneeded. The mountpoints are created in /media/auto and are
named after the devices volume label, or failing this the device's
model name, falling back on /media/auto/removble_drive. Subsequent
devices with the same name are named /media/auto/somename.1, and so on.

Anyway, with autofs installed I added this to /etc/auto.master:

---CUT HERE---
/media/auto /etc/auto.removable --timeout=2 --ghost
---CUT HERE---

I have these udev rules in /etc/udev/rules.d/002_local_automount.rules
[beware of word-wrap]

---CUT HERE---
# use -*- SH -*- mode to turn off wordwrap in jed
#Specifying ENV{ID_FS_USAGE}=="filesystem" doesn't work on add, test inside run cmd
BUS=="usb|ieee1394",SUBSYSTEM=="block",ACTION=="add", run+="/usr/local/bin/removable_drive_handler"

#Specifying BUS doesn't work on remove, but you're unlikely to remove anything besides usb or fW
SUBSYSTEM=="block",ACTION=="remove",ENV{ID_FS_USAGE}=="filesystem", run+="/usr/local/bin/removable_drive_handler"
---CUT HERE---

Finally, /usr/local/bin/removable_drive_handler :

---CUT HERE---
#! /bin/bash


#Clean out dead automounts, go through map file and remove any maps
#which refer to non-existant nodes in /dev
test "$ID_FS_USAGE" = "filesystem" || exit 0

case "$ACTION" in

"remove" )
# clean out stale maps and remove specified map
echo \#Editing is futile, automatically generated at $(date) > $
while read key options location
if [ "$location" != ":$DEVNAME" -a -e "${location##:}" ] #Remove colon to look for node
echo $key $options $location >> $
done < $map_file

mv $ $map_file

"add" )
# Figure out name for mountpoint
if [ -n "ID_FS_LABEL_SAFE" ] #Prefer volume label as it's user controlled
elif [ -n "$ID_MODEL" ] #Next try device model name
else #Finally, use a default

# If there's already a mountpoint with this name, try name.1, name.2 ...
if [ -e "$autofs_mount_dir/$mountpoint" ]
while [ -e "$autofs_mount_dir/$mountpoint.$n" ]
let "n += 1"

# Add map for device using FS appropriate options
if [ "$ID_FS_TYPE" = "vfat" ]
echo "$mountpoint" $vfat_mount_options :$DEVNAME >> $map_file
echo "$mountpoint" $unix_mount_options :$DEVNAME >> $map_file

# If kill doesn't work, use initscript
kill -HUP $(cat $autofs_pid_file) || /etc/init.d/autofs reload

---CUT HERE---

This is still very much a work in progress, so anybody with comments
or suggestions (keep it clean!) please feel free to chime in.



Dave Thayer | Whenever you read a good book, it's like the
Denver, Colorado USA | author is right there, in the room talking to
dave@xxxxxxxxxxxxxxxx | you, which is why I don't like to read
| good books. - Jack Handey "Deep Thoughts"

To UNSUBSCRIBE, email to debian-user-REQUEST@xxxxxxxxxxxxxxxx
with a subject of "unsubscribe". Trouble? Contact listmaster@xxxxxxxxxxxxxxxx

Relevant Pages

  • Re: [autofs] [RFC] Towards a Modern Autofs
    ... >entangling autofs with that work. ... >filesystem it's willing to export. ... >>map is mounted. ... The result is that some users will see mount points ...
  • Re: [autofs] [RFC] Towards a Modern Autofs
    ... entangling autofs with that work. ... > map is mounted. ... I don't quite see the need for the mapkey mount option. ... But in sec. 5.3.2 I see you making filesystem dirs in /tmp which seem to ...
  • Re: [autofs] [RFC] Towards a Modern Autofs
    ... not visibility in the automount map. ... > to mount it and no longer finds it in the map, ... if /usr/src/linux is an autofs direct ... Whereas if the subdir and containing dir are unmounted ...
  • Re: [autofs] [RFC] Towards a Modern Autofs
    ... >> If wildcard map entries are not in autofs v3 then Jeremy implemented this ... >> of stress for mount and umount. ...
  • Re: question concerning autofs, usbfs and vfat
    ... I think there is some confusion as to the meaning of some of the fields in the mount command output, ... The type 'vfat' is a real file system type, ... The "autofs" type is printed when the automount daemon is running, "usbfs" refers to the USB subsystem software. ...