Quando una periferica non funziona, la prima domanda non è «quale driver installo» ma «il kernel la vede?». Distinguere fra hardware non rilevato e hardware rilevato ma senza modulo è metà del lavoro di diagnosi, ed è esattamente quello che l’esame chiede: quale comando, quale opzione, quale file.

Quello che si decide nel firmware, prima che Linux parta

L’utilità di configurazione che si apre premendo Canc, F2 o F12 all’accensione (BIOS sulle macchine più vecchie, UEFI su quelle dalla fine degli anni 2000 in poi, anche se tutti continuano a chiamarla BIOS) è il posto dove si abilitano e disabilitano le periferiche integrate: controller SATA, audio, rete, porte seriali, funzioni della CPU. Spegnere ciò che non serve riduce i consumi e toglie di mezzo funzioni della CPU con bug noti. Regolare IRQ e DMA a mano oggi è raro, ma il firmware resta l’unico posto dove farlo.

La voce che si sbaglia più spesso è l’ordine di avvio dei dispositivi. Se al primo posto finisce un disco che non contiene il bootloader, la macchina non parte pur essendo integra: è la spiegazione classica del «ho aggiunto un secondo disco SATA e adesso non si avvia più».

lspci e lsusb: vedere che cosa il kernel ha riconosciuto

Due comandi coprono quasi tutta la diagnosi. lspci elenca ciò che sta sul bus PCI: controller disco, schede di rete, GPU, tutto ciò che è saldato sulla scheda madre o infilato in uno slot. lsusb elenca i dispositivi USB, cioè quasi sempre tastiere, dispositivi di puntamento e memorie rimovibili. Entrambi mostrano di più se eseguiti come root o con sudo.

$ lspci -s 04:02.0 -v
04:02.0 Network controller: Ralink corp. RT2561/RT61 802.11g PCI
    Subsystem: Linksys WMP54G v4.1
    Flags: bus master, slow devsel, latency 32, IRQ 21
    Kernel driver in use: rt61pci

Il numero esadecimale a inizio riga è l’indirizzo del dispositivo e si passa a -s per isolarlo; -v aggiunge i dettagli, -k mostra il driver attivo e tutti i moduli disponibili. La riga «Kernel driver in use» è il verdetto: se c’è, il dispositivo è stato identificato e un modulo lo governa; se manca, il bus lo vede ma nessun driver lo pilota, ed è lì che va cercato il problema.

Per l’USB valgono opzioni analoghe: lsusb -t disegna l’albero dei bus mostrando a fine riga il driver e la classe del dispositivo, lsusb -d 1781:0c9f -v isola un modello per coppia idVendor:idProduct, lsusb -s 01:20 isola per bus e numero di device. Queste sigle sono da sapere a memoria, non da riconoscere: -s filtra per posizione, -d per identificativo.

Moduli del kernel: lsmod, modinfo, modprobe

I driver Linux si chiamano moduli e si gestiscono con gli strumenti del pacchetto kmod, identici su ogni distribuzione. lsmod elenca quelli caricati su tre colonne: nome, dimensione in byte occupata in RAM e «Used by», che conta e nomina i moduli dipendenti.

modprobe nome carica un modulo risolvendo le dipendenze, modprobe -r nome lo scarica assieme a quelli rimasti inutilizzati. Se qualcuno lo sta usando il rifiuto è esplicito:

# modprobe -r bluetooth
modprobe: FATAL: Module bluetooth is in use.

modinfo nome mostra descrizione, file, autore, licenza, dipendenze e parametri accettati; modinfo -p nome stampa solo i parametri. Per rendere permanente un parametro, o per impedire il caricamento di un modulo, si scrive un file con estensione .conf dentro /etc/modprobe.d/ (storicamente esisteva anche il singolo /etc/modprobe.conf):

# echo "options nouveau modeset=0" > /etc/modprobe.d/nouveau.conf
# echo "blacklist nouveau" >> /etc/modprobe.d/blacklist.conf

Conviene creare un file per modulo invece di modificare blacklist.conf: si capisce a colpo d’occhio chi ha messo cosa. Il caso tipico è mettere in blacklist nouveau quando si installa il driver proprietario nvidia.

/proc, /sys e /dev: gli stessi dati letti a mano

Quei comandi non fanno altro che leggere file. /proc e /sys sono pseudo-filesystem: non stanno su una partizione, vivono in RAM e spariscono allo spegnimento. In /proc si guardano /proc/cpuinfo per i processori, /proc/interrupts per gli IRQ per CPU, /proc/ioports per le porte di I/O registrate e /proc/dma per i canali DMA. /sys è sysfs ed è dedicato all’hardware e ai dati del kernel collegati, mentre /proc contiene anche processi e strutture interne.

In /dev c’è un file per ogni dispositivo. A popolarlo è udev, che intercetta gli eventi del kernel e applica le regole di /etc/udev/rules.d/, sia per l’hardware già presente all’accensione (coldplug) sia per quello inserito a caldo (hotplug), appoggiandosi proprio a sysfs. D-Bus sta un piano più su: è il bus di messaggi con cui i programmi in esecuzione vengono avvisati, per esempio, che è comparsa una chiavetta. La terna da ricordare è sysfs espone, udev crea i nodi, D-Bus notifica.

Come si chiamano i dischi

I dispositivi di memoria di massa sono block device. Dal kernel 2.4 quasi tutti vengono trattati come SCSI, quindi IDE, SATA, SSD e USB prendono il prefisso sd: /dev/sda, /dev/sdb, con le partizioni numerate /dev/sda1, /dev/sda2. Sulle macchine legacy i dischi IDE erano /dev/hda e /dev/hdb (master e slave del primo canale), /dev/hdc sul secondo, e i floppy /dev/fd0. Due eccezioni da ricordare alla lettera: le schede SD usano /dev/mmcblk0p1, gli SSD NVMe su PCI Express usano /dev/nvme0n1p1.