Stamattina ho scritto come sia possibile usare le regole di Udev per far si che i dispositivi vengano montati in una directory piuttosto che in un’altra a seconda del dispositivo. Ora vedremo come aggiungere regole a Udev per fargli eseguire un determinato script quando si monta una penna USB (o quando la si smonta).

Prima di tutto dobbiamo ottenere informazioni sull’hardware, quindi diamo questo comando da terminale:
# tail -f /var/log/syslog
e inseriamo la nostra periferica USB (penna, HD esterno). Otterremo un bel po’ di testo come output, segniamoci il percorso della device (ad esempio /dev/sdb).

Ora che sappiamo dove trovare la periferica, possiamo ottenere molte informazioni, facciamolo con questo comando:
$ udevinfo -a -p $(udevinfo -q path -n /dev/sdb)

Anche in questo caso come output otterremo molte righe di testo, ma tra questi, i dati che ci servono non sono molti, segnateveli, perche’ vi serviranno per scrivere la/e regola/e.

Un file di regole per Udev e’ ad esempio questo:

---8<---
BUS=="scsi", SYSFS{model}=="BLAblabla", KERNEL=="sd?1", NAME="pendatilavoro", OWNER="luca"
SUBSYSTEM=="block", ACTION=="add", RUN+="/etc/udev/dev.d/script/mount.dev"
SUBSYSTEM=="block", ACTION=="remove", RUN+="/etc/udev/dev.d/script/umount.dev"
---8<---

da salvare ad esempio su /etc/udev/rules/10-dam.rules (il numero davanti al nome indica la priorita’ di esecuzione, piu’ basso e’ il numero prima verra’ eseguita la regola).

Questo e’ il significato dei valori:

BUS=="scsi" =>                      la penna USB viene riconosciuta come disco scsi
SYSFS{model}=="UMni512MB*IOM2J4" => un modo per riferirsi a quella specifica penna USB
KERNEL=="sd?1" =>                   la prima partizione della penna
NAME="pendatilavoro" =>                  Udev mettera' la nostra penna nel percorso /dev/pendatilavoro (per la prima partizione)
OWNER="luca" =>                    il percorso /dev/pendatilavoro e' dell'utente luca

SUBSYSTEM=="block", ACTION=="add", RUN+="/etc/udev/dev.d/script/mount.dev" => quando la periferica viene inserita viene eseguito lo script RUN+="/etc/udev/dev.d/script/mount.dev"

SUBSYSTEM=="block", ACTION=="remove", RUN+="/etc/udev/dev.d/script/umount.dev" => quando la penna viene estratta viene eseguito lo script RUN+="/etc/udev/dev.d/script/umount.dev"

Aggiungendo script, potete ad esempio fare in modo che la penna si sincronizzi con una directory del vostro hard disk (potete utilizzare rsync) o quando la inserite, o prima di smontarla. Con rsync il comando e’ una cosa del genere:
$ rsync -a -v --delete /dev/pendatilavoro /home/utente/hddatilavoro
quindi con le dovute modifiche fate lo script e inserite il suo percorso nella regola di Udev.

Fonte: Udev – action add – remove

[^] torna su | post<li> | 

Abbiamo visto qualche tempo fa come montare in automatico i dispositivi USB, in quel caso i dispositivi venivano montati in un percorso casuale. Insomma, non proprio casuale, veniva montato nella prima directory libera di un elenco (con usbmount). Ma, come faccio a far montare in automatico un determinato dispositivo rimovibile in una determinata directory? Mi spiego meglio, se abbiamo due penne USB di diversa marca e un HD USB, come facciamo a fare in modo che la penna A venga montata nella directory A, la penna B nella directory B e l’HD esterno C nella directory C? Il modo esiste, vediamolo.

Prima di tutto bisogna conoscere qualcosa di udev, sapere come funziona e come scriverne le regole. Ho capito, non ne avete voglia.

Le regole di udev si trovano nella directory /etc/udev/rules.d/, meglio non modificare le regole gia’ esistenti, creiamo dunque un nuovo file, e siccome le regole vengono lette e processate in ordine alfabetico, il file che andiamo a creare per essere letto per primo lo possiamo nominare:

00_local.rules

Ma prima dobbiamo sapere come vengono identificati i nostri dispositivi. Diamo dunque il seguente comando:
# tail -f /var/log/messages
e inseriamo il dispositivo rimovibile.
Oppure, inseriamo il dispositivo e poi diamo questo comando:
$ dmesg
Possiamo subito notare il posizionamento (sda ad esempio), il tipo di prodotto e il modello (ad esempio External HDD e Western Digital).

Ora diamo il comando:
$ udevinfo -a -p /sys/block/sda
se il dispositivo non si trova in sda, ma sdb, sdc, o quello che e’, inserite il percorso giusto. Esce un output piuttosto lungo, ma non spaventatevi, le cose che ci interessano sono tre, annotatevi:

---8<---
KERNEL=="sda"
---8<---
ATTRS{vendor}=="WD"
---8<---
ATTRS{model}=="5000AAV External"
---8<---

Queste informazioni sono sufficienti per creare una regola. Infatti sono informazioni che possono essere reperite da udev, che le puo’ utilizzare per riconoscere il dispositivo.

Tutto quello che abbiamo visto fin qui e’ propedeutico alla scrittura delle regole. Veniamo ora alla scrittura della/e regola/e. Vogliamo che quando inseriamo il nostro Hard Disk Western Digital, venga montato nella directory /media/hdwd.
Creiamo il nostro file:
# nano /etc/udev/rules.d/00_local.rules
e aggiungiamoci la regola:

---8<---
KERNEL=="sda", ATTRS{vendor}=="WD", ATTRS{model}=="5000AAV External", NAME="%k", SYMLINK+="usbhdwd"
ACTION=="add", KERNEL=="sda", ATTRS{vendor}=="WD", ATTRS{model}=="5000AAV External", RUN+="/bin/mkdir /media/hdwd"
ACTION=="add", KERNEL=="sda", ATTRS{vendor}=="WD", ATTRS{model}=="5000AAV External", RUN+="/bin/mount -t vfat -o sync,flush,uid=1000,gid=100 /dev/usbhdwd /media/hdwd"
ACTION=="remove", KERNEL=="sda", ENV{ID_VENDOR}=="WD", ENV{ID_MODEL}="5000AAV_External", RUN+="/bin/umount /media/hdwd"
ACTION=="remove", KERNEL=="sda", ENV{ID_VENDOR}=="WD", ENV{ID_MODEL}="5000AAV_External", RUN+="/bin/rmdir /media/hdwd"
---8<---

Se fosse un Hard Disk partizionato, allora la regola sarebbe questa:

---8<---
KERNEL=="sd?1", ATTRS{vendor}=="WD", ATTRS{model}=="5000AAV External", NAME="%k", SYMLINK+="usbhdwd"
ACTION=="add", KERNEL=="sd?1", ATTRS{vendor}=="WD", ATTRS{model}=="5000AAV External", RUN+="/bin/mkdir /media/hdwd"
ACTION=="add", KERNEL=="sd?1", ATTRS{vendor}=="WD", ATTRS{model}=="5000AAV External", RUN+="/bin/mount -t vfat -o sync,flush,uid=1000,gid=100 /dev/usbhdwd /media/hdwd"
ACTION=="remove", KERNEL=="sd?1", ENV{ID_VENDOR}=="WD", ENV{ID_MODEL}="5000AAV_External", RUN+="/bin/umount /media/hdwd"
ACTION=="remove", KERNEL=="sd?1", ENV{ID_VENDOR}=="WD", ENV{ID_MODEL}="5000AAV_External", RUN+="/bin/rmdir /media/hdwd"
---8<---

Quando scrivete le vostre regole, state attenti a inserire i dati che corrispondono al vostro dispositivo. Ora potete creare in questo modo anche le regole per la vostra penna USB di marca x e per quella di marca y. Questo sistema e’ molto utile quando dovete usare piu’ dispositivi rimovibili contemporaneamente, venendo montati sempre nella stessa posizione, non rischiate di confondervi tra un dispositivo e l’altro.

[^] torna su | post<li> | 

blue.zener demonstrates some handy Linux UDEV foo that assigns the Bus Pirate to /dev/bus_pirate, instead of the boring /dev/ttyusb. This can be used to give any device a more memorable name under Linux.

Thanks for the tip!

[Tux image]

Ese fue el error que me dio Archlinux una vez que actualicé el sistema. Lo peor es que  aparecía cuando iniciaba el computador, dándome las posibilidades de ingresar la clave de root para solucionar el problema o de presionar control+d para reiniciar:

The superblock could not be read or does not describe a correct ext4
filesystem. If the device is valid and it really contains an ext4
filesystem (and not swap or ufs or something else), then the superblock
is corrupt, and you might try running e2fsck with an alternate superblock:
e2fsck -b 8193

******************* FILESYSTEM CHECK FAILED *************
* Please repair manually and reboot. Note that the root *
* filesystem is currently mounted read-only. To remount *
* it read-write type: mount -n -o remount,rw / *
* When you exit the mantenance shel the system will *
* reboot automatically. *
*********************************************************

Give root password for mantenance:

Obviamente no me quedaba más que reiniciar u.u

Estuve cerca de dos meses con el problemita =/. De cada dos veces que iniciaba el sistema una me mandaba el error u.u. Entonces puse esto en un tema del foro oficial de archlinux y adivinen qué… no me ayudaron . Pasó otro mes y pedí que por favor alguien me diera alguna idea para solucionar este asunto, esta vez, por suerte, dos usuarios de la comunidad me ayudaron Aquí pongo la solución que funcionó para mi:

Mi fstab (antes de solucionar el problema) era así:

#
# /etc/fstab: static file system information
#
#

none /dev/pts devpts defaults 0 0
none /dev/shm tmpfs defaults 0 0

#/dev/cdrom /media/cd auto ro,user,noauto,unhide 0 0
#/dev/dvd /media/dvd auto ro,user,noauto,unhide 0 0
#/dev/fd0 /media/fl auto user,noauto 0 0

/dev/sda1 / ext4 defaults 0 1
/dev/sda3 swap swap defaults 0 0
/dev/sda4 /home ext4 defaults 0 1
/dev/sdb1 /home/zuargo/Sata ext4 defaults 0 1

Pero debía ser así:

#
# /etc/fstab: static file system information
#
#

none /dev/pts devpts defaults 0 0
none /dev/shm tmpfs defaults 0 0

#/dev/cdrom /media/cd auto ro,user,noauto,unhide 0 0
#/dev/dvd /media/dvd auto ro,user,noauto,unhide 0 0
#/dev/fd0 /media/fl auto user,noauto 0 0

UUID=2727445b-47fa-4ffb-b70d-370a13651a4e / ext4 defaults 0 1
UUID=2222e40b-f06b-496e-bf29-4845a8f4d164 swap swap defaults 0 0
UUID=f4129b69-5944-476f-8db7-668cb5e81679 /home ext4 defaults 0 1
UUID=3a2a074a-ef50-4faa-94e8-b53b3de51508 /home/zuargo/Sata ext4 defaults 0 1

¿Notan la diferencia? en vez de decir el nombre de las particiones, es decir, /dev/sda1, /dev/sda2, /dev/sdb1, etc. el fstab muestra ese parámetro llamado UUID, no me preguntes qué diablos es eso porque no lo se xD. O sea para solucionar el problema debes conseguir las UUID de tus particiones, esto lo puedes lograr mediante el comando blkid:

[root@zuargo-archlinux ~]# blkid
/dev/sda1: UUID=”2727445b-47fa-4ffb-b70d-370a13651a4e” TYPE=”ext4″
/dev/sda3: UUID=”2222e40b-f06b-496e-bf29-4845a8f4d164″ TYPE=”swap”
/dev/sda4: UUID=”f4129b69-5944-476f-8db7-668cb5e81679″ TYPE=”ext4″
/dev/sdb1: UUID=”3a2a074a-ef50-4faa-94e8-b53b3de51508″ TYPE=”ext4″

Luego reemplaza dichas UUID en tu fstab por el /dev/sdxx que corresponda, guarda los cambios, reinicia y listo (al menos a mi me funcionó ).

Respecto a por qué se debe el problema he leído que es un ¿bug? de archlinux con udev (o algo así xD)

Muchas gracias a foutrelis y a Leonid.I, ambos, usuarios del foro oficial de Archlinux, quienes me ayudaron a resolver este problemilla ^^.

Saludos y espero que a alguien le sirva esto

Since the adoption of Kernel 2.6, Linux has used the udev system to handle devices such as USB connected peripherals. If you want to change the behavior when you plug something into a USB port, this section is for you. As an example, we will use a USB thumb drive but these methods should translate to any device handled by udev. As a goal for this exercise we decided to create a symlink and execute a script when a specific thumb drive was loaded. The operating system we used for this exercise is Ubuntu 9.04 Jaunty Jackalope.

Background Investigation

Before writing rules, we have to gather all the information needed to identify our device. We found the block device node that the drive was assigned to by plugging it in and checking /var/log/messages. We then pass that location (/dev/sdd1) to two commands that we run at the same time. Some distributions use the “udevinfo” command but with Ubuntu 9.04 the command has changed to “udevadm info”:

udevadm info -a -p $(udevadm info -q path -n /dev/sdd1)

The output of this is pretty meaty. We need to find the top of the chain that provides the block node which is used for mounting removable storage (in our case, /dev/sdd1). Using this KERNEL as identification will ensure that our symlink points to a mountable block device and not some part of the USB controller. We are also looking for device specific identifiers that differentiate this particular thumbdrive from all others:

looking at device '/devices/pci0000:00/0000:00:02.1/usb1/1-2/1-2:1.0/host29/target29:0:0/29:0:0:0/block/sdd/sdd1':
 KERNEL=="sdd1"
 SUBSYSTEM=="block"
 DRIVER==""
 ATTR{partition}=="1"
 ATTR{start}=="63"
 ATTR{size}=="31310622"
 ATTR{stat}=="     208    15448    16282      776        2        0        2       12        0      508      788"

looking at parent device '/devices/pci0000:00/0000:00:02.1/usb1/1-2':
KERNELS=="1-2"
 SUBSYSTEMS=="usb"
 DRIVERS=="usb"
 ATTRS{configuration}==""
 ATTRS{bNumInterfaces}==" 1"
 ATTRS{bConfigurationValue}=="1"
 ATTRS{bmAttributes}=="80"
 ATTRS{bMaxPower}=="200mA"
 ATTRS{urbnum}=="1858"
 ATTRS{idVendor}=="13fe"
 ATTRS{idProduct}=="1f00"
 ATTRS{bcdDevice}=="0110"
 ATTRS{bDeviceClass}=="00"
 ATTRS{bDeviceSubClass}=="00"
 ATTRS{bDeviceProtocol}=="00"
 ATTRS{bNumConfigurations}=="1"
 ATTRS{bMaxPacketSize0}=="64"
 ATTRS{speed}=="480"
 ATTRS{busnum}=="1"
 ATTRS{devnum}=="69"
 ATTRS{version}==" 2.00"
 ATTRS{maxchild}=="0"
 ATTRS{quirks}=="0x0"
 ATTRS{authorized}=="1"
 ATTRS{manufacturer}=="OCZ"
 ATTRS{product}=="DIESEL"
 ATTRS{serial}=="50E6920B000AE8"

In writing a udev rule, any of these characteristics can be used as conditions for the rule’s execution. That being said, only properties from one parent of the device and from the device itself  can be match. Trying to match values from more than one parent in the chain will be invalid and will not work.

The Rule

Rule files are stored in the /etc/udev/rules.d/ directory. We got some advice from the README in that directory on how to name rule files:

Files should be named xx-descriptive-name.rules, the xx should be
chosen first according to the following sequence points:

< 60  most user rules; if you want to prevent an assignment being
overriden by default rules, use the := operator.

these cannot access persistent information such as that from
vol_id

< 70  rules that run helpers such as vol_id to populate the udev db

< 90  rules that run other programs (often using information in the
udev db)

>=90  rules that should run last

We plan to run a script with this rule so we gave it a name that started with a higher number than our other rules but lower than 90. We used the filename:

81-thumbdrive.rules

The first part of a udev rule is the matching keys. We will use the KERNEL entry from the very top of the chain as well as the idVendor, idProduct, and serial attributes from the device specific information. This will positively identify this particular thumb drive and ignore all others. The kernel argument uses  a question mark as a wild card so that if our drive were mounted on a different node (ie: sda1, sdb1, sdc1, etc.) it could still be identified.

KERNEL=="sd?1", ATTRS{idVendor}=="13fe", ATTRS{idProduct}=="1f00", ATTRS{serial}=="50E6920B000AE8"

Now that we have the keys necessary to identify the particular hardware we’re looking for we can add assignment arguments. In our case we added two. The first creates a symlink to this device inside of the /dev/ directory. The second executes a script in our home directory:

SYMLINK+="hackaday", RUN+="/home/mike/notify-plugin.sh 'HackaDay Thumbdrive:' 'Connected as: $KERNEL'"

Here is the final rule assembled into one line:

KERNEL=="sd?1", ATTRS{idVendor}=="13fe", ATTRS{idProduct}=="1f00", ATTRS{serial}=="50E6920B000AE8", SYMLINK+="hackaday", RUN+="/home/mike/notify-plugin.sh 'HackaDay Thumbdrive:' 'Connected as: $KERNEL'"

We added this as the only line in our rule file and then restarted udev using these commands:

sudo nano /etc/init.d/81-thumbdrive.rules
sudo /etc/init.d/udev restart

The Script (and the bug workaround)

We wanted to use the pop-up notification we covered a while back but couldn’t get it to work. After a bit of frustration we found out that the notify-send package has trouble putting notifications on a user’s screen when called from a script run by root. There is a workaround for this bug. We altered the script just a bit for our purposes and pasted it to a new file named: /usr/local/bin/alt-notify-send

#!/bin/sh
user=`whoami`
pids=`pgrep -u $user gnome-panel`
title=$1
text=$2
timeout=$3
icon=$4

if [ -z "$title" ]; then
 echo You need to give me a title >&2
 exit 1
fi
if [ -z "$text" ]; then
 text=$title
fi
if [ -z "$timeout" ]; then
 timeout=60000
fi

for pid in $pids; do
 # find DBUS session bus for this session
 DBUS_SESSION_BUS_ADDRESS=`grep -z DBUS_SESSION_BUS_ADDRESS \
 /proc/$pid/environ | sed -e 's/DBUS_SESSION_BUS_ADDRESS=//'`
 # use it

 #icon hack:
 if [ -z $icon ]; then
 DBUS_SESSION_BUS_ADDRESS=$DBUS_SESSION_BUS_ADDRESS \
 notify-send -u low -t $timeout "$title" "$text"
 else
 DBUS_SESSION_BUS_ADDRESS=$DBUS_SESSION_BUS_ADDRESS \
 notify-send -u low -t $timeout -i "$icon" "$title" "$text"
 fi
done

We then created the script that the udev rule calls. This is placed in our home directory at /home/mike/notify-plugin.sh

#!/bin/bash

su mike alt-notify-send "$1" "$2" 6000 "/home/mike/hackaday_icon.png"

The script can do just about anything we want it to. In this case it calls the notification workaround script passing two strings from the udev rule, a delay time, and an icon to display with the pop-up.

Order of events:

Now that everything’s in place, let’s take a look at what happens when our drive is plugged in.

1. -USB drive is plugged into the computer
2. -Udev checks the /etc/udev/rules.d/ directory and starts using the rule files in order
3. -Udev gets to our file: 81-thumbdrive.rules and matches the “sd?1″ kernel, idVendor, idProduct, and serial number of the thumbdrive.
4. -If udev confirms a match on our four conditions, a symlink is created at /dev/hackaday and the /home/mike/notify-plugin.sh script is executed, passing it a message that includes the kernel information.
5. -Our script executes creating a pop-up notification using the alt-notify-send workaround.
6. -HAL takes over, automatically mounting our drive (this is part of Ubuntu’s removable storage handling and unrelated to our udev rule).

Here we see the symlink pointing to our block device and the pop-up notification:

Other uses:

Udev rules give you control over the hardware attached to your machine. If you are working on a USB connected project, these rules will allow you to set permissions for access, execute scripts when added or removed, and provide a persistent symlink for accessing this hardware without relying on the same node name each time the device is connected. We use a udev rule to allow avrdude to access our AVR Dragon programmer without root permission. In this case our rule sets read/write permissions for owner and group, then assigns the device to the “plugdev” group. As long as the user trying to run avrdude is a member of the plugdev group the program will be able to access the dragon. Here’s the rule:

SUBSYSTEM=="usb", ATTR{idVendor}=="03eb", ATTR{idProduct}=="2107", MODE="0660", GROUP="plugdev"

We hope this helps clarify how the udev system works. Give it a try with your next project.

Resources:

• Writing udev rules by Daniel Drake: http://reactivated.net/writing_udev_rules.html
• notify-send bug: https://bugs.launchpad.net/ubuntu/+source/libnotify/+bug/160598
• notify-send workaround: http://ubuntuforums.org/showthread.php?p=6889270#post6889270

No os alarméis con el título Sólo es una cosa curiosa. Cuando instalo Fedora 11, antes de actualizar ningún paquete, me arranca en 25 segundos más o menos. Pero una vez que actualizo todos los paquetes, tarda más de un minuto. Al principio no le di importancia porque pensé que sería problema del kernel y se solucionaría en la siguiente versión, pero no fue así. Luego pensé que a lo mejor sólo ocurría en la versión de 64 bits e instalé la de 32 bits. Nada, todo igual. Pues investigando un poco descubrí que el problema es el paquete udev y la librería libudeb0. No se por qué, pero hice un downgrade y ahora me arranca en 21 segundos. Una maravilla. Si os pasa lo mismo, abrid una terminal y escribid:

su -c ‘yum downgrade udev libudev0′

Generally, the command “migrate” of the Vmware Infrastructure Client is a very safe operation and you can move completely one virtual machine from one ESX server to another one in few steps and few minutes.

The n.1 error that could happen is that the single virtual ethernet controller eth0 is “disappeared” after migration and your machine lost its ip address (and this could be REALLY dramatic).

The solution, in my cases (on a Suse 10.1 with only one ethernet), was always the same:

go to /etc/sysconfig/network

locate a file similiar to ifcfg-eth-id-XX:XX… that’s related to the old mac address of eth0

rename it simply to ifcfg-eth0 (with mv command)

go to /etc/udev/rules.d

edit a file named 30-net_persistent_names

inside there are X lines where X is the number of your eth devices (old, new, used, unused…); in a default situation there are two lines, one old for eth0 and one new for a new created eth1

delete the first line that includes the same old mac address you saw before (related to eth0 as you can see at the end of that line) and change from eth1 to eth0 in the remaining line, that’s the one containing the new mac of your ethernet card.

Save and reboot.Now your eth0 should be ok as in the past.

Eu instalei o driver proprietário da minha placa wireless e por algum motivo que eu desconheço ele não fica com o nome “wlan0″. O pior é que eu tenho um amigo otário que ficava tirando onda por causa dessa bobagem. ¬¬’

Mas tudo bem, vai ai a solução que eu encontrei.

No arquivo /etc/udev/rules.d/50-udev.rules (o número 50 pode ser diferente) eu acrescentei a seguinte linha:

SUBSYSTEM==”net”, DRIVERS==”?*”, ATTRS{address}==”XX:XX:XX:XX:XX:XX”, NAME=”wlan0″

e dei um restart no udev:

# /etc/init.d/udev restart

Referência: http://www.science.uva.nl/research/air/wiki/LogicalInterfaceNames

Para ir mais longe: http://www.debianadmin.com/rename-network-interface-using-udev-in-linux.html

PS: da última vez que eu tentei ele não mudou o nome só reiniciando o udev.

[]’s

I got an error today trying to upgrade a gentoo cluster:

[blocks B ] >=sys-fs/udev-126 (“>=sys-fs/udev-126″ is blocking
sys-fs/cryptsetup-1.0.6)

Solution:

emerge -u cryptsetup

Done! After try to reboot to check if the udev detects all your network devices correctly.

Although I should learn for my ongoing exams I found a few moments to try getting auto-mounting on the console. (Note: This is rather a post for me to remember than anything useful )

As I didn’t find a properly working solution for my minimal installation (some troubles with thunar and I wanted also for the console), I decided to do a poor alternative on my own. I tried to make it almost as convenient as in GNOME (or KDE…) as I was sick of always typing “sudo mount /dev/sd?1 /mnt” which also led to some troubles when using more than one stick.

It’s no more than two small scripts combined with two rules of udev (save as /etc/udev/rules/01-YOURNAME.rules and modify the script path):
BUS=="usb", KERNEL=="sd??", ACTION=="add", RUN+="/home/flo/.scripts/udev/mount.sh %k"
BUS=="usb", KERNEL=="sd??", ACTION=="remove", RUN+="/home/flo/.scripts/udev/umount.sh %k"
These lines execute mount.sh when attaching an USB device and execute umount.sh when removing it. “%k” gives the device name (e.g. sdb1) as parameter for the script.

mount.sh:

#!/bin/bash
label=$(ls -l /dev/disk/by-label/ | grep $1)
if [ $? -eq 0 ]; then	#found the device
    label=$(echo $label | sed -e 's/.*:...//g' | sed -e 's/.->.*//g')
else
    label=$(ls -l /dev/disk/by-uuid | grep $1 | sed -e 's/.*:...//g' | sed 's/.->.*//g')
fi
mkdir /media/$label
mount /dev/$1 /media/$label -o sync,gid=46,umask=007

This script tries to find the label of the partition. If not possible it uses the UUID as a name for the mount directory, which is /media/{UUID|LABEL}. It finally mounts the device into this newly created folder, setting the “sync” option, which makes it save to remove the device without umounting it. “gid=46,umask=007″ means, that only root and members of the group “plugdev” are allowed to acces the device – this is needed for FAT formated sticks.

umount.sh:

#!/bin/bash
label=$(mount | grep $1 | sed -e 's/.*\/media\///g' | sed -e 's/.type.*//g' )
umount -l /dev/$1
rmdir /media/$label

This script umounts the device and removes the folder, that was created.

Important note: These scripts should *not* be editable by users as they are executed with root rights – and therefor might be used to “hack” the system when modified!

I have no idea, how well these lines work with hard drives containing several partitions (I don’t have one here at the moment) or with encrypted partitions. I’ll have a look at that after the exams (in roughly 2 weeks).

As always: Use with care, I’m not responsible for any harm

In my earlier post on getting a Ubuntu VM running on VPC, I neglected one important and usually insignificant detail: how to disable udev for the VM’s NICs.

The problem with udev is that it effectively disables the VM’s NIC under certain conditions. To understand why, it helps to make some observations about the various modules involved.

Udev is the device manager for Linux 2.6 systems. It is responsible for populating /dev with only the devices that are present. It provides notification to other software when devices are changed. And, most importantly for this blog post, it provides “persistent naming for devices when they move around the device tree.” So, if you move your USB cabling and routers around, your machine should still be able to identify, say, your printer. Or if you add a new NIC and your system detects it before your existing eth0, your old NIC will still be eth0 and your new one will be eth1. This is pretty awesome, and it helps resolve some of the problems I remember having with old PCs, trying to guess which device name maps to which physical device.

On Hyper-V (or Virtual Server, or Virtual PC), NICs are usually virtual, so they get assigned virtual MAC addresses. The default configuration is to let Windows pick the MAC address. These MAC addresses are typically stable, unless you do something like recreate the NIC or move the VM to a new host.

The scenario that this blog post is concerned about is this: you set up a VM on one host, and then you move it to another host. You might move it for any number of reasons: you set it up on VPC and want to permanently host it on Hyper-V, or your Hyper-V hosting situation changes and you need to migrate VMs around, or whatever. Following the move, your VM is no longer on the network! Bad news.

So, when you’re setting up your VM, you need to consider how udev will interact with Hyper-V. Some possible solutions include assigning a static MAC address to the NIC, or making udev smart enough to realize that if the old NIC went away and a new one is in its place, that it should use the new one in place of the old one. My solution is to make udev ignore eth*, since I usually am configuring a Linux VM to run some particular service, and I will not be changing the network configuration in any significant way. My solution is likely to be affected by upgrades because it modifies files that are generated by scripts.

And now, to the point of this post: how to make udev ignore your eth* devices:

1. Open /etc/udev/rules.d/75-persistent-net-generator.rules in your favorite text editor.
2. On line 21, where it says KERNEL!="eth*|ath*… remove eth*|. For example, on my system, I start with
   KERNEL!="eth*|ath*|wlan*[0-9]|ra*|sta*|ctc*|lcs*|hsi*", GOTO="persistent_net_generator_end"
   and end up with
   KERNEL!="ath*|wlan*[0-9]|ra*|sta*|ctc*|lcs*|hsi*", GOTO="persistent_net_generator_end"
3. If udev has already renamed your nic, you’ll also need to open /etc/udev/rules.d/70-persistent-net.rules and remove any eth* entries you find.

This should work on any Linux with udev (kernel >= 2.6). Line 21 is the right one to change on Ubuntu 8.10 and 8.04.2 systems that I’ve configured this way.

Stworzyć plik /etc/udev/rules.d/01-touchpad.rules

Zawartość:

SUBSYSTEM=="usb", SYSFS{product}=="*Mouse*"
ACTION=="add", SUBSYSTEM=="input", ENV{ID_CLASS}="mouse", RUN+="/usr/bin/synclient TouchpadOff=1"
ACTION=="remove", SUBSYSTEM=="input", ENV{ID_CLASS}="mouse", RUN+="/usr/bin/synclient TouchpadOff=0"

O PySDM (Storage Device Manager) é um gerenciador de pontos de montagem, permitindo alterar a forma como os dispositivos são montados no sistema. Ele permite definir graficamente o nome da partição, ponto de montagem e opções, como montagem pelo usuário, acesso, etc. Ele realiza as alterações no fstab sozinho. É, isso mesmo, edite o fstab pelo modo grafico! Se você quiser, ao invés de alterar o fstab, é possível criar regras dinâmicas para o udev. Tudo isso é feito por meio de assistentes simplificados. Um bom programa que ainda permite aprender sobre as opções mexendo com uma interface fácil.

Procure pelo pacote pysdm no gerenciador de pacotes de sua distro, não irá se arrepender.

changing eth0 name to eth1 and eth2 after each reboot. it is a bug in udev package.

Con este mensaje en la lista de correo de Ubuntu devel, se anunció que Ubuntu 9.10 karmic Koala ya esta entre nosotros. Que quede claro, que es la version Alpha 1, por lo que queda un laaargo camino de desarrollo por delante.

Las cosas que se presentan en esta versión, por lo pronto, son:

• Administración de energía y “mapeado” de las teclas especiales Fn de las notebooks movida de Hal (Hardware Abstraction Layer) a DeviceKit-power y udev-extras.
• Nueva arquitectura para el testeo de los drivers de video de Intel.
• GCC 4.4 como el compilador por defecto.

Y las unicas maneras de upgradear nuestras PCs a esta version, es mediante los cd’s alternativos (tanto para ubuntu como kubuntu y xubuntu) o mediante:

ALT+F2

update-manager -d

Links relacionados:
Karmic Koala Alpha 1 | Ubuntu.

Como ya  os contaba en el post de la clonación tenía problemas con paquetes no encontrados. Ahora ya tengo todos los paquetes puesto que volví a ejecutar apt-mirror como ya indiqué en el truco de apt-mirror.

Ahora he intentado hacer el apt-get dist-upgrade.

Se detiene en:

mkdir: no se puede crear el directorio «/tmp/mkinitramfs_hoESCF/etc/udev/rules.d»: El fichero ya existe
cpio: ./sbin/udevsettle: No se puede stat: No existe el fichero ó directorio
cpio: ./sbin/udevtrigger: No se puede stat: No existe el fichero ó directorio
cpio: ./bin/udevinfo: No se puede stat: No existe el fichero ó directorio
dpkg: el subproceso post-installation script devolvió el código de salida de error 1

Al principio creía que era por mis paquetes codip2p del proyecto desdeslin pero no era así porque tenía la versión del initramfs-tools era la de jaunty.

Al final lo que he hecho ha sido enlazar udevsettle y udevtrigger al binario true.

Con udevinfo no había manera así que he tenido que editar un fichero de configuración de initramfs-tools (Vaya ahora mismo no tengo la ruta) para que hiciera caso omiso del mismo. Para que no lo copiaran.

En Ubuntu (y no sé si en Debian) esos tres comandos se han substituido por uno nuevo que hace las veces de ellos.

Pero no sé por qué el initramfs-tools sigue haciendo referencia a ellos.

Todo esto lo he hecho offline y es posible que actualice este post con enlaces a gente que le ha haya pasado lo mismo y con su solución.

Note: installing iPhone updates through VirtualBox is not a good idea. Make sure you have a backup method to restore your phone before diving into this.

I love my iPhone, but I hate that I can’t sync it natively inside Linux. I was never able to get iTunes working running under Wine, so I’ve been forced to create a virtual machine running WinXP to sync it. I don’t like the idea of a VM running in the background, wasting system resources when it’s not being used. I wanted a better solution.

With the help of udev and VirtualBox command-line tools, I was able to come up with something better. Now when I’m ready for bed I plug my iPhone in, VirtualBox automatically boots the VM, and it syncs with iTunes. When I unplug the phone, Windows shuts down automatically. The only time the VM is using system resources is while I’m sleeping, so I don’t care.

I think this is as good as it gets with the iPhone on Linux and the only compromise is the time invested to set it up.

To do this, you’ll first need to install the full version of Sun’s VirtualBox, it includes USB features that are required. It’s free for personal use. Create a new VM with a bare Windows install on it. I didn’t install any additional updates and I disabled Windows Update, since it’s behind a NAT and I won’t be doing anything other than the sync on it. I also disabled a bunch of unnecessary services and ran Bootvis to minimize the VM boot time. Then I mapped a network drive to my music folder (on the host system) so iTunes will have access to my entire music collection. I logged in with my iTunes account and resubscribed to all my podcasts. At this point it’s not a bad idea to make a copy of the VM in it’s pristine state.

VirtualBox Settings

Shut down Windows. In VirtualBox, right-click the VM and select Preferences. You should tell it to use VT-x/AMD-V (General > Advanced) if you have a relatively modern processor that supports virtualization extensions; it’s not a requirement but will improve performance. The settings you will need are under USB. Check “Enable USB Controller” and “Enable USB 2.0 EHCI Controller”, the click the plus icon to add a filter. While your iPhone is attached to the system, you should see it listed in the dropdown (Apple Inc. iPhone), select it and click OK. This is required so your VM can see the device. You might also want to configure a sound device (PulseAudio) or iTunes will complain.

Now we get to the fun stuff, tweaking the host Linux system and writing BASH scripts. First, let’s create a log file that anyone can write to in case we need to troubleshoot:

$ sudo touch /var/log/iphone.log

$ sudo chmod 777 /var/log/iphone.log

Now, we need to get the internal ID of the VM you created.

$ VBoxManage list vms

You should see the name of the new VM followed by it’s UUID in parenthesis. Copy that UUID, we’ll need it for our first script:

iphone_attach.sh

#!/bin/bash
export XAUTHORITY=/home/nathan/.Xauthority
export DISPLAY=:0.0
su nathan -c “/usr/bin/VBoxManage startvm bc341828-db3b-46a9-8bc9-153c8eb35ad7″ >> /var/log/iphone.log

The two export lines tell the script which X Windows session to attach to. The final command uses the VBoxManage tools to start your VM, log the output, and do it under your own user account (since this will run as root). Obviously you’ll need to change “nathan” to your account name for each instance. You should also replace the UUID with your own. The remove script is not all too different:

iphone_remove.sh

#!/bin/bash
export XAUTHORITY=/home/nathan/.Xauthority
export DISPLAY=:0.0
su nathan -c “/usr/bin/VBoxManage controlvm bc341828-db3b-46a9-8bc9-153c8eb35ad7 acpipowerbutton” >> /var/log/iphone.log

Again, the export commands tell it which X session to use and we use VBoxManage to simulate an ACPI shutdown. You’ll need to replace the UUID with your own and change the user name and home folder path. Make sure these scripts work before you move on to the udev stuff.

grab the serial number

Note, this section was originally created using 0810 (Intrepid) but it broke in Jaunty (0904). I have another way to configure this so it works in Jaunty at the end of this post (it may also work in Interpid).

Now we need to tell Linux to run the above scripts when the device is connected/disconnected from the USB bus. First we need to find the serial number of your iPhone so we can tell udev what to look for.

$ lsusb | grep Apple

This displays the USB bus and device numbers for your phone, note the two 3-digit numbers and plug them into the next command.

udevinfo -a -p `udevinfo -q path -n /dev/bus/usb/004/002`|grep “ATTR{serial}”

Change 004 to the bus number you got in the previous command and change 002 to your device number. This digs into the attributes of your iPhone and displays the serial number which we’ll need later on. Note that you can remove the grep command to view all available attributes of your phone if you’re curious.

udev stuff

Go to the udev rules directory and create a new iphone rule, use a lower number like 98 so it gets processed after the other rules.

$ cd /etc/udev/rules.d

$ sudo vi 98-iphone.rules

98-iphone.rules

ACTION==”add”, SUBSYSTEM==”usb”, ATTR{serial}==”c4560xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx”, SYMLINK+=”iphone”, RUN+=”/home/nathan/scripts/iphone_attach.sh”

ACTION==”remove”, SYMLINK==”iphone” ,RUN+=”/home/nathan/scripts/iphone_remove.sh”

The first line here describes what to look for when a device is attached and what to do when it finds your iPhone. The ACTION, SUBSYTEM, and ATTR declarations tell it to watch for a USB device being added with the serial number of your iPhone. SYMLINK tells it to create an entry on the dev file system for it (/dev/iphone); through trial and error I discovered that this is required so we have something to look for when the phone is disconnected. The RUN section tells it to run the iphone_attach.sh script.

The second line is a bit different and maybe not as intuitive. It is watching for the dev file of your iphone to disappear (/dev/iphone) which happens as soon as you unplug it. Then it runs the iphone_remove.sh script. That’s it, you’re done.

other stuff

One annoyance I ran into was Nautilus trying to automount the phone as a camera. I was unable to tell it to ignore the iPhone, so I just turned off automount completely in Nautilus using gconf-editor.

$ gconf-editor

(uncheck: apps > nautilus > preferences > media_automount)

Another idea I had to use the suspend/resume functionality instead of stopping/starting the VM. However, I found that on resume the VM wouldn’t properly sync with the phone until Windows rebooted, even after using the VBoxManage commands to disconnect/reconnect the phone.

In the future, I’d like to look into reducing the XP install size with something like nLite and using dropbox to move the VM to the cloud. The ultimate goal would be to have the ability to sync my phone from home, work, or my laptop while travelling. I have some ideas on the way to approach this but it’s not a burning need at the moment. It would be really cool though.

Jaunty

Unfortunately I noticed the iphone_remove.sh script was no longer triggering after I upgraded to Jaunty. So I figured out another way to configure udev. First, we need to come up with another identifier to use in the udev rule:

udevadm monitor –environment

While that command is running in the background, plug in your phone, one of the lines should look like this:

PRODUCT=5ac/1292/1

Copy this line. I’m not sure if the same ID applies to the original and 3G phones, so run this for yourself. Then we can create the udev rule.

vi /etc/udev/rules.d/98-iphone.rules

You may need to change the Product ID here if it differs from mine, and change the path to your script:

SUBSYSTEM==”usb”, ENV{PRODUCT}==”5ac/1292/1″, ACTION==”add”, RUN+=”/home/nathan/scripts/iphone_attach.sh”
SUBSYSTEM==”usb”, ENV{PRODUCT}==”5ac/1292/1″, ACTION==”remove”, RUN+=”/home/nathan/scripts/iphone_remove.sh”

And that’s it. This may actually be the proper way to configure the rules in Intrepid, but I no longer have a 0810 system to test on.

]]> http://akedemo.wordpress.com/2009/04/17/hacker-may-get-root-through-udev-bug/ Fri, 17 Apr 2009 16:55:18 +0000 akedemo http://akedemo.wordpress.com/2009/04/17/hacker-may-get-root-through-udev-bug/ http://razorvine.wordpress.com/2009/04/13/colinux-upgrade-woes/ Mon, 13 Apr 2009 12:37:37 +0000 razorvine http://razorvine.wordpress.com/2009/04/13/colinux-upgrade-woes/

I just upgraded from colinux 0.7.3 to 0.7.4. The upgrade went smoothly, but udev screwed up my network interfaces on the next boot.

udev: renamed network interface eth1 to eth2
udev: renamed network interface eth0_rename to eth1

Apparently, the upgrade changed the MAC address of my TAP adapter. To solve the issue, i edited udev’s rules file:

diakonos  /etc/udev/rules.d/70-persistent-net.rules

# PCI device 0x10ec:0x8029 (ne2k-pci)
#Comment out old rule
#SUBSYSTEM=="net", DRIVERS=="?*", ATTR{address}=="52:54:00:12:34:56", NAME="eth0"

# PCI device 0x1a55:0x0005 (conet)
#adjust NAMEs in new rules
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="00:ff:7d:99:00:00",
 ATTR{type}=="1", KERNEL=="eth*", NAME="eth0"

# PCI device 0x1a55:0x0005 (conet)
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="00:ff:e1:57:98:e0",
 ATTR{type}=="1", KERNEL=="eth*", NAME="eth1"