Lo hice y lo entendí

El blog de Vicente Navarro
29 mar

Creación de reglas udev para personalizar el nombre de los ficheros de dispositivo de las memorias USB

Linux ha mejorado mucho últimamente en lo que a dispositivos hotplug se refiere. Es mucho más flexible de lo que solía y con la últimas distribuciones y los últimos escritorios como KDE o GNOME, al meter una memoria USB, automáticamente nos la detecta y monta sin tener que hacer absolutamente nada más.

Esto se hace realidad gracias a tres componentes de Linux:

  • El Linux Hotplugging, que se encarga de cargar automáticamente los módulos/drivers para los dispositivos que el kernel detecta, bien en el arranque, bien dinámicamente.
  • El udev, que permite usar nombres lógicos en los ficheros de dispositivo (los que están bajo /dev).
  • El HAL – Hardware Abstraction Layer, que es el que permitiría que, por ejemplo, al conectar una cámara de fotos nos saliera en el escritorio una aplicación de gestión de fotos, pero también se encargaría, por ejemplo, de montar automáticamente las memorias USB al conectarlas.
  • El D-Bus, usado por el HAL para comunicar a todos los procesos interesados en la máquina los eventos de hardware que se vayan produciendo.

El documento de GNOME Integración de Hardware en el Escritorio cuenta todo esto muy bien en el capítulo El núcleo Linux y sus ayudantes.

Pero en este artículo quería centrarme en el udev. Yo tengo un montón de dispositivos de almacenamiento USB: Un dedo de 256MB (Kingston), otro de 512MB (sin marca aparente), otro de 8GiB (TrekStor) , un enclosure Venus DS3 con un disco Maxtor estándar de 250GB y finalmente, el típico lector de tarjetas de memoria (SD, CF, MS). Además también tengo por ahí un reproductor de MP3, la cámara de fotos, etc. El caso es que me resultaba muy desagradable tener que buscar cada vez en la salida del dmesg el fichero de dispositivo que le había tocado a cada cacharrito para poder montarlo. La solución a mi problema era el udev.

Inciso: Antes del udev había otro sistema llamado devfs con un propósito similar que fue bastante común durante bastante tiempo (según el el artículo de la WikiPedia del devfs, el udev existe desde el kernel 2.6.15 y el devfs está en los kernels de Linux >=2.4 && <2.6.18) , pero que fue descartado por diversos motivos. El FAQ del udev describe bastante bien alguno de ellos.

El primer paso para la configuración del udev a nuestra medida pasa por conectar nuestra memoria USB y por mirar las últimas lineas del comando dmesg:

usb 1-6: USB disconnect, address 5
usb 1-6: new high speed USB device using ehci_hcd and address 6
usb 1-6: configuration #1 chosen from 1 choice
scsi8 : SCSI emulation for USB Mass Storage devices
usb-storage: device found at 6
usb-storage: waiting for device to settle before scanning
scsi 8:0:0:0: Direct-Access     TrekStor USB Stick CS-D        PQ: 0 ANSI: 0
SCSI device sdi: 15625008 512-byte hdwr sectors (8000 MB)
sdi: Write Protect is off
sdi: Mode Sense: 10 00 00 00
sdi: assuming drive cache: write through
SCSI device sdi: 15625008 512-byte hdwr sectors (8000 MB)
sdi: Write Protect is off
sdi: Mode Sense: 10 00 00 00
sdi: assuming drive cache: write through
 sdi: sdi1
sd 8:0:0:0: Attached scsi removable disk sdi
sd 8:0:0:0: Attached scsi generic sg8 type 0
usb-storage: device scan complete

Tenemos una memoria USB de 8000MiB en /dev/sdi. Si la hubiéramos conectado antes o después de otras memorias USB, en vez de /dev/sdi podría haber sido /dev/sdh o /dev/sdj. Para no tener que buscar siempre ese fichero de dispositivo en la salida del dmesg, sería ideal que siempre fuera /dev/trekstor, independientemente de cuándo lo conectáramos.

Sabiendo ya el fichero de dispositivo, podemos mirar las propiedades del mismo con el comando udevinfo:

udevinfo -a -p $(udevinfo -q path -n /dev/sdi)

y en la salida del comando nos tenemos que fijar en los atributos:

looking at parent device '/devices/pci0000:00/0000:00:02.1/usb1/1-6':
KERNELS=="1-6"
SUBSYSTEMS=="usb"
DRIVERS=="usb"
ATTRS{serial}=="AAC26F0C1D29"
ATTRS{product}=="USB Stick CS-D"
ATTRS{manufacturer}=="TrekStor GmbH _ Co. KG"
ATTRS{maxchild}=="0"
 ATTRS{version}==" 2.00"
ATTRS{devnum}=="7"
ATTRS{speed}=="480"
ATTRS{bMaxPacketSize0}=="64"
ATTRS{bNumConfigurations}=="1"
ATTRS{bDeviceProtocol}=="00"
ATTRS{bDeviceSubClass}=="00"
ATTRS{bDeviceClass}=="00"
ATTRS{bcdDevice}=="0220"
ATTRS{idProduct}=="625f"
ATTRS{idVendor}=="0451"
ATTRS{bMaxPower}=="100mA"
ATTRS{bmAttributes}=="c0"
ATTRS{bConfigurationValue}=="1"
ATTRS{bNumInterfaces}==" 1"
ATTRS{configuration}==""

Con esta salida, elegimos un atributo que nos parezca razonablemente único en el sistema, y siguiendo el manual Writing udev rules como referencia, podemos crear una regla como la siguiente en un fichero con el nombre que queramos bajo /etc/udev/rules.d/. Yo lo voy a hacer en /etc/udev/rules.d/vicente.rules:

BUS=="usb", KERNEL=="sd*", ATTRS{product}=="USB Stick CS-D", SYMLINK+="trekstor%n"

y tras hacer un:

/etc/init.d/udev reload

la regla se activará y al conectar de nuevo la memoria USB se creará automáticamente un fichero de dispositivo con el nombre deseado, incluyendo el fichero de dispositivo de la primera partición:

# ls -la /dev/trekstor*
lrwxrwxrwx 1 root root 3 2007-03-24 00:58 /dev/trekstor -> sdi
lrwxrwxrwx 1 root root 4 2007-03-24 00:58 /dev/trekstor1 -> sdi1

y si ponemos esta línea en el /etc/fstab:

/dev/trekstor1  /mnt/trekstor vfat defaults,umask=000     0       0

cada vez que el sistema arranque con la memoria USB conectada se montará directamente en el directorio deseado sin más inconvenientes.

Esto, por supuesto, si lo hacemos con todos nuestros dispositivos, tendremos la diferenciación deseada entre memorias USB:

BUS=="usb", KERNEL=="sd*", ATTRS{product}=="USB Stick CS-D", SYMLINK+="trekstor%n"
BUS=="usb", KERNEL=="sd*", ATTRS{product}=="DataTraveler 2.0", SYMLINK+="kingston%n"
BUS=="usb", KERNEL=="sd*", ATTRS{manufacturer}=="P Technology", SYMLINK+="dedo512mb%n"

Hay que tener en cuenta que en la salida del comando udevinfo nos sale tanto la controladora de la memoria como lo que es la memoria en sí misma, la segunda como hija de la primera. Para entender esto mejor nos podemos fijar en el disco IDE Maxtor en el enclosure USB Venus que comentaba antes. En esta memoria USB podemos ver esta diferencia entre controladora y memoria. Éste es el disco y sale antes en la salida del udevinfo:

looking at parent device '/devices/pci0000:00/0000:00:02.1/usb1/1-8/1-8:1.0/host6/target6:0:0/6:0:0:0':
KERNELS=="6:0:0:0"
SUBSYSTEMS=="scsi"
DRIVERS=="sd"
ATTRS{ioerr_cnt}=="0x0"
ATTRS{iodone_cnt}=="0x36"
ATTRS{iorequest_cnt}=="0x36"
ATTRS{iocounterbits}=="32"
ATTRS{timeout}=="30"
ATTRS{state}=="running"
ATTRS{rev}=="    "
ATTRS{model}=="TM3250820A      "
ATTRS{vendor}=="MAXTOR S"
ATTRS{scsi_level}=="3"
ATTRS{type}=="0"
ATTRS{queue_type}=="none"
ATTRS{queue_depth}=="1"
ATTRS{device_blocked}=="0"
ATTRS{max_sectors}=="240"

y ésta es la controladora del enclosure:

looking at parent device '/devices/pci0000:00/0000:00:02.1/usb1/1-8':
KERNELS=="1-8"
SUBSYSTEMS=="usb"
DRIVERS=="usb"
ATTRS{serial}=="300000031605"
ATTRS{product}=="USB2.0 Storage Device"
ATTRS{manufacturer}=="Cypress Semiconductor"
ATTRS{maxchild}=="0"
ATTRS{version}==" 2.00"
ATTRS{devnum}=="4"
ATTRS{speed}=="480"
ATTRS{bMaxPacketSize0}=="64"
ATTRS{bNumConfigurations}=="1"
ATTRS{bDeviceProtocol}=="00"
ATTRS{bDeviceSubClass}=="00"
ATTRS{bDeviceClass}=="00"
ATTRS{bcdDevice}=="0001"
ATTRS{idProduct}=="6830"
ATTRS{idVendor}=="04b4"
ATTRS{bMaxPower}=="  0mA"
ATTRS{bmAttributes}=="c0"
ATTRS{bConfigurationValue}=="1"
ATTRS{bNumInterfaces}==" 1"
ATTRS{configuration}==""

Para tener el fichero de dispositivo con el nombre deseado, en el fichero /etc/udev/rules.d/vicente.rules podríamos la siguiente línea haciendo referencia a un atributo único de la controladora:

BUS=="usb", KERNEL=="sd*", ATTRS{manufacturer}=="Cypress Semiconductor", SYMLINK+="maxtor%n"

Podemos fijarnos en que la controladora tiene un path incluído en el path de la memoria:

/devices/pci0000:00/0000:00:02.1/usb1/1-8/1-8:1.0/host6/target6:0:0/6:0:0:0

y que es al que apunta el fichero de dispositivo dentro del sysfs:

# ll /sys/block/sdi/
total 0
drwxr-xr-x  6 root root    0 2007-03-28 21:54 ./
drwxr-xr-x 44 root root    0 2007-03-28 21:53 ../
-r--r--r--  1 root root 4096 2007-03-28 21:53 dev
lrwxrwxrwx  1 root root    0 2007-03-28 21:53 device -> ../../devices/pci0000:00/0000:00:02.1/usb1/1-6/1-6:1.0/host9/target9:0:0/9:0:0:0/
drwxr-xr-x  2 root root    0 2007-03-28 21:53 holders/
drwxr-xr-x  3 root root    0 2007-03-28 21:53 queue/
-r--r--r--  1 root root 4096 2007-03-28 21:53 range
-r--r--r--  1 root root 4096 2007-03-28 21:53 removable
drwxr-xr-x  3 root root    0 2007-03-28 21:53 sdi1/
-r--r--r--  1 root root 4096 2007-03-28 21:53 size
drwxr-xr-x  2 root root    0 2007-03-28 21:53 slaves/
-r--r--r--  1 root root 4096 2007-03-28 21:54 stat
lrwxrwxrwx  1 root root    0 2007-03-28 21:53 subsystem -> ../../block/
--w-------  1 root root 4096 2007-03-28 21:54 uevent

Para diferenciar el disco de la controladora podemos fijarnos en los drivers usados, ya que el disco tiene DRIVERS==”sd” (de SCSI Disk) mientras que la controladora tiene DRIVERS==”usb”. Además, un dísco típicamente tendrá de atributo ATTRS{max_sectors} mientras que un atributo típico de la controladora es ATTRS{bMaxPower}.

Estoy haciendo énfasis en fijarnos en los atributos de la controladora porque en la regla estamos poniendo BUS==”usb”. Si por ejemplo tienes un lector de tarjetas como éste:

Lector de tarjetas de memoria

en el que cada ranura es un /dev/sdX, resulta que la controladora es única para los cuatro discos y cada disco tiene propiedades diferentes. La controladora tendría este aspecto:

SUBSYSTEMS=="usb"
DRIVERS=="usb"
ATTRS{serial}=="0123456789abcdef"
ATTRS{product}=="USB Multi- Card Reader "
ATTRS{manufacturer}=="OTi"

y cada uno de los discos este, variando el model en cada uno de ellos:

SUBSYSTEMS=="scsi"
DRIVERS=="sd"
[...]
ATTRS{model}=="SD CARD Reader  "
ATTRS{model}=="MS CARD Reader  "
ATTRS{model}=="SM CARD Reader  "
ATTRS{model}=="CF CARD Reader  "

En este caso, es mucho mejor usar el BUS==”scsi” y las reglas quedarían así:

BUS=="scsi", ATTRS{model}=="SD CARD Reader  ", SYMLINK+="cardsd%n", OPTIONS+="all_partitions"
BUS=="scsi", ATTRS{model}=="CF CARD Reader  ", SYMLINK+="cardcf%n", OPTIONS+="all_partitions"
BUS=="scsi", ATTRS{model}=="SM CARD Reader  ", SYMLINK+="cardsm%n", OPTIONS+="all_partitions"
BUS=="scsi", ATTRS{model}=="MS CARD Reader  ", SYMLINK+="cardms%n", OPTIONS+="all_partitions"

y tras el /etc/init.d/udev reload tendremos:

# ll /dev/card*
lrwxrwxrwx 1 root root 3 2007-03-29 20:19 /dev/cardcf -> sdd
lrwxrwxrwx 1 root root 4 2007-03-29 20:19 /dev/cardcf1 -> sdd1
lrwxrwxrwx 1 root root 3 2007-03-29 20:19 /dev/cardcf3 -> sg3
lrwxrwxrwx 1 root root 3 2007-03-29 20:19 /dev/cardms -> sdg
lrwxrwxrwx 1 root root 3 2007-03-29 20:19 /dev/cardms6 -> sg6
lrwxrwxrwx 1 root root 3 2007-03-29 20:19 /dev/cardsd -> sdf
lrwxrwxrwx 1 root root 4 2007-03-29 20:19 /dev/cardsd1 -> sdf1
lrwxrwxrwx 1 root root 3 2007-03-29 20:19 /dev/cardsd5 -> sg5
lrwxrwxrwx 1 root root 3 2007-03-29 20:19 /dev/cardsm -> sde
lrwxrwxrwx 1 root root 3 2007-03-29 20:19 /dev/cardsm4 -> sg4

en un momento en el que hay una tarjeta SD (sdf1) y una CF metidas (sdd1). En este punto me queda la duda de por qué se crean enlaces a otros ficheros de dispositivo (sg3, sg6, sg5, sg4), pero los que nos hacen falta están correctos.

La opción all_partitions es una recomendación que aparece en el ejemplo del USB Card Reader del “Writing udev rules” y según la página de man de udev sirve para:

all_partitions will create the device nodes for all available partitions of a block device. This may be useful for removable media devices where media changes are not detected.

Podríamos haber usado BUS==”scsi” desde el principio, pero creo que así es mucho más ilustrativo de la dinámica de las reglas del udev.

El fichero /etc/udev/rules.d/vicente.rules queda definitivamente así:

BUS=="usb", KERNEL=="sd*", ATTRS{product}=="USB Stick CS-D", SYMLINK+="trekstor%n"
BUS=="usb", KERNEL=="sd*", ATTRS{product}=="DataTraveler 2.0", SYMLINK+="kingston%n"
BUS=="usb", KERNEL=="sd*", ATTRS{manufacturer}=="Cypress Semiconductor", SYMLINK+="maxtor%n"
BUS=="usb", KERNEL=="sd*", ATTRS{manufacturer}=="P Technology", SYMLINK+="dedo512mb%n"
BUS=="scsi", ATTRS{model}=="SD CARD Reader  ", SYMLINK+="cardsd%n", OPTIONS+="all_partitions"
BUS=="scsi", ATTRS{model}=="CF CARD Reader  ", SYMLINK+="cardcf%n", OPTIONS+="all_partitions"
BUS=="scsi", ATTRS{model}=="SM CARD Reader  ", SYMLINK+="cardsm%n", OPTIONS+="all_partitions"
BUS=="scsi", ATTRS{model}=="MS CARD Reader  ", SYMLINK+="cardms%n", OPTIONS+="all_partitions"

Es importante indicar que si las reglas tienen algún error de sintaxis, el udev se quejará en el syslog:

Mar 29 20:18:13 localhost udevd[4881]: add_to_rules: invalid rule '/etc/udev/rules.d/vicente.rules:9'

Finalmente, comentar que se pueden crear reglas de udev para muchos otros tipos de dispositivos como impresoras, tarjetas de red o grabadoras que también nos pueden venir muy bien.

Actualización 30/3/07 18:40: El artículo ha aparecido en Barrapunto. Allí se están comentando cosas interesantes. Me ha interesado especialmente un comentario de Ivan Vilata i Balaguer en el que explica que el udev crea por defecto también una serie de dispositivos bajo /dev/disk/by-* que nos pueden ser de utilidad.

Y, efectivamente, con todos mis cacharritos USB conectados, el directorio /dev/disk/by-id contiene las siguientes entradas:

lrwxrwxrwx 1 root root   9 2007-03-30 18:47 usb-Kingston_DataTraveler_2.0_27C08C4111818B31 -> ../../sdj
lrwxrwxrwx 1 root root  10 2007-03-30 18:47 usb-Kingston_DataTraveler_2.0_27C08C4111818B31-part1 -> ../../sdj1
lrwxrwxrwx 1 root root   9 2007-03-30 18:47 usb-MAXTOR_S_TM3250820A_300000031605 -> ../../sdk
lrwxrwxrwx 1 root root  10 2007-03-30 18:47 usb-MAXTOR_S_TM3250820A_300000031605-part1 -> ../../sdk1
lrwxrwxrwx 1 root root   9 2007-03-30 18:38 usb-OTi_CF_CARD_Reader_0123456789abcdef -> ../../sdd
lrwxrwxrwx 1 root root  10 2007-03-30 18:38 usb-OTi_CF_CARD_Reader_0123456789abcdef-part1 -> ../../sdd1
lrwxrwxrwx 1 root root   9 2007-03-30 18:38 usb-OTi_MS_CARD_Reader_0123456789abcdef -> ../../sdg
lrwxrwxrwx 1 root root   9 2007-03-30 18:38 usb-OTi_SD_CARD_Reader_0123456789abcdef -> ../../sdf
lrwxrwxrwx 1 root root  10 2007-03-30 18:38 usb-OTi_SD_CARD_Reader_0123456789abcdef-part1 -> ../../sdf1
lrwxrwxrwx 1 root root   9 2007-03-30 18:38 usb-OTi_SM_CARD_Reader_0123456789abcdef -> ../../sde
lrwxrwxrwx 1 root root   9 2007-03-30 18:38 usb-TrekStor_USB_Stick_CS-D_AAC26F0C1D29 -> ../../sdh
lrwxrwxrwx 1 root root  10 2007-03-30 18:38 usb-TrekStor_USB_Stick_CS-D_AAC26F0C1D29-part1 -> ../../sdh1
lrwxrwxrwx 1 root root   9 2007-03-30 18:38 usb-UT163_USB_Flash_Disk_20060400000401 -> ../../sdi
lrwxrwxrwx 1 root root  10 2007-03-30 18:38 usb-UT163_USB_Flash_Disk_20060400000401-part1 -> ../../sdi1

El directorio /dev/disk/by-label contiene entradas para las etiquetas de las particiones como las siguientes, pero requiere que la partición tenga etiqueta:

lrwxrwxrwx 1 root root  10 2007-03-30 18:47 KINGSTON -> ../../sdj1
lrwxrwxrwx 1 root root  10 2007-03-30 18:47 Maxtor_250G -> ../../sdk1
lrwxrwxrwx 1 root root  10 2007-03-30 18:38 TREKSTOR -> ../../sdh1

Los directorios /dev/disk/by-uuid y /dev/disk/by-path podrían ser útiles también pero parecen menos intuitivos.

Todas las reglas de udev que crean estos ficheros de dispositivo están en el fichero /etc/udev/rules.d/z20_persistent.rules.

También es interesante la posibilidad de añadir entradas al /etc/fstab que hagan referencia a la etiqueta de la partición. Esto lo explica la página de man del fstab:

Instead of giving the device explicitly, one may indicate the (ext2 or xfs) filesystem that is to be mounted by its UUID or volume label (cf. e2label(8) or xfs_admin(8)), writing LABEL=<label> or UUID=<uuid>, e.g., `LABEL=Boot’ or `UUID=3e6be9de-8139-11d1-9106-a43f08d823a6′. This will make the system more robust: adding or removing a SCSI disk changes the disk device name but not the filesystem volume label.

Si yo quisiera montar siempre la memoria Kingston con label KINGSTON en /mnt/kingston podría poner en el fstab una línea como esta:

LABEL=KINGSTON /mnt/kingston vfat defaults,umask=000 0 0

Los comandos para cambiar la etiqueta en los diferentes sistemas de ficheros son:

ext2/ext3 tune2fs -L etiqueta /dev/XXX
e2label /dev/XXX etiqueta
reiserfs reiserfstune -l etiqueta /dev/XXX
jfs jfs_tune -L etiqueta /dev/XXX
xfs xfs_admin -L etiqueta /dev/XXX
ntfs ntfslabel /dev/XXX etiqueta
FAT • Al crearlo con mkdosfs se puede especificar la opción -n etiqueta
• Con mlabel definiendo el nombre de la unidad en el /etc/mtools.conf
• Con el Konqueror funcionando como gestor de ficheros

Para finalizar esta actualización, quiero mencionar el artículo Persistent block device naming donde he encontrado los comandos para cambiar los labels pero que incluso habla de usar este tipo de ficheros de dispositivo by-id o by-label en el gestor de arranque.

Actualización 2/5/08: Para obtener el UUID de una partición, podemos usar el comando vol_id o el blkid:

# vol_id /dev/sdg1
ID_FS_USAGE=filesystem
ID_FS_TYPE=ntfs
ID_FS_VERSION=3.1
ID_FS_UUID=F680D4CE80D49709
ID_FS_UUID_ENC=F680D4CE80D49709
ID_FS_LABEL=Maxtor 250G
ID_FS_LABEL_ENC=Maxtor\x20250G
ID_FS_LABEL_SAFE=Maxtor_250G

# blkid /dev/sdg1
/dev/sdg1: UUID="F680D4CE80D49709" LABEL="Maxtor 250G" TYPE="ntfs"

Entradas relacionadas

17 Comentarios a “Creación de reglas udev para personalizar el nombre de los ficheros de dispositivo de las memorias USB”

  • Tirs Abril dice:

    Genial. ¿Dónde has estado toda mi vida?

    Solamente uno de los cinco servidores que administro en la empresa tiene el X instalado y fue a petición del cliente; yo tiro de consola el 90% del tiempo, y claro, al no tener escritorio no tenía el iconito automáticamente al conectar el cacharro de turno. Cada vez que tenía que copiar cosas desde/hacia un disco externo era un sinvivir. Incluso para un disco USB de backups (manías de otro cliente) tuve que hacerme un script que se pateaba todos los puntos de montaje buscando el dichoso disco, que además me cambiaba cada X tiempo “por rotación de backups” (ejem). Ahora se acabó: los discos se llamarán como yo les diga, y punto.

    En resumen: GRACIAS por compartir tu sabiduría. Un artículo muy útil.

    ¡Saludos!

  • Felipe dice:

    > En este punto me queda la duda de por qué se crean enlaces a otros ficheros de dispositivo (sg3, sg6, sg5, sg4), pero los que nos hacen falta están correctos.

    Se crean enlaces porque se lo estás diciendo con SYMLINK. Para simplemente llamarlos con un nombre, usa NAME+=”loquequieras%n”

    Un saludo

  • Figue dice:

    Muchas gracias por la entrada

  • Ivan dice:

    Muy bueno el artículo, como siempre. Cuando lo estaba leyendo he pensado “seguro que pasa a portada de barrapunto”, he ido a la web y allí estabas…. Ya llevas 3, sigue así ;-)

    Saludos, Iván.

  • Hola:

    Como ya se ha comentado en /., hay alternativas más sencillas usando en el fstab la identificación de los dispositivos por la etiqueta (LABEL=) o el UUID (UUID=).

  • Tirs Abril Muchas gracias a ti por tu visita. Me alegro mucho de que te haya resultado útil.

    Felipe Gracias por tu comentario, pero el problema es que en ese ejemplo /dev/sgX no pinta nada. Si cardcf es sdd, y cardcf1 es sdd1, ¿a qué santo cardcf3 es sg3?

    /dev/cardcf -> sdd
    /dev/cardcf1 -> sdd1
    /dev/cardcf3 -> sg3

    Fique A tí por la visita

    Iván ¡Muchas gracias! Vas a conseguir ruborizarme :oops: No puedo negar que me gusta que los artículos salgan en Barrapunto. Ya que te esfuerzas en escribir algo, que le pueda resultar útil a la máxima cantidad de gente posible.

    Manuel Fernandes Alonso Muchas gracias.Tras tu comentario y los de Barrapunto he actualizado el artículo con esos consejos. Gracias a vosotros está mucho más completo.

  • maeghith dice:

    Vaya, que oportuno, yo también me estoy peleando con udev (aunque con menos éxito, por lo que veo).

    ¿Has probado la opción “RUN” para ejecutar algún script?

    He visto en los foros de ubuntu, que es posible hacer esto, por ejemplo si tienes la unidad con datos cifrados, para descirfarlos automáticamente. Bastante majo el tema.

  • maeghith Espero que el artículo te ayude en tu pelea.

    Respecto al RUN, acabo de probar esta regla:

    BUS==”usb”, KERNEL==”sd*”, ATTRS{product}==”DataTraveler 2.0″, RUN+=”/tmp/prueba.sh”

    y al meter la memoria USB en cuestión, el script /tmp/prueba.sh sí que se ejecuta.

    Y muchas gracias por el enlace al foro de ubuntu. ¡Realmente es muy interesante!

  • Luis Ortega dice:

    Hola,

    Parece que gracias a tu articulo puedo entender un poco las reglas de udev. Gracias.
    Una pregunta, puedo cambiar el nombre a un dispositivo usb, concretamente un telefono, al que ya he creado la regla, para que cuando lo conecte me diga que se ha conectado Nokia6230i? como lo hago?
    Gracias otra vez.

    Salu2

  • Luis Ortega Hola Luis, no estoy seguro de entender bien tu preguna. Entiendo que conectas tu Nokia con el cable de datos USB y entonces ¿lo ves como una memoria USB normal o lo gestionas con alguna aplicación? En el primero de los casos, aplica exactamente lo que se explica en el artículo. Si lo que quieres es que el KDE o el GNOME te avisen de que se ha conectado el móvil, eso tendría que ocurrir sin que tú hagas nada…

  • Ivan dice:

    Sí, que te publiquen en barrapunto está genial :-P. Cuando pasaron a portada el mío del raid 1 hace un par de semanas estuve 4 días dándole el coñazo a mi mujer… jejeje.

    Saludos, Iván.

  • maeghith dice:

    Gracias por la prueba, ya he encontrado el problema: estaba usando zenity como payload en las pruebas, y entre que las reglas de udev se ejecutan como root, y que root no tiene sesión gdm en ubuntu, me era imposible ver los mensajes de zenity.

    Cuando cambié el zenity por un touch comprobé que funcionaba perfectamente :)

  • Bytecoders dice:

    El artículo simplemente genial. Ahora en mi opinión creo que el montaje de los SCSI de la cámara de fotos o el montaje automático de las memorias usb es más cosa de usbmount que no de la capa de abstracción de hardware (HAL).

    Saludos y enhorabuena por tu blog, simplemente genial.

  • @Bytecoders ¡Muchas gracias! Me alegro de que te haya gustado.

  • Pakito dice:

    hola

    yo estoy intentando hacer una regla udev para que se ejecute un script cada vez que se inserte o se quite un dispositivo USB (aparte de que lo ignore ya que sino carga el modulo usb_storage). Pero nada, no consigo que me funcione. Esto utilizaba:

    #SUBSYSTEM==”block”, \
    #SYSFS{idVendor}==”11d4″, \
    #SYSFS{idProduct}==”1043″, \
    #ACTION==”add”, \
    #RUN+=”/root/llave.sh start”, \
    #OPTIONS=”ignore_device”, \
    #ACTION==”remove”, \
    #RUN+=”/root/llave.sh stop”

    La unica forma de que me funcione es asi:

    SUBSYSTEM==”block”, \
    ACTION==”add”, \
    SYSFS{idVendor}==”11d4″, \
    SYSFS{idProduct}==”1043″, \
    #ACTION==”add”, \
    #IMPORT{program}=”/root/llave.sh start”, \
    OPTIONS=”ignore_device”
    #ACTION==”remove”, \
    #IMPORT{program}=”/root/llave.sh stop”

    Pero por mas que busco por Google, no entiendo como puedo hacerlo. ¿Alguna idea?¿Lectura recomendada para realizarlo y/o aprender?. gracias

    saludos Paco

  • Nevermind dice:

    En Ubuntu 8.10, el comando mlabel no tiene mas la opción -i, ni tampoco es posible asignar un Label usando :: de la forma clásica “mlabel /dev/sdxY ::NewLabel”

    Para asignar la letra de unidad en el /etc/mtools.conf, basta con hacer:
    sudo echo ‘drive x: file=”/dev/sdxY”‘ >> /etc/mtools.conf

    reemplazando sdxY por sda1 o el device que corresponda. Luego, para asignar el label hacemos
    sudo mlabel x:”New Label”

    (las comillas son si queremos un label con espacios)

    Para verificar:
    sudo mlabel -s x:

    Desde luego que x: puede cambiarse por la letra que uno quiera.

Tema LHYLE09, creado por Vicente Navarro