Guida a udev su GentooQuando gli utenti linux parlano del proprio hardware in presenza di persone che pensano linux sia una sorta di strano virus od una nuova marca di caffè, l'utilizzo di termini come "slash dev slash foo" vengono accolti con strani sguardi. Ma per alcuni fortunati utenti (che includono anche chi sta leggendo) utilizzare /dev/sda1 è semplicemente un modo veloce di spiegare che si sta parlando del primo canale SATA, prima partizione... giusto? Tutti sanno cosa sia un file di periferica. Qualcuno sa anche perché questi file hanno diversi numeri quando si da un'occhiata più approfondita in /dev con un ls -l. Ma quello che si dà per scontato è che quando ci si riferisce al primo HD SATA si parla di /dev/hda. Potrebbe anche non essere visto in questo modo, ma questo è un difetto di struttura. Si pensi alle periferiche PlugNPlay come le penne USB, IEEE1394, periferiche PCI hot-swappable...qual è la prima periferica? E per quanto tempo? Come si chiameranno le altre periferiche quando la prima verrà sconnessa? Questo come influenzerà i flussi di dati in corso? Non sarebbe divertente che il proprio lavoro venisse stampato, invece che sulla nuova stampante laser, sulla propria sgangherata stampate ad aghi, solamente perché qualcuno ha deciso di staccare la spina alla stampante laser che era vista dal sistema come primaria? Le finalità del progetto udev sono sia interessanti che necessarie:
Ogni volta che avviene una modifica nella struttura delle periferiche, il kernel emette un uevent che viene ricevuto da udev. A questo punto udev segue le regole impostate nelle directory /etc/udev/rules.d, /run/udev/rules.d e /lib/udev/rules.d. Basandosi sulle informazioni contenute nell'uevent trova la regola o le regole necessarie a innescare ed eseguire le azioni richieste. Queste azioni possono essere creare o cancellare file di periferiche, ma possono anche inizializzare il caricamento di un firmware particolare nella memoria del kernel. udev è stato pensato per funzionare in combinazione con i kernel 2.6 e 3.x (come per esempio gentoo-sources con il profilo di default 10.0). Se si sta utilizzando un kernel simile a questo non dovrebbe esserci alcun problema con l'utilizzo di udev in quanto il supporto necessario è compreso in tutte le versioni stabili di sys-apps/baselayout. Normalmente udev dovrebbe già essere installato nel sistema, se così non fosse è semplice installarlo:
Ricordarsi inoltre di attivare le seguenti opzioni nel kernel:
Se si utilizza genkernel non occorre fare nulla di speciale. Genkernel imposterà udev in modo predefinito. File di periferica mancanti all'avvio Se non si riesce ad avviare il sistema con successo perché si ottiene un errore che dice che il file /dev/null non è stato trovato, o perché la console iniziale non esiste, il problema è dovuto alla mancanza di alcuni file che devono essere presenti nel sistema prima che /dev venga montato e udev inizi a gestirlo. Questo è un errore piuttosto comune sui sistemi Gentoo installati usando supporti vecchi. Avendo installato sys-apps/baselayout-1.8.12, o più recente, questo inconveniente dovrebbe essere alleviato dal fatto che il sistema dovrebbe essere comunque in grado di avviarsi. Comunque, per evitare noiosi avvisi, è sufficiente creare i file di periferica mancanti, come descritto in seguito. Per visualizzare i dispositivi che sono disponibili prima che il filesystem /dev venga montato bisogna eseguire i seguenti comandi:
I dispositivi necessari per avviare correttamente il sistema sono /dev/null e /dev/console. Se non vengono visualizzati durante il test precedente vanno creati manualmente. I comandi seguenti vanno eseguiti nella directory test/dev/ creata in precedenza:
Quando si sono impartiti questi comandi è necessario ricordarsi di smontare la directory test/:
Nel caso si usassero i driver proprietari di nVidia e il server grafico X non partisse, in un sistema configurato per utilizzare solo udev, bisogna assicurarsi che il modulo nvidia sia presente in /etc/conf.d/modules. Assegnazione differente dei nomi tra DevFS e udev Nonostante l'intento di mantenere inalterati i nomi assegnati ai dispositivi da entrambi i sistemi di gestione, in qualche caso può capitare che ci siano delle differenze tra il nome assegnato da DevFS e quello assegnato da udev. Un caso conosciuto riguarda il controller RAID HP Smart Array 5i (più precisamente il modulo del kernel cciss). Con udev, il dispositivo viene chiamato /dev/cciss/cXdYpZ dove X, Y e Z sono numeri. Con devfs, il dispositivo si chiama /dev/hostX/targetY/partZ o é un link simbolico a /dev/cciss/cXdY. In questo caso é necessario ricordarsi di modificare il file /etc/fstab e i file di configurazione del bootloader. La stessa cosa succede con molti dei link simbolici che venivano creati in /dev, come per esempio /dev/mouse, che ora udev non crea più. Assicurarsi che nel proprio file di configurazione di X il percorso del dispositivo del mouse punti ad un file esistente. Un'altro problema è nella differenza di denominazione dei terminali tra devfs e udev. Mentre in devfs i terminali vengono chiamati tty, udev li chiama vc e tty. Ciò può dare dei problemi nel caso siano state applicate delle restrizioni, attraverso l'uso di /etc/securetty, riguardo le login da utente root. Assicurarsi che entrambe le voci tty1 e vc/1 siano elencate nel file di configurazione /etc/securetty, per permettere a root di effettuare il login tramite la console. Rinominare i dispositivi a blocchi Per un paio di anni, udev (dalla 104 in poi) unitamente alle versioni del kernel linux (2.6.19 e successive) potrebbero cambiare i nomi di dispositivo dei propri dischi, a causa di una modifica nell'implementazione del kernel relativa a libata: per esempio una periferica CD-RW mappata in precedenza come /dev/hdc potrebbe cambiare in /dev/sr0. Mentre questo di norma non rappresenta un problema, potrebbe dare dei problemi a qualche applicazione che ha codificato internamente la ricerca dei dispositivi in altre locazioni. Per esempio, media-sound/rip si aspetta di trovare i dischi in /dev/cdrom, e ciò diventa un problema se si usa un nuovo kernel e udev rinomina il proprio dispositivo in /dev/cdrom1. Per aggirare questi problemi, bisogna modificare /etc/udev/rules.d/70-persistent-cd.rules e assegnare il nome corretto al dispositivo. Per ulteriori informazioni riguardanti la scrittura di regole per udev, assicurarsi di leggere la guida di Daniel Drake. Rinominare i dispositivi di rete Talvolta disconnettendo e riconnettendo un dispositivo di rete (come una scheda USB WiFi) essa può venire rinominata ogni volta, incrementandone il numero di un'unità. Quando ciò accade, la si vedrà diventare wlan0, wlan1, wlan2, ecc. Ciò avviene perchè udev sta aggiungendo delle regole aggiuntive al proprio file delle regole, invece di ricaricare le regole esistenti. Siccome udev controlla la propria directory delle regole tramite inotify, bisogna avere il supporto a inotify nella propria configurazione del kernel:
Ora udev ricorderà correttamente i nomi dei propri dispositivi di rete. udev carica i moduli in un ordine non previsto Qualche volta udev carica i moduli in un ordine non indesiderato, non previsto o abbastanza casuale. Tale comportamento è abbastanza comune in special modo per i sistemi che hanno dispositivi multipli dello stesso tipo, per esempio periferiche multimediali. Questo influenza i numeri assegnati ai dispositivi; per esempio, nelle schede sonore talvolta potrebbero invertirsi di numero. Ci sono alcune soluzioni per correggere la numerazione dei dispositivi e/o l'ordine di caricamento dei moduli. Idealmente, basterebbe usare i parametri del modulo per specificare il numero di dispositivo desiderato. Alcuni moduli, come ALSA, include il parametro "index" (indice, ndt). I moduli che usano il parametro index possono essere adeguati come mostrato. Questo esempio è per sistemi con due schede sonore. La scheda con un indice uguale a 0 viene designata come prima scheda. Una volta che i parametri vengono modificati, i file di configurazione del modulo devono essere aggiornati.
L'esempio precedente è la soluzione preferibile, purtroppo non tutti i moduli supportano dei parametri come index. Per tali moduli, bisogna forzare il loro corretto ordine di caricamento. Per prima cosa, bisogna impedire ad udev di caricare automaticamente i moduli inserendoli in una "lista nera" (blacklist). Assicurarsi di usare il nome esatto del modulo che viene caricato. Per i dispositivi PCI, bisogna usare i nomi dei moduli ottenuti dall'output di lspci -k, disponibile nel pacchetto pciutils. L'esempio seguente usa i moduli DVB.
Successivamente, caricare i moduli nell'ordine corretto. Aggiungerli al file /etc/conf.d/modules nell'ordine esatto con cui si desidera vengano caricati.
Il supporto per i dispositivi framebuffer (/dev/fb/*) è stato introdotto a partire dalla versione 2.6.6-rc2 del kernel. Nel caso si usasse un kernel precedente alla versione 2.6.4 è necessario includere esplicitamente il supporto per il filesystem /dev/pts, anche se si raccomanda vivamente di passare ad una versione più recente del kernel.
La conferenza sul sistema udev tenuta da Greg Kroah-Hartman (IBM Corporation) al Linux Symposium (Ottawa, Canada - 2003) è un ottimo punto di partenza per una buona comprensione di udev. Decibel's UDEV Primer è un documento molto approfondito riguardo all'uso di udev su Gentoo. Writing udev rules, scritto dallo sviluppatore di Gentoo Daniel Drake, è un documento eccellente per imparare come personalizzare la proprio installazione di udev. I contenuti di questo documento sono rilasciati sotto la licenza Creative Commons - Attribution / Share Alike. |
|