Re: Trouble auto-mounting with a PCMCIA flash reader...
Joe Emenaker <joe@emenaker.com>:
> Still doesn't unmount automatically, though.
(Do you mean after removing the card, or whenever the last
filesystem access did end ?) In the past the MS 'fat' filesystem wasn't
able to 'sync' always correctly, so that was the reason why you should
'safely remove' (umount) a memory stick before plug-out.
However, i don't know if this is still the case.
> I'd like to avoid *needing* KDE for any of this, since I sometime run on
> console-only. I'd like the mounting/unmounting to be done all by daemons
usbmount works independent from any X session, but it's rules
use to match only USB bus storage devices. But rather than hacking
these, i'd recommend to write your own udev hook.
> yet *also* have KDE recognize the insertion and update it's "media:"
KDE will recognize if an mtab-mounted device gets umounted anyway.
Try it, umount a device manually and the icon will disappear.
Any 'external' daemon writing to mtab will just be recognized too.
> I thought the udev rules were only to customize the *naming* (and
> symlinking) of the device files (as I'm already doing with my USB
> dongle drives.
That was the case, in the beginning of uev. Then someone found out
that udev can do the whole hotplug stuff, too, easily. This is why you
don't need any hotplug package anymore if you got udev. However,
there are some default files and folders called 'hotplug' which are
part of the udev package now.
> Do you have to do that in fstab by setting the "auto" option?
'auto' only means an init script will mount at boottime.
If you make it 'noautro' and 'users' instead, any user can
mount and umount it, anytime, that is, either a user session (KDE)
daemon, or usbmount running as root, in which case a user still can
umount (which is different from the 'user' option behaviour)
Always use the 'sync' option for removables. (->man fstab).
KDE uses an independent session (virtual) filesystem (like gnome-vfs)
so KDE mounted devices doesn't need any fstab entry and usually also
will not appear in mtab if there is no fstab entry for them.
(You don't see it with a parameter-less 'mount') But KDE is preferring
fstab definitions (mountpoints and options) if they exist.
usbmount, however, maintains its own config file, and ignores fstab.
It has no way to map a certain device to a certain mountpoint.
It may still be useful to you. Here's a example usbmount.conf:
MOUNTPOINTS="/media/usb0 /media/usb1 /media/usb2 /media/usb3"
FILESYSTEMS="ext2 ext3 vfat"
MOUNTOPTIONS="sync,noexec,nodev,noatime"
FS_MOUNTOPTIONS="-fstype=vfat,uid=1000,gid=50,dmask=0007,fmask=0117"
To take full customized control you would probably write a custom script
which is called by udev, like '/etc/udev/mycard.rules' (and link into rules.d).
Look at /etc/udev/usbmount.rules:
# Rules for USBmount
KERNEL=="sd*", BUS=="usb", ACTION=="add", RUN+="/usr/share/usbmount/usbmount add"
KERNEL=="ub*", BUS=="usb", ACTION=="add", RUN+="/usr/share/usbmount/usbmount add"
KERNEL=="sd*", ACTION=="remove", RUN+="/usr/share/usbmount/usbmount remove"
KERNEL=="ub*", ACTION=="remove", RUN+="/usr/share/usbmount/usbmount remove"
You just put something like RUN+="/usr/local/mymount" in place.
You need some matching keys (strings or values) for a card insertion.
Find out what udev is doing on inserting/removing a card.
Look if something appears in /dev/disk/by-id or by-label or whatever
you prefer. (You also can add a mountpoint entry containing that
location in fstab, and put up an easy symlink on your desktop)
If the event is not popping up anything in /dev at all, then you still can
write your own udev rule if you know how to match the device, or, more
accurately, the inserted card. You may find some keywords in dmesg, or
/var/log/kern.log or syslog, to identify the device in the /sys structure.
Then you can query it by udevinfo. For example, my usb memory stick
(accessed as scsi device) can be queried by:
udevinfo -ap /sys/bus/scsi/devices/9\:0\:0\:0
... which produces lots of output like:
KERNEL=="9:0:0:0"
SUBSYSTEM=="scsi"
DRIVER=="sd"
ATTR{ioerr_cnt}=="0x2"
ATTR{iodone_cnt}=="0x62"
ATTR{iorequest_cnt}=="0x62"
ATTR{iocounterbits}=="32"
ATTR{timeout}=="30"
ATTR{state}=="running"
ATTR{rev}=="1.04"
ATTR{model}=="TransMemory "
ATTR{vendor}=="TOSHIBA "
ATTR{scsi_level}=="3"
ATTR{type}=="0"
ATTR{queue_type}=="none"
ATTR{queue_depth}=="1"
ATTR{device_blocked}=="0"
ATTR{max_sectors}=="240"
You can use any of these lines (within one 'parental' class) as matching key.
In this case, since i don't have anything else of toshiba, i would set up mycard.rule
like (untested!)
KERNEL=="sd*",ATTR{model}=="TransMemory ",ATTR{vendor}=="TOSHIBA ",ACTION=="add", RUN+="/usr/local/bin/mymount add'
KERNEL=="sd*",ATTR{model}=="TransMemory ",ATTR{vendor}=="TOSHIBA ",ACTION=="remove", RUN+="/usr/local/bin/mymount remove'
udev 'hotplug' is passing some usable variables to userspace, like the device name
that the kernel did apply top the new hardware. Sorry i can't be more detailed, my
machines aren't fully operable right now. This is partly out of memory, take it with a
grain of care. Have a look at http://www.reactivated.net/writing_udev_rules.html too.
hth,
micha
Reply to: