UDEV per kernel 2.6: nozioni fondamentali

1.Introduzione

Sono successe diverse cose emozionanti dall'uscita di UDEV. La sua maturazione ha reso possibile l'avere sistemi puramente udev. Alcune periferiche non sono ancora state portate su sysfs e necessitano quindi di soluzioni alternative per farle funzionare. Altrimenti si può scegliere tra due soluzioni alternative:

• usare un sistema puramente udev e fare uso di workaround per le periferiche che hanno problemi, o
• usare la configurazione predefinita di Gentoo che usa un file devices.tar.bz2 per popolare /dev.

Nella sezione setup si daranno maggiori dettagli su queste opzioni.

L'informazione più recente è che si sono ancora circa 162 periferiche gestite dal kernel che devono essere importate in sysfs. Per questo si dovranno ancora usare delle soluzioni alternative per queste periferiche. Il mio scanner solo recentemente ha iniziato a funzionare con udev (viene visto come un usbcam, ma funziona). Al momento tutte le mie periferiche funzionano.

Se avete già UDEV installato e funzionante potreste voler leggere la "DSD's Guide on Writing UDev Rules". Il cui link si trova di seguito.

Ancora un piccolo preliminare. Cosa succederà ai kernel 2.6 con DevFs?

Direttamente dalla sorgente: da notare che devfs è stato reso obsoleto da udev, http://www.kernel.org/pub/linux/utils/kernel/hotplug/. L'uso di DevFs è stato ridotto al minimo e viene previsto solo per quelle installazioni che usano il suo schema si nomenclature che sfortunatamente differisce dai nomi che usano normalmente le installazioni di Linux.

2.Modifiche recenti a questo documento

• Traduzione in giapponese: uno speciale ringraziamento a Masanao Igarashi per aver tradotto UDEV Primer in giapponese. L'URL è nella sezione dedicata ai link. Se il link non è funzionante al momento lo sarà presto.
• Permessi: qualcosa da notare dai changelog in Udev-051: si prega inoltre di notare che i file .permissions non esistono più! Se ne avevate di personalizzati, occorrerà riportare la loro logica nei file .rules (sennò si avrà accesso alle periferiche solo come utente root che per quanto riguarda la sicurezza non è la strategia migliore...)
• Se si usa genkernel si tenga conto che lo script linuxrc per genkernel non usa gentoo=nodevfs come si farebbe per kernel manuali. Se si vuole usare UDEV con genkernel si dovrà aggiungere il parametro udev nel file di configurazione di Grub, o se si usa Lilo, aggiungerlo ad una linea append per renderlo attivo. Grazie a Dominic Battre per questa informazione e ricerca.
• Sysfsutils: è stato notificato che sysfsutils è divenuto una dipendenza per udev. Viene ora provveduto con la propria copia di libsysfs. Non occorre più fare anche un emerge sysfsutils.
• Flash drive: Chris ha scritto un nuovo tutorial su come configurare Flash Drive (penne, etc.) con UDEV. Per ora usando una configurazione per una singola partizione. E' comunque in ampliamento.
• Misc Device: un paio di aggiornamenti per le informazioni sul Palm Pilot con Udev da Chris.
• Chris Atkinson ha scritto un eccellente tutorial su come usare UDEV con un Palm Pilot. Vedere il link Misc Devices.
• Se qualcuno ha problemi con qualche periferica e mi può dire come fare per farla funzionare con chiarezza, sarò felice di includerla nel Primer.

3.Cos'è UDEV

In poche parole UDEV è una sostituzione di DEVFS in user-space usando sysfs e /sbin/hotplug. UDEV crea e rimuove voci in /dev in base alla configurazione corrente del sistema. Fa questo in base agli eventi di /sbin/hotplug nel sistema e leggendo informazione circa questi eventi da sysfs.

UDEV lavora interamente nello user-space (NdT: spazio utente) usando chiamate /sbin/hotplug fatte dal kernel ogni qualvolta una periferica viene aggiunta o rimossa dal kernel. Tutta la politica della nomenclatura e il controllo dei permessi viene fatto in user-space.

Per maggiori informazioni si possono leggere le FAQ di Udev.

4.Configurazione di Udev

Probabilmente la prima domanda sarà: come fare ad iniziare ad usare udev?

Non è realmente difficile a meno che non si sia mai compilato un kernel, che naturalmente esula dallo scopo di questo tutorial.

Passi per configurare Udev 

Come menzionato precedentemente, ci sarà bisogno di installare e configurare un kernel della serie 2.6. La scelta migliore per i kernel da usare adesso sono: >mm-sources-2.6.1-mm3 (proprio adesso sto usando il kernel 2.6.4-gentoo-r1) o >gentoo-dev-sources-2.6.1 o >development-sources-2.6.2. Notare il simbolo di maggiore (>), il che significa che si deve scaricare la versione più recente del kernel cui si fa riferimento. Udev funzionerà anche con kernel minori, ma dato che sono state fatte delle migliorie si avranno maggiori probabilità di successo installando un kernel più nuovo. Le parti più importanti della configurazione sono mostrate di seguito.

Alcune note da considerare:

• Se si vuole, si può ancora compilare il kernel col supporto di DEVFS e scegliere quale usare all'avvio del sistema, per questo non si pensi che non si possa compilare devfs nel kernel per usare udev. Si veda la sezione su come editare i file di configurazione di Lilo o Grub per maggiori dettagli.
• Se per qualche ragione non si vede una delle opzioni del kernel come mostrato sotto durante la configurazione del vostro kernel, continuate la lettura, alcuni kernel possono differire.
• Potrebbe sembrare che se si vuole usare initrd,che io non uso, si debba avere o il tarball o compilare il kernel col supporto per Devfs altrimenti si ha un errore del tipo 'devfs not mounting on /dev'. Questo non significa che si debba usarlo, basta averlo compilato nel kernel.
• Se si sta usando genkernel, considerate l'uso della versione 3.0.2f che è stata configurata per funzionare con Udev. Compilare il genkernel con l'opzione --udev. Per esempio: genkernel --save-config --menuconfig --udev all
• Durante la configurazione dei bootloader Lilo o Grub non dimenticare di usare udev invece di gentoo=nodevfs, che viene usata con kernel compilati 'a mano'. Vedere la sezione relativa ai bootloader per qualche esempio.

A parte le opzione del kernel e il bootloader, il resto di questo documento si dovrebbe applicare a tutte le esigenze.

Configurazione del kernel 

Figura 1: Udev kernel configuration

Figura 2: Udev kernel configuration

Ci sono alcune opzioni che non si vedono durante la configurazione del kernel usando menuconfig ma che si possono impostare editando direttamente il file .config. Se si vuole controllare il file, ecco cosa dovreste vedere. In alcuni kernel CONFIG_HOTPLUG potrebbe apparire da qualche altra parte, come in General Setup. Potreste usare grep per cercarlo nel file .config e tornare al menuconfig per impostarlo.

      # Bus options (PCI, PCMCIA, EISA, MCA, ISA)
      #
      CONFIG_HOTPLUG=y
      #
      # File systems
      #
      # Pseudo filesystems
      #
      CONFIG_PROC_FS=y
      CONFIG_PROC_KCORE=y
      CONFIG_SYSFS=y
      # CONFIG_DEVFS_FS is not set   <--- Se si imposta a 'Y' si dovrà aggiungere gentoo=nodevfs al bootloader per avviare con udev.
      CONFIG_DEVPTS_FS=y                  Non impostare Devfs per essere caricaro in modo automatico all'avvio!!!
      # CONFIG_DEVPTS_FS_XATTR is not set           Come per il kernel 2.6.4 l'opzione DEVPTS_FS non è disponibile. Abilitarla nel kernel.
      CONFIG_TMPFS=y
      # CONFIG_HUGETLBFS is not set
      # CONFIG_HUGETLB_PAGE is not set
      CONFIG_RAMFS=y

Se si vuole, si può ancora compilare DEVFS (CONFIG_DEVFS_FS) nel kernel, ma ricordate l'avvertimento dato in precedenza. Se si usa anche DEVFS, ci sono alcune opzioni di avvio per lilo o grub che verranno menzionate tra breve, dove sarà possibile attivare o meno DEVFS o UDEV.

Se si sta usando un sistema udev nativo (p.e. non usando devices.tar.bz2) nessuna modifica verrà salvata dato che la creazione dei dispositivi di periferiche è dinamica. Se si vogliono fare delle modifiche ai dispositivi di periferica in udev, si dovrà agire sul file /etc/udev/rules.d/10-local.rules. Si dovrà creare questo file, non si dovrà editare il file 50-udev.rules dato che contiene le regole predefinite. E' possibile aggiungere le proprie regole creando il file 10-local.rules. Non si dovranno creare regole proprie per molti sistemi. Se si ha necessità, creare le proprie regole dove menzionato.

Installare udev 

Installare almeno la versione 024-r1 di udev, dato che versioni precedenti non funzionano e si potrebbero incontrare molti problemi. Sempre meglio usare l'ultima versione. Dato che Udev dipende da hotplug, occorre installare anche questo pacchetto, se non viene installato direttamente dall'ebuild di udev e anche se non vi serve.

# emerge udev
 se il comando precedente non installa anche hotplug eseguire anche
il prossimo emerge
# emerge hotplug

Configurazione di hotplug 

Aggiungere hotplug al run-level.

# rc-update add hotplug boot

Si potrebbe controllare di non avere già configurato hotplug per il run-level di default.

# rc-update -s
oppure
# rc-update show

Questi comandi dovrebbero mostrare qualcosa come segue:

bash-2.05b# rc-update -s
                  alsasound | boot
                     hdparm |      default
                   hostname | boot
                    hotplug | boot

Se si ha hotplug nel run-level di default occorre rimuoverlo e porlo in boot.

# rc-update del hotplug default
# rc-update add hotplug boot

La directory sys 

Gentoo crea ora una directory /sys in root per montarvi il sysfs. Questo avviene almeno per le nuove installazioni, o anche dopo il cambio da devfs a udev. Controllare comunque che esista tale directory altrimenti crearla a mano con mkdir /sys.

fstab 

Gentoo è ora in grado di montare defpts e sys. Non ci sarà necessità di aggiungere voci in /etc/fstab. Sarà lo script /sbin/rc a gestire tutto ora. Lo si può controllare con df -a. Non abbiamo dato nessuna indicazione di inserire delle voci in /etc/fstab, ma se lo si è fatto converrebbe rimuoverle. Se si hanno problemi di montaggio con devpts o sys e non si riesce ad aprire una console, probabilmente si dovranno controllare altre cause.

Si potrebbe pensare a questo punto di avere udev, sysfs e hotplug installati e pronti per funzionare. Purtroppo non è così. Finché sysfs non è montato, /dev non è montato in ramfs e hotplug non è partito, non si può realmente fare niente. Si vedranno modifiche in /sys se si aggiungono o rimuovono periferiche, ma il sistema non farà niente con queste informazioni.

Aggiornare baselayout 

A questo punto è necessario il nuovo baselayout. Questo pacchetto contiene gli script init necessari per far partire il tutto.

# emerge baselayout

La prima versione funzionante è baselayout-1.8.6.13, dove non c'è bisogno di modificare halt.sh e /sbin/rc. Dato che udev è in continua evoluzione, si consiglia di usare almeno questa o una più recente. Anche se la versione summenzionata ha gli init script necessari...si usi comunque la versione più recente.

Un file che si può notare è in /lib/udev-state e si chiama devices.tar.bz2. Questo è dove viene salvato lo stato corrente di /dev da ramfs durante uno spegnimento del sistema e da dove verrà ricreato /dev al riavvio successivo.

Salvare lo stato di /dev non va contro lo scopo di UDEV? Si suppone che UDEV sia un filesystem dinamico che crea solo i dispositivi di periferica presenti nel sistema e solo quando necessario, per esempio se il vostro scanner non è connesso non avete bisogno del dispositivo e quindi non dovrebbe essere creato. Dopo la connessione, udev dovrebbe creare il dispositivo. Se lo stato di /dev viene salvato, il dispositivo sarà presente anche se non è connesso. La ragione per farlo è stato perché all'inizio solo i dispositivi basilari necessari sono stati creati da Udev. Dispositivi a blocchi (dischi), tty,... UDEV ha fatto molta strada ora e possiede molte delle funzionalità di cui si necessita. Così è possibile ora utilizzare un sistema puramente udev. Sussitono comunque alcuni problemi, ma ci sono soluzioni alternative per loro.

Un giorno nel futuro di Gentoo probabilmente verrà rimosso il file devices.tar.bz2, quando udev sarà ancor più avanzato. Si guarderà a come udev si avvicinerà a questo successo.

Ci si assicuri di porre i nuovi file di configurazione necessari per l'aggiornamento eseguendo etc-update. Altrimenti non verrà salvato lo stato corrente di /dev in /lib/udev-state/devices/devices.tar.bz2. E anche se non si sta programmando di usare devices.tar.bz2 e si vuole usare un sistema puramente udev, non si avranno gli script necessari al posto giusto per usare udev.

Editare gli script 

Se si è soddisfatti di come funzionano gli script predefiniti di Gentoo, si può saltare questa sezione. Per eseguire un sistema puramente udev editare i seguenti due script.

Usando baselayout-1.8.6.13-r1 ci sarà solo bisogno di editare /etc/conf.d/rc invece dei due script suddetti. Ecco alcune parti rilevanti (con i parametri predefiniti):

      # Set to "yes" if you want to save /dev to a tarball on shutdown
      # and restore it on startup. This is useful if you have a lot of
      # custom device nodes that udev do not handle/know about.
      # (ONLY used by UDEV enabled systems!)

      RC_DEVICE_TARBALL="yes"

      # Set to "yes" if you want devfsd to start upon bootup. This is
      # the default for Gentoo.
      # Set to "no" only if you understand the full implications. A
      # number of files may need to be altered (i.e. /etc/inittab,
      # /etc/fstab, etc.).
      # Also note that it does _NOT_ start for UDEV enabled systems,
      # even if RC_DEVFSD_STARTUP="yes" ...

      RC_DEVFSD_STARTUP="yes"

Dopo molte prove ed errori, questo è il modo di impostare queste opzioni.

Nota: non usare 'devfs=nomount' nel bootloader, /sbin/rc non controlla questa opzione, vengono controllate solo 'gentoo=nodevfs' o 'gentoo=noudev'

Questa è la configurazione predefinita. Si può ancora avviare a Devfs o Udev. A seconda della configurazione del kernel, si abbiano le opzioni appropriate mostrate sotto per lilo o grub (p.e. gentoo=noudev o dentoo=nodevfs).

      RC_DEVICE_TARBALL="yes"
      RC_DEVFSD_STARTUP="yes"

La prossima configurazione NON usa il tarbal (devices.tar.bz2), ma è ancora possibile avviare a Devfs se si desidera. A seconda della configurazione del kernel si abbiano le opzioni appropriate mostrate sotto per lilo o grub (p.e. gentoo=noudev o gentoo=nodevfs)

      RC_DEVICE_TARBALL="no"
      RC_DEVFSD_STARTUP="yes"

Con la prossima configurazione si PUO' usare o NON usare il tarball (devices.tar.bz2). Ma non sarà possibile avviare a Devfs!

      RC_DEVICE_TARBALL="yes"
      RC_DEVFSD_STARTUP="no"

      RC_DEVICE_TARBALL="no"
      RC_DEVFSD_STARTUP="no"

Versioni vecchie di baselayout (<1.8.6.13-r1) 

/etc/init.d/halt.sh

Scommentando le righe di questo file che iniziano per ## (come root), si bloccherà il salvataggio dello stato di /dev nel file devices.tar.bz2 quando si fa lo shutdown del sistema. Questa parte dello script dove viene salvato lo stato di /dev è all'inizio di halt.sh.

      # We need to properly terminate devfsd to save the permissions
      if [ -n "`ps --no-heading -C 'devfsd'`" ]
      then
              ebegin "Stopping devfsd"
              killall -15 devfsd &>/dev/null
              eend $?
      elif [ ! -e /dev/.devfsd -a -e /dev/.udev ]
      then
              ebegin "Saving device nodes"
              ##cd /dev
              ##try tar -jclpf "/tmp/devices-$$.tar.bz2" *
              ##try mv -f "/tmp/devices-$$.tar.bz2" /lib/udev-state/devices.tar.bz2
              eend 0
      fi

/sbin/rc

C'è solo una riga in questo file da scommentare (come root) sempre preceduta da ##. Questo previene /sbin/rc dal popolare /dev col contenuto di devices.tar.bz2 al momento dell'avvio del sistema.

      # Fix weird bug where there is a /dev/.devfsd in a unmounted /dev
      mymounts="$(awk '($3 == "devfs") { print "yes"; exit 0 }' /proc/mounts)"
      if [ -e "/dev/.devfsd" -a "${mymounts}" != "yes" ]
      then
              rm -f /dev/.devfsd
      fi

      if [ "${udev}" = "yes" ]
      then
              ebegin "Mounting ramfs at /dev"
              try mount -n -t ramfs none /dev
              eend $?
              ebegin "Configuring system to use udev"
              einfo " Populating /dev with device nodes..."
              ##try tar -jxpf /lib/udev-state/devices.tar.bz2 -C /dev
              populate_udev
              if [ -e /proc/sys/kernel/hotplug -a -x /sbin/hotplug ]
              then
                      einfo " Using /sbin/hotplug for udev management..."

              elif [ -e /proc/sys/kernel/hotplug ]
              then
                      einfo " Setting /sbin/udev as hotplug agent..."
                      echo "/sbin/udev" > /proc/sys/kernel/hotplug
              else
                      ewarn " Kernel was not compiled with hotplug support!"
              fi
              eend 0
              # Create problematic directories
              mkdir -p /dev/{pts,shm}
              # Same thing as /dev/.devfsd
              touch /dev/.udev

Device console e null 

Se questa è una nuova installazione e si sta configurando il sistema per usare UDEV esclusivamente, o quando si riavvia dopo l'installazione, la configurazone di udev è corretta e si ha un errore come: "WARNING: Unable to open an initial console". Il problema risiede nel fatto che non esistono né /dev/console e né /dev/null. Quello che succede è che /dev/console è necessaria prima che udev popoli la directory /dev. Si può provare questo rimuovendo manualmente tutti i dispositivi di periferica statici da /dev da un altro sistema e quindi riavviando il sistema in udev. Si avrà l'errore suddetto e si noterà inoltre che l'errore avviene al momento del normale caricamento di udev. Se si crea /dev/console il sistema andrà in errore a causa di /dev/null. Per cui saranno necessarie entrambe i dispositivi statici in /dev, almeno all'inizio. Per correggere l'errore momentaneamente occorre crearle manualmente in /dev.

# cd /dev
# mknod -m 660 console c 5 1
# mknod -m 660 null c 1 3

Questi comandi creeranno /dev/console e /dev/null staticamente nella directory /dev.

Driver NVIDIA 

I pacchetti suddetti funzionano con udev/sysfs. Queste versioni non sembrano disponibili adesso. Qualsiasi versione 5336 dovrebbe funzionare. Io sto usando nvidia-kernel-1.0.5336-r4 e nvidia-glx-1.0.5336-r2. Se si usano le stesse si riuscirà a avviare una sessione X. Queste versioni sono marcate come masked e non appaiono come stabili anche se io non ho avuto nessun problema. Se non si vuole o non si possono usare queste versioni, si può leggere la parte relativa ai problemi con i dispositivi per vedere come procedere.

Se si hanno problemi di creazione dei dispositivi nvidia in /dev anche usando i driver corretti, vedere i problemi relativi ai dispositivi di seguito. Accertarsi comunque di aver posto la voce nvidia nel file /etc/modules.autoload.d/kernel-2.6 in modo da far caricare il driver all'avvio del sistema. Se così non fosse, il device nvidia non verrebbe creato. Utilizzare il comando lsmod per vedere se il modulo è stato caricato.

Lilo e Grub 

Questa dovrebbe essere l'ultima cosa da editare. (vedere problemi con i dispositivi di seguito prima di riavviare).

Se non si è compilato il supporto DEVFS nel kernel non c'è altro da aggiungere ai bootloader. Se invece si è compilato il supporto DEVFS nel kernel (si è selezionato il montaggio automatico di devfs all'avvio? Ricompilare il kernel senza questa opzione.) c'è bisogno di prendere un paio di decisioni. Gentoo vorrà caricare devfs all'avvio se compilato nel kernel anche se si ha udev. Pertanto ci sono un paio di opzioni:

• Opzione 1: non caricare devfs e usare udev: aggiungere gentoo=nodevfs
• Opzione 2: non caricare udev e usare devfs: aggiungere gentoo=noudev
• Opzione 3: avere due opzioni in grub o lilo che permettano l'avvio dello stesso kernel, che caricando udev o devfs: aggiungere due opzioni di avvio a lilo o grub. Una con i parametri dell'opzione 1 e l'altra con quelli dell'opzione 2
• Genkernel opzione 1: non caricare devfs e usare udev: aggiungere udev
• Genkernel opzione 2: non caricare udev e usare devfs: aggiungere devfs

Opzione 1: non caricare devfs e usare udev
      # Udev system mm1 2.6.3 kernel
           image ="/boot/bzImage-2.6.3-rc1-mm1"
           root="/dev/hdb2"
           label="GentooUDEV"
           append = "gentoo=nodevfs ide0=ata66 ide1=ata66 hdc=ide-cd"
           read-only

Opzione 2: non caricare udev e usare devfs
      # Devfs system mm1 2.6.3 kernel
           image ="/boot/bzImage-2.6.3-rc1-mm1"
           root="/dev/hdb2"
           label="GentooDEVFS"
           append = "gentoo=noudev ide0=ata66 ide1=ata66 hdc=ide-cd"
           read-only

Opzione 3: scegliere cosa usare all'avvio
      # Udev system mm1 2.6.3 kernel
           image ="/boot/bzImage-2.6.3-rc1-mm1"
           root="/dev/hdb2"
           label="GentooUDEV"
           append = "gentoo=nodevfs ide0=ata66 ide1=ata66 hdc=ide-cd"
           read-only
      # Devfs system mm1 2.6.3 kernel
           image ="/boot/bzImage-2.6.3-rc1-mm1"
           root="/dev/hdb2"
           label="GentooDEVFS"
           append = "gentoo=noudev ide0=ata66 ide1=ata66 hdc=ide-cd"
           read-only

Genkernel opzione 1: non caricare devfs e usare udev
      # Udev system kernel-2.6.10
           image="/boot/kernel-2.6.10-gentoo-r6"
           root="/dev/ram0"
           label="GenKernel-2.6.10"
           append="udev init=/linuxrc real_root=/dev/hda4 video=vesafb:ywrap,vga=0x31B"
           initrd="/boot/initrd-2.6.10-gentoo-r6"

Genkernel opzione 2: non caricare udev e  usare devfs
      # Devfs system kernel-2.6.10
           image="/boot/kernel-2.6.10-gentoo-r6"
           root="/dev/ram0"
           label="GenKernel-2.6.10"
           append="devfs init=/linuxrc real_root=/dev/hda4 video=vesafb:ywrap,vga=0x31B"
           initrd="/boot/initrd-2.6.10-gentoo-r6"

Opzione 1: non caricare devfs e usare udev
      title=Gentoo UDEV
      root (hd0,0)
      kernel (hd0,0)/bzImage-2.6.3-rc1-mm1 root=/dev/hda3 gentoo=nodevfs

Un altro esempio
      title=Gentoo Main
      root (hd0,5)
      kernel /bzImage-2.6.4-gentoo-r1 root=/dev/hda7 gentoo=nodevfs hdc=ide-cd ide0=ata66 ide1=ata66 vga=791

Se non si è compilato il supporto DEVFS nel kernel e si vuole farlo in seguito, ricompilare il kernel col supporto DEVFS. Quindi rieditare il bootloader ed aggiungere le modifiche appropriate come visto in precedenza usando una delle opzioni previste. Non è possibile usare udev o devfs allo stesso tempo. Per l'ennesima volta: non compilare il montaggio automatico dei devfs all'avvio!! (Questo è l'ultimo avviso.)

5.Problemi relativi ai dispositivi

Per prima cosa controllare prima in /var/log/error_log_files che può contenere utili tracce per risalire al problema.

Editare il file devices.tar.bz2: alcuni optano per usare l'installazione predefinita di udev in Gentoo e modificano semplicemente il proprio devices.tar.bz2 affinché contenga solo i dispositivi di cui necessitano e che non sono stati creati da udev. Si può far questo per i dispositivi come console e null e/o altri. Un modo semplice è usando Ark anche se ci sono altri modi grafici o da linea di comando. Io ho mosso semplicemente devices.tar.bz2 in una directory temporanea. Dopo averlo scorso ho selezionato tutto eccetto console e null e ho rimosso la selezione. Ho salvato il file. Ricontrollando ho verificato che ci fossere solo i due dispositivi. Quindi si può sostituire il vecchio devices.tar.bz2 con il nuovo. Se si segue questa strategia, assicurarsi solo di non editare gli script affinché non usino il tarball. Volendo usare il tarball si dovrebbe lasciare la variabile RC_DEVICE_TARBALL="yes".

Driver NVIDIA 

I driver Nvidia nvidia-kernel-1.0.5336-r1 e nvidia-glx-1.0.5336-r1 funzionanto con udev/sysfs. Queste versioni non sembrano disponibili al momento. Qualsiasi versione 5336 dovrebbe funzionare. Io sto usando nvidia-kernel-1.0.5336-r4 e nvidia-glx-1.0.5336-r2. A proposito, questa è la procedura standard per includere i moduli nvidia in /etc/modules.autoload.d/vostro_kernel. Così, se si sta usando i driver nvidia summenzionati e X non parte perché non c'è alcun /dev/nvidia#, ci si assicuri di aver aggiunto il modulo per il caricamento automatico all'avvio insieme agli altri moduli. Se non si vuole o non si possono usare queste versioni, ecco cosa fare.

Per ora si dovrebbero creare manualmente i dispositivi nvidia# e nvidiactl in /dev. Un modo per farlo è aggiungerli nel proprio file /etc/conf.d/local.start, in questo modo:

      mknod -m 660 /dev/nvidia0 c 195 0
      mknod -m 660 /dev/nvidia1 c 195 1
      mknod -m 660 /dev/nvidiactl c 195 255

Gli utenti Debian non hanno un file local.start, ma possono aggiungere i dispositivi non creati in /etc/udev/links.conf. Se si sta usando Debian si aggiungano le seguenti righe a links.conf:

            M nvidia0 c 195 0
            M nvidia1 c 195 1
            M nvidiactl c 195 255

L'opzione M crea i nodi dei dispositivi usando /sbin/MAKEDEV

Se non si è sicuri di quanti dispositivi si necessita, crearne almeno due per non avere problemi ricordando di cambiare i numeri minor e major affinché corrispondano. Quando udev parte mettendo i driver nvidia in /dev o si è scelto di usare i primi driver menzionati, e si otterrà un errore all'avvio che avverte che i dispositivi esistono già, è il momento di rimuovere le linee.

Se si sono installati i driver nvidia-kernel-1.0.5336-r1.ebuild e glx (qualsiasi driver versione 5336 dovrebbe funzionare) e si ottiene questo errore all'avvio: "Error: API mismatch: the NVIDIA kernel module is version 1.0.4480, but this X module is version 1.0.5336.". Assicurarsi che il modulo del kernel e tutti i driver NVIDIA abbiano lo stesso driver.

La soluzione sta nel guardare la propria directory /lib/modules/your_kernel/video e assicurarsi di averci un solo driver per nvidia. Questo dovrebbe essere etichettato nvidia.ko se si è installata la versione 1.0.5336-r1 (or qualsiasi versione 5336). Se ve ne sono altri (chiamati probabilmente nvidia.o), rimuoverli, se non funziona, disintallare i driver nvidia e reinstllare solo la versione 1.0.5336-r1 (o ogni altra versione 5336).

Se si sta pianificando di fare avanti e indietro tra Devfs e Udev, la prima volta che si riparte usando Devfs si dovranno ricaricare nvidia-kernel e nvidia-glx. Emergere nvidia-kernel non ha creato i dispositivi per me e ho dovuto usare mknod.

Dispositivi Nvidia/Alsa 

A partire da udev-021 c'è un nuovo programma /sbin/udevstart. Se non si sono usate versioni con questo nuovo programma prima di aver installato udev-023-r1, si sarà incorsi nel problema relativo a Nvidia/Alsa con nessuna periferica Nvidia e solo un dispositivo alsa (/dev/snd/controlC0) creato. Così, se si è installata la versione 021 e ci si trova il sistema avviato col login da linea di comando e senza X, si esegua da root: /sbin/udevstart. Questo comando creerà i dispositivi e si potrà uscire dal login, rientrare come utente ed eseguire: startx. Questo è un problema dei pacchetti nvidia e alsa e non di udev.

Si noti che i dispositivi per periferiche NVIDIA (usando la versione corrente: nvidia-kernel-1.0.5336-r4) che non vengono creati non è più un problema. Sembra essere, invece, un problema legato ad una sincronizzazione. L'errore che si può trovare nel file XFree86.0.log è: "NVIDIA(0): Failed to initialize the nvidia kernel module!" e naturalmente non parte la sessione X. Controllando però in /dev si trova che i dispositivi NVIDIA sono stati creati correttamente. Non eseguire ancora udevstart, se X continua a non partire anche dopo un riavvio, ma è possibile eseguire un login e con startx parte la sessione X, occorre aggiungere un comando sleep al file local.start. Ci possono essere svariate cose nel file /etc/conf.d/local.start cosicché il tempo di attesa (sleep) può variare. Proprio ora ho aggiunto uno sleep 3 al mio local.start e funziona. Provando una valore più basso la sessione X non partiva. Provare incrementando il numero finché tutto funziona.

      sleep X

      Dove X è il numero di secondi di attesa

Dispositivi mixer/midi/dsp 

Alcune persone, me incluso, riportano che i dispositivi /dev/mixer, /dev/midi o /dev/dsp non vengono creati, Il problema non è di udev. Se si compila il supporto per i suddetti dispositivi come modulo devono essere inclusi in /etc/nodules.autoload.d/kernel-2.6. Così, se questi dispositivi non vengono creati, aggiungere: snd_pcm_oss & snd_seq_oss al file kernel-2.6. Il modulo snd_pcm_oss caricherà snd_mixer_oss.

      snd_mixer_oss è l'alias di /dev/mixer
      snd_pcm_oss è l'alias di /dev/dsp
      snd_seq_oss è l'alias di /dev/midi

Dispositivi PPP 

Questo è uno dei dispositivi che devono ancora essere importati in sysfs, per questo non è possibile scrivere delle regole di udev per la loro creazione. Se si necessita di /dev/ppp occorre crearlo manualmente. Si dovrà aggiungere la sua creazione nel file local.start come per la periferica nvidia. Qualcuno ha modificato il tarball per contenere i dispositivi necessari che non vengono creati automaticamente. Se si opta per l'aggiunta al file /etc/conf.d/local.start, aggiungervi la seguente linea:

      mknod -m 660 /dev/ppp c 108 0

Gli utenti di Debian non hanno un file local.start, ma possono aggiungere le periferiche che non vengono create in /etc/udev/links.conf. Così se si è utenti Debian, aggiungere a links.conf:

            M ppp c 108 0

Il parametro M crea i nodi dei dispositivi usando /sbin/MAKEDEV

Mouse 

Se il mouse non funziona non è un problema legato a udev ma a come è stato configurato in passato. Udev (in questo momento) ha quattro dispositivi che possono essere usati per il mouse.

• /dev/input/mice
• /dev/input/mouse0 (ci potranno essere mouse1, mouse2,.. se si hanno più di un mouse, ma mouse0 è per il primo mouse)
• /dev/misc/psaux (che ha un link simbolico con /dev/psaux)

Così qualsiasi dispositivo si stia usando (mouse#, mice o psaux), ci si assicuri che i file /etc/X11/XF86Config-4 o XF86Config o xorg.conf siano configurati con la corretta ubicazione della periferica. Si potrebbe anche creare un proprio link simbolico attraverso il file /etc/udev/rules.d/10-local.rules, ma è consigliabile limitarsi ad editare i file XF86Config-4 o XF86Config.

6.Riavvio del sistema e altre cose

Si dovrebbe ora essere in grado di riavviare e testare il sistema con udev. All'avvio si dovrebbero vedere le seguenti righe:

      mounting sysfs at /sys
      mounting ramfs at /dev
      configuring system to use udev
        populating /dev with device nodes
        using /sbin/hotplug for udev management

Ci sono alcune cose prese dai forum da aggiungere:

• Setfont: se si vede un errore sul Setfont all'avvio, installare l'ultima versione di kbd: emerge -U kbd
• Udev-009: questa versione non si compila con sysfsutils-0.4.0. Ci sarà bisogno di fare un downgrade a sysfsutils-0.3.0, emergere udev-009, e reinstallare sysfsutils-0.4.0. E' stato riportato un bug per questo. Non dovrebbe essere più un problema, comunque, dato che si dovrebbe usare una versione di udev più nuova.
• Creazione dinamica di dispositivi: alcuni sono meravigliati circa la creazione dinamica di dispositivi che si suppone compia udev. Questo viene fatto popolando /dev con molti dispositivi. Ma non se ne vedrà la creazione neanche col modo che ha Gentoo di configurare UDEV. (Questo si applica solo a coloro che usano devices.tar.bz2).

7.Frammenti dalla guida su come scrivere regole UDEV

Seguono alcuni frammenti tratti dalla guida DSD su come scrivere regole per UDEV per far vedere la loro semplicità. Ho scelto una periferica che solo recentemente funziona con udev: il mio Microtek Scanner.

Ho scritto uno script in Python per mostrare informazioni di sysfs per tutti i dispositivi in /dev. Nella nuova versione ho aggiunto la possibilità di cercare in /sys per una periferica. Si può scaricare qui: udevread-0.3.tar. Per eseguirlo, basta estrarlo ed eseguire: python udecread.py --all per tutte le periferiche in /dev o python udevread.py --dev percorso_periferica. Per esempio: python udevread.py --dev input/mice. Suggerisco di aprire il terminale a schermo completo. Per vedere un esempio di output cliccare qui.

Senza udevread.py: prima occorre sapere che il dispositivo dello scanner in /dev è /dev/sg0. Usando tail -f /var/log/syslog con hotplug attivo si dovrebbe vedere qualcosa del genere:

Feb 25 09:16:17 decibels default.hotplug[18643]: arguments (scsi_generic) env (OLDPWD=/ DEVPATH=/class/scsi_generic/sg0 ...

Usando questa informazione ho cercato gli identificatori che non cambiano:

bash-2.05b# find | grep sg0
./class/scsi_generic/sg0
./class/scsi_generic/sg0/device
./class/scsi_generic/sg0/dev
./cdev/major/sg0

Basandosi su questo responso:

bash-2.05b# udevinfo -a -p /sys/class/scsi_generic/sg0

device '/sys/class/scsi_generic/sg0' has major:minor 21:0
  looking at class device '/sys/class/scsi_generic/sg0':
    SYSFS{dev}="21:0"

follow the class device's "device"
  looking at the device chain at '/sys/devices/platform/host0/0:0:0:0':
    BUS="scsi" <------ Scelto questo.
    ID="0:0:0:0"
    SYSFS{detach_state}="0"
    SYSFS{type}="6"
    SYSFS{device_blocked}="0"
    SYSFS{queue_depth}="1"
    SYSFS{scsi_level}="3"
    SYSFS{vendor}=" "
    SYSFS{model}="Scanner V6UPL   " <----- Scelto questo. Lo spazio è presente nel nome.
    SYSFS{rev}="1.00"
    SYSFS{online}="1"

  looking at the device chain at '/sys/devices/platform/host0':
    BUS=""
    ID="host0"
    SYSFS{detach_state}="0"

  looking at the device chain at '/sys/devices/platform':
    BUS=""
    ID="platform"
    SYSFS{detach_state}="0"

Con udevread.py: prima occorre sapere che il dispositivo dello scanner in /dev è /dev/sg0. Usando tail -f /var/log/syslog con hotplug attivo si dovrebbe vedere qualcosa del genere:

Feb 25 09:16:17 decibels default.hotplug[18643]: arguments (scsi_generic) env (OLDPWD=/ DEVPATH=/class/scsi_generic/sg0 ...

bash-2.05b$ python udevread.py --dev sg0
************ DEVICE NODE *************
-----------------------------
/dev/sg0
P: /class/scsi_generic/sg0
N: sg0
T: c
M: 020660
S: saranno mostrati alcuni link simbolici
O: root
G: disk
F: saranno mostrati file di regole
L: 0
U: 9650

Examining /sys for information on Device
looking at class device '/sys/class/scsi_generic/sg0':
SYSFS{dev}="21:0"

follow the class device's "device"
looking at the device chain at '/sys/devices/platform/host0/0:0:0:0':
BUS="scsi" <------ Scelto questo.
ID="0:0:0:0"
SYSFS{detach_state}="0"
SYSFS{device_blocked}="0"
SYSFS{model}="Scanner V6UPL   " <----- Scelto questo. Lo spazio fa parte del nome.
SYSFS{online}="1"
SYSFS{queue_depth}="1"
SYSFS{rev}="1.00"
SYSFS{scsi_level}="3"
SYSFS{type}="6"
SYSFS{vendor}=" "

looking at the device chain at '/sys/devices/platform/host0':
BUS=""
ID="host0"
SYSFS{detach_state}="0"

looking at the device chain at '/sys/devices/platform':
BUS=""
ID="platform"
SYSFS{detach_state}="0"

-----------------------------
*********** END DEVICE NODE ***********

I risultati sono simili, ma non c'è bisogno di cercare il percorso in /sys. In più si hanno maggiori informazioni dovendo usare due volte udevinfo per ottenere lo stesso risultato. Inoltre si può usare l'opzione --all per stampare lo stesso risultato per tutti i nodi dei dispositivi presenti in /dev.

Creazione della regola 

Si vedrà ora come mettere tutto insieme per creare una regola che oltre a creare un dispositivo per il mio scanner in /dev/sg0 lo chiamerà anche /dev/scanner.

Dove aggiungere le regole? In /etc/udev/udev-rules, /etc/udev/rules.d/50-udev.rules. 50-udev.rules è il default e DSD raccomanda di non editare questo file. Il file /etc/udev/udev.rules è obsoleto e non viene usato; lo si può rimuovere se si usa una versione aggiornata di udev. DSD consiglia di creare un nuovo file in /etc/udev/rules.d chiamato 10-local.rules per regole locali. Creare quindi un nuovo file in /etc/udev/rules.d chiamato 10-local.rules ed aggiungere ciò che segue (Non c'è bisogno di aggiungere gli spazi alla fine del nome del modello):

# Microtek Scanner
BUS="scsi", SYSFS{model}="Scanner V6UPL", NAME="%k", SYMLINK="scanner"

I so che il mio XSane backend è microtek2.conf in /etc/sane.d e controlla periferiche scsi, per questo aggiungervi /dev/scanner. Far partire due programmi per lo scanner. Entrambi mi permettono la scelta tra usare /dev/sg0 o /dev/scanner. Il tutto funziona perfettamente.

Qual è l'utilità di scrivere regole? In questo esempio non molto, è un esercizio per creare un link a /dev/sg0. Ma in altri casi si potrebbero avere molte periferiche e voler sapere a cosa corrispondono. In alcuni casi i link simbolici posso essere veramente di aiuto. Si veda l'esempio che segue. Leggere la Guida di DSD per maggiori dettagli.

DVD 

Io volevo usare i dvd e i vcd attraverso una periferica cdwriter/dvd reader combo. DSD contiene ottime informazioni su questa particolare periferica nel proprio howto. Udev crea un link /dev/cdroms/cdrom0 di default, ma può non creare /dev/dvd (che era il mio caso). In questo modo non potevo usare un dvd o un vcd. Inoltre non usavo l'emulazione scsi, preferendo hdc=ide-cd. Per risolvere il tutto, ho usato l'howto aggiungendo le seguenti righe al mio /etc/udev/rules.d/10-local.rules :

# cdrom/dvd devices
KERNEL="hdc", SYMLINK="dvd"

Questo ha creato un link /dev/dvd extra al mio /dev/hdc (ricordare: non c'è bisogno di riavviare il sistema, basta eseguire udevstart da linea di comando come root). In questo modo ho due link a /dev/hdc.

Fotocamere digitali 

Alcune fotocamere digitali necessitano di un dispositivo, altre no, Se la fotocamera usa un dispositivo scsi (p.e. /dev/sd# o /dev/sg#) si vedano le regole di DSD. Quelle che non richiedono un dispositivo richiedono qualche configurazione. La mia Kodak DX3215 richiede gphoto2 e può usare le gui gtkam o digikam. Viene mostrata in /sys ma non in /sys/class come un dispositivo. Ogni tentativo di avere un dispositivo di classe è miseramente fallito e nessuno dei test ha creato un nuovo dispositivo in /dev o ha trovato un riferimento alla periferica in /sys eccetto per il bus usb. Il solo problema erano i permessi, sia gtkam che digikam richiedono un piccolo lavoro da fare in /etc/hotplug/usb.usermap e di scegliere quale script si vuole usare come /etc/hotplug/usbcam e rendere usbcam eseguibile. gtkam funziona bene, ma con un errore che non può ottenere la lista del contenuto di '/', anche come root. digikam non dà errore.

8.Altre periferiche: Palm Pilot, flash drive, ...

Palm pilot, USB e udev: by Chris Atkinson 

Questa sezione descrive come configurare il supporto di un Palm Pilot USB per la sincronizzazione su un sistema udev puro.

Si assume che si abbia un sistema configurato appropriatamente per funzionare con il proprio Palm Pilot.

Il Palm Pilot esiste solo in sysfs dopo aver premuto il pulsante di HotSync e prima del completamento, cancellazione o termine della sincronizzazione. Questo significa che si dovrà premere il pulsante di sincronizzazione più volte prima di essere in grado di utilizzarlo.

Innanzitutto, collegare il supporto del Palm alla porta USB. Premere il pulsante di Hotsync sul supporto del Palm. Eseguire quindi dmesg.

Il risultato dovrebbe essere simile al seguente:

usb 2-1: new full speed USB device using address 2

Si deve ora scovare in sysfs questa nuova periferica USB. Provare in /sys/class/tty. Mentre l'hotsync è attivo, entrare nella directory /sys/class/tty e farne un listato come segue;

bash-2.05b# ls
console  tty12  tty19  tty25  tty31  tty38  tty44  tty50  tty57  tty63  ttyS3
ptmx     tty13  tty2   tty26  tty32  tty39  tty45  tty51  tty58  tty7   ttyS4
tty      tty14  tty20  tty27  tty33  tty4   tty46  tty52  tty59  tty8   ttyS5
tty0     tty15  tty21  tty28  tty34  tty40  tty47  tty53  tty6   tty9   ttyS6
tty1     tty16  tty22  tty29  tty35  tty41  tty48  tty54  tty60  ttyS0  ttyS7
tty10    tty17  tty23  tty3   tty36  tty42  tty49  tty55  tty61  ttyS1  ttyUSB0
tty11    tty18  tty24  tty30  tty37  tty43  tty5   tty56  tty62  ttyS2  ttyUSB1

La voce che interessa è l'ultima, ttyUSB1. (Entrambi i link USB vengono creati dal Palm Pilot, ma solo l'ultimo fa qualcosa e quindi non facciamo caso al ttyUSB0).

Comunque, è meglio fare un doppio controllo. Si aspetti finché l'hotsync è andato in timeout e quindi si riesegua il comando per fare il listato. Le due voci ttyUSB dovrebbero essere svanite.

Ora che si conoscono le voci in sysfs si userà udevinfo per avere la traccia dei dati necessari per creare la regola di udev, come segue:

bash-2.05b$ udevinfo -p /sys/class/tty/ttyUSB1 -a

One of the entries is of interest:

looking at the device chain at '/sys/devices/pci0000:00/0000:00:1d.0/usb2/2-1'                 :
    BUS="usb"
    ID="2-1"
    SYSFS{bConfigurationValue}="1"
    SYSFS{bDeviceClass}="00"
    SYSFS{bDeviceProtocol}="00"
    SYSFS{bDeviceSubClass}="00"
    SYSFS{bMaxPower}="  2mA"
    SYSFS{bNumConfigurations}="1"
    SYSFS{bNumInterfaces}=" 1"
    SYSFS{bcdDevice}="0100"
    SYSFS{bmAttributes}="c0"
    SYSFS{detach_state}="0"
    SYSFS{devnum}="4"
    SYSFS{idProduct}="0001"
    SYSFS{idVendor}="0830"
    SYSFS{manufacturer}="Palm, Inc."
    SYSFS{maxchild}="0"
    SYSFS{product}="Palm Handheld"
    SYSFS{serial}="123456789ABC"
    SYSFS{speed}="12"
    SYSFS{version}=" 1.00"

Con queste informazioni si può creare la regola di udev nel file /etc/udev/rules.d/10-udev.rules che creerà un nuovo dispositivo in /dev per il Palm Pilot. Ci sono svariati modi per farlo, quello che uso io è il seguente:

#Chris Palm Pilot

BUS="usb", SYSFS{serial}="123456789ABC", NAME="pilot"

Ci saranno ora da sistemare i permessi per il nuovo dipositivo. Dato che la procedura migliore è di lasciare la configurazione predefinita del file /etc/udev/permissions.d/50-udev.permissions invariata, sarà necessario creare un file /etc/udev/permissions.d/10-udev.permissions contenente le seguenti voci per rendere il dispositivo scrivibile e leggibile da tutti:

#set Palm Pilot rw
pilot*:root:usb:0666

Si eseguirà ora un controllo per vedere se tutto finziona. Premere il pulsante per l'Hotsync e dare un comando innocuo per avere la lista dei file sul Palm:

bash-2.05b$ pilot-xfer -p /dev/pilot -L

Si dovrebbe ottenere la lista dei file del Palm Pilot. Infine, ci si assicuri che l'interfaccia GUI che si usa con il proprio Palm, controlli in /dev/pilot (piuttosto che in TTYUSB).

Flash drive: by Chris Atkinson 

Una delle periferiche più comuni di cui fioccano le domande è la penna USB. Questa è una periferica grande quanto un dito che può essere inserita in una porta USB e montata come un disco.

Questa sezione copre gli aspetti legati a udev sull'uso di tale periferica. Si raccomanda di leggere tutorial più generali per queste periferiche, per essere sicuri di non avere problemi non legati a udev.

Una nota che non riguarda udev è che partendo dai kernel 2.6.9 si dovrebbe compilare il supporto per gli usb block drives piuttosto che usare l'emulazione SCSI. Dato che questo è abbastanza nuovo, si faranno anche esempi usando sia i vecchi dispositivi sd* che i nuovi ub*.

Per partire, inserire la periferica ed eseguire dmesg. Usando l'emulazione SCSI, l'ultima riga dell'output dovrebbe assomigliare alla seguente:

usb 1-2: new high speed USB device using address 2
Initializing USB Mass Storage driver...
scsi0 : SCSI emulation for USB Mass Storage devices
 Vendor: 128MB Model: USB2.0FlashDrive Rev: 
 Type: Direct-Access ANSI SCSI revision: 02
USB Mass Storage device found at 2
usbcore: registered new driver usb-storage
USB Mass Storage support registered.
SCSI device sda: 251904 512-byte hdwr sectors (129 MB)
sda: Write Protect is off
sda: Mode Sense: 03 00 00 00
sda: assuming drive cache: write through
 sda: sda4
Attached scsi removable disk sda at scsi0, channel 0, id 0, lun 0

Usando invece il supporto usb block device dei kernel 2.6.9+, dovrebbe apparire come segue:

usb 1-2: new high speed USB device using address 2
ub: sizeof ub_scsi_cmd 60 ub_dev 924
uba: device 2 capacity nsec 256000 bsize 512
uba: was not changed
 uba: uba1
usbcore: registered new driver ub

Inizia ora la caccia di questa periferica in /sys. Il problema infido è che non si sta cercando il dispositivo sda (o uba), ma piuttosto la sua partizione sda4 (o uba1). Per questo eseguire il comando:

$ udevinfo -p /sys/block/sda/sda4 -a

O per i nuovi dispositivi ub*

$ udevinfo -p /sys/block/uba/uba1 -a

La parte interessante dell'output dovrebbe assomigliare alla seguente:

looking at the device chain at '/sys/devices/pci0000:00/0000:00:1d.7/usb1/1-1':
 BUS="usb"
 ID="1-1"
 SYSFS{bConfigurationValue}="1"
 SYSFS{bDeviceClass}="00"
 SYSFS{bDeviceProtocol}="00"
 SYSFS{bDeviceSubClass}="00"
 SYSFS{bMaxPower}=" 84mA"
 SYSFS{bNumConfigurations}="1"
 SYSFS{bNumInterfaces}=" 1"
 SYSFS{bcdDevice}="0100"
 SYSFS{bmAttributes}="80"
 SYSFS{detach_state}="0"
 SYSFS{devnum}="2"
 SYSFS{idProduct}="0117"
 SYSFS{idVendor}="0117"
 SYSFS{manufacturer}="Power by USB"
 SYSFS{maxchild}="0"
 SYSFS{product}="USB 2.0 Flash Drive "
 SYSFS{serial}="A083014282978"
 SYSFS{speed}="480"
 SYSFS{version}=" 2.00"

E' ora possibile creare una regola in /etc/udev/rules.d/10-udev.rules come segue:

#Black USB Thumb Drive

BUS="usb", SYSFS{serial}="A083014282978", NAME="blackthumb"

Controllare per assicurarsi che la periferica sia ora presente come un dispositivo in /dev col nome che gli è stato assegato:

$ ls -la /dev | grep thumb

Se esiste, si può aggiungere una voce al file /etc/fstab per permetterne il montaggio.

La riga seguente mostra una voce per una periferica con singola partizione formattata come vfat montabile da qualsiasi utente. Modificare la riga in base alle proprie esigenze.

/dev/thumb /mnt/thumbdrive vfat noauto,user,umask=000 0 0

Alla fine, si monti la periferica per essere sicuri che sia dove ci si aspetta.

$ mount /dev/thumb
$ cd /mnt/thumbdrive
$ ls

9.Link

• La traduzione in tedesco di Udev Primer (Un rigraziamento a: Alexander Minges)
• La traduzione in giapponese di Udev Primer (Un ringraziamento a: Masanao Igarashi)
• La traduzione in giapponese di Udev Primer Misc
• Come scrivere regole udev la Guida DSD.
• Il thread principale di UDEV dal forum di Gentoo