Re: Trouble auto-mounting with a PCMCIA flash reader... - Debian

This is a discussion on Re: Trouble auto-mounting with a PCMCIA flash reader... - Debian ; Maybe 'supermount' can do the trick (but i never installed it myself.) Generally, consider to zgrep 'keyword' /proc/config.gz to lookup if any required drivers are available to the running kernel. Did you already check how a full KDE session (udev/hald/kio) ...

+ Reply to Thread
Results 1 to 2 of 2

Thread: Re: Trouble auto-mounting with a PCMCIA flash reader...

  1. Re: Trouble auto-mounting with a PCMCIA flash reader...


    Maybe 'supermount' can do the trick (but i never installed it
    myself.)

    Generally, consider to zgrep 'keyword' /proc/config.gz to lookup
    if any required drivers are available to the running kernel.

    Did you already check how a full KDE session (udev/hald/kio)
    would handle insertion ?

    If inserting a card would produce an udev event, you can use
    udevinfo to get some usable keyword and place a custom udev
    rule in /etc/udev/rules.d. That would work without HAL or
    automount. (For a start, you can take 'usbmount' as a template,
    this is a very simple thingy installing only few files)

    micha


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

  2. Re: Trouble auto-mounting with a PCMCIA flash reader...


    Joe Emenaker :
    > 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 Thread