Ricorda le etichette!

Informatica

In questo post vi racconto di un pasticcio di quelli che capitano ai pivelli di gnu/linux e agli amministratori di sistema distratti (se volete considerarmi nella prima o nella seconda categoria, fate voi), e come un po' di attenzione e delle etichette (label) messe al posto giusto (sulle partizioni ed in fstab e menu.lst) possono prevenire seccature e perdite di tempo del tipo:
Begin: waiting for root file system
[... passano dieci minuti...]
unable to find /dev/sda1

L'altro giorno, così, senza ragione, mi è venuta la strana idea di "fare manutenzione" al serverino Debian stable che utilizzo per le mie sperimentazioni con Apache, MySQL e PHP (uno più serio di me direbbe: il mio server di sviluppo). Dico "strana idea", perché non c'era ragione di fare alcuna manutenzione: tutto funzionava, semplicemente e senza alcun problema.

Ma visto che (irrazionalmente) avevo deciso di fare manutenzione (chiamiamola così...), mi collego al serverino tramite ssh, controllo un po' i log (solite cose, niente di strano), lo spazio su disco (abbondante per l'uso che ne faccio) e cose del genere, avvio aptitude, e controllo se ci sono aggiornamenti disponibili.
Ripeto: non c'era alcuna ragione di fare una cosa del genere, visto che tutto funzionava, e che il serverino non si era mai avventurato in luoghi pericolosi come Internet... insomma, come si dice?
Se funziona non lo toccare, che lo rompi!
Ed infatti...

Infatti c'erano un mucchio di aggiornamenti disponibili: il kernel, mysql, apache, ssh, glibc... visto che mi fido ciecamente (lo so, faccio male, è molto meglio fidarsi e basta) di Debian e del fatto che ho installato una release "stable", non mi sono fermato più di tanto a riflettere: va bene, datti da fare e aggiorna tutto!!!
APT scarica il necessario, installa tutti i pacchetti, e dopo una ventina di minuti mi raccomanda di riavviare un po' di servizi e di riavviare il sistema, perché ho installato un aggiornamento del kernel. E sia! Riavviamo:
# reboot

Passato un minuto, riprovo a collegarmi al serverino (che normalmente ci mette meno di 20 secondi ad avviarsi), per controllare che sia tutto in ordine:
$ ssh 192.168.1.10
Non risponde.

Vabbe', magari è il servizio ssh che non si è avviato, sarà cambiata la configurazione... Proviamo a mandargli un ping, vediamo se risponde...
$ ping 192.168.1.10
PING 192.168.1.10 (192.168.1.10) 56(84) bytes of data.
From 192.168.1.3 icmp_seq=2 Destination Host Unreachable
From 192.168.1.3 icmp_seq=3 Destination Host Unreachable

Niente. Non risponde.

Vuoi vedere che qualcosa è andato storto? Vado al serverino, che è senza monitor (tanto lo uso solo in rete), e premo il tasto di accensione/spegnimento, che di solito, essendo gestito dal sistema di gestione dell'energia, avvia il sistema oppure esegue uno shutdown pulito. Il computer si spegne all'istante. Cattivo segno: acpi non funziona come dovrebbe.

Mi decido allora a collegare un monitor e una tastiera USB al serverino. Lo accendo, vedo le normali schermate del BIOS e di grub, I messaggi di avvio del sistema fino a quando sullo schermo mi ritrovo il messaggio:
Begin: waiting for root file system

E non succede nulla. Niente di niente. È congelato. Perché? Evidentemente non trova la partizione di root. E perché? Boh!
Aspettando un bel po', evidentemente il kernel si è arreso, mi lancia alcuni disperati messaggi sul terminale, tra cui:
unable to find /dev/sda1
E mi lascia una shell minimale, con busybox, speranzoso in un mio aiuto.

Lì per lì non capisco. Che può essere successo? Vado al mio PC desktop, interrogo google, e trovo un sacco di pagine riguardanti lo stesso problema, ma associato a cause diverse. Devo saperne di più.

Torno al serverino. Controllo quali siano le partizioni sul sistema, digitando:
cat /proc/partitions
Mi risponde dicendomi che io ho solo /dev/hda1. Allora io gli chiedo qual è la root del sistema da cui lui voleva avviare:
echo $ROOT
E lui mi risponde:
/dev/sda1
Allora è chiaro quale sia il problema: la root del sistema si trova nella partizione /dev/hda1, ma il kernel all'avvio cerca la partizione /dev/sda1. Vado a sbirciare /boot/grub/menu.lst ed /etc/fstab e nel primo ci trovo il riferimento a /dev/sda1! Ecco dov'è il problema. Riavvio il sistema con CTRL-ALT-DEL, alla schermata di grub premo "e", modifico la riga di comando, sostituendo sda1 con hda1, premo invio e poi provo ad avviare il sitema premendo "b". Funziona tutto di nuovo!

Cos'è successo allora? Probabilmente gli aggiornamenti installati hanno causato un cambiamento nel nome della periferica del disco, da sda ad hda, e i file di configurazione non sono stati cambiati adeguatamente. Oppure uno script ha fatto un pasticcio nell'aggiornare questi file di configurazione dopo aver installato gli aggiornamenti.
Chi lo sa. Se fossi stato un sysadmin attento, mi sarei ricordato se prima dell'aggiornamento il mio disco era sda o hda, o almeno avrei annotato qualcosa, o avrei avuto un backup. Ben mi sta, ho perso un po' di tempo per la mia superficialità.

D'altra parte, è un bel po' che so come si evitano questi problemi: fidandosi un po' di meno e controllando la configurazione prima di riavviare! (fare un backup di sistema prima di un aggiornamento importante è talmente ovvio che non c'è neanche bisogno di dirlo...) ;-)

Nello specifico, la soluzione ai cambiamenti di nome dei dischi, dovuti alle ragioni più varie (aggiornamenti del kernel con effetti imprevisti, cambiato partizionamento, dischi sostituiti, ...) è non usare nei file /etc/fstab e /boot/grub/menu.lst riferimenti alle periferiche del tipo /dev/sda1, /dev/hda5 e simili, ma usare piuttosto i LABEL o i riferimenti UUID.
È un po' che in effetti Ubuntu e le sue derivate (ed anche altre distro, come Mandriva, credo... ) usano i riferimenti UUID nei file di configurazione, mentre Fedora preferisce utilizzare i LABEL, mi pare.

Personalmente, detesto i riferimenti UUID: sono unici, ok (o meglio, è enormemente improbabile imbattersi in due UUID identici), ma per l'utente una stringa così lunga e complicata è praticamente illeggibile e impossibile da ricordare, e dunque è più difficile controllare la correttezza della configurazione.
Giusto per farvi vedere cosa intendo, ecco un esempio con una UUID, da un file /etc/fstab:
# Entry for /dev/hda5 :
UUID=621cd7f8-55b1-436a-9523-dc7b315c160e / ext3 defaults,noatime 1 1

Chi si potrebbe ricordare questa UUID? :-)

Io preferisco di gran lunga i LABEL, che però dovrebbero essere assegnati dall'utente con nomi espressivi e per quanto possibile unici (sì, perché ci può capitare di avere dei problemi se il sistema assegna a hda5 il banale LABEL "root", e poi spostiamo il disco in un altro computer in cui c'è un'altra partizione con lo stesso LABEL).

Ma ecco come fare per usare i LABEL per le nostre partizioni.
Prima di tutto, assegno un nome alla partizione, con il comando:
# e2label /dev/hda1 debroot
Voi ovviamente dovrete sostituire /dev/hda1 con il riferimento alla partizione a cui volete assegnare l'etichetta. In questo caso, io ho chiamato la partizione "debroot", voi scegliete quel che vi pare, è arbitrario.
Se la partizione in questione non è formattata in ext2 né ext3, ma in FAT32 o in NTFS, per impostare i LABEL useremo rispettivamente i comandi dosfslabel (incluso nel pacchetto dosfstools, oppure mlabel, dal pacchetto mtools) e ntfslabel (incluso in ntfsprogs).

Poi vado a modificare il mio file /etc/fstab, sostituiendo il riferimento con la LABEL. Ad esempio:
# Entry for /dev/hda5 :
LABEL=debroot / ext3 defaults,errors=remount-ro, noatime 0 1

Poi vado a modificare anche la configurazione di grub, modificando la riga pertinente di /boot/grub/menu.lst in modi simile a questo:
kernel /boot/vmlinuz-2.6.18-6-686 root=LABEL=debroot ro

In questo modo il kernel sarà sempre in grado di trovare la partizione da cui avviare il sistema e da montare, anche se la configurazione dei dischi dovesse cambiare radicalmente. E questo con un vantaggio: la configurazione sarà sempre leggibile e comprensibile anche da un essere umano distratto come me.
E se dovessi dimenticare il nome che ho dato ad una certa partizione, sarà sufficiente usare il comando e2label senza specificare alcun nome di dispositivo per conoscere il LABEL corrente. In alternativa, si può usare anche il comando vol_id seguito dal nome della partizione, per vedere il LABEL e l'UUID della partizione (ha il vantaggio che funziona con tutti file system).

Ma la soluzione definitiva è sempre non fidarsi mai del tutto della macchina, mantenere il controllo e verificare che sia tutto in ordine prima di riavviare (e tenere dei backup, ma che lo dico a fare? Lo sai già!).

E se fate un pasticcio, non fatevi prendere dal panico!
Leggete tutti i messaggi di errore restituiti sul terminale: anche se non sa che pesci pigliare, il nostro pinguino ci sa spesso indicare dove sta il problema, basta fare un po' di attenzione per venirne fuori rapidamente.

Trackback URL for this post:

http://gerlos.altervista.org/trackback/386

commenti

ritratto di Anonimo

Domanda

Ma se io uso una label che punta ad hda1 e poi per motivi misteriori la prima partizione diventa sda1 non sto semplicemente spostando il problema? Il server continuerà a non avviarsi finchè non cambio la label... o sbaglio?

ritratto di gerlos

Re: Domanda

No, non sposti il problema, perché la label è associata alla partizione in quanto tale, e non al nome che gli dà il kernel!
In pratica la label è scritta nel filesystem, il kernel all'avvio la rileva, ed è in grado di identificare la partizione in modo univoco, indipendentemente da come sia chiamata in modo "classico".

L'applicazione più furba di questa cosa è per i sistemi che si avviano da USB: ad esempio, non hai modo a priori di sapere se il kernel chiamerà /dev/sda1 o /dev/sdb1 la partizione dove tieni il sistema. Ma poiché sai che il kernel legge i label, se presenti, stai certo che se referenzi la partizione con il label nel boot loader e in fstab, il suo sistema si avvierà sempre correttamente.

Lo stesso accade con gli identificativi UUID.

Invia nuovo commento

Il contenuto di questo campo è privato e non verrà mostrato pubblicamente.
  • Allowed HTML tags: <a> <em> <strong> <del> <cite> <code> <img> <ul> <ol> <li> <dl> <dt> <dd> <pre>
  • Linee e paragrafi vanno a capo automaticamente.
  • Insert Flickr images: [flickr-photo:id=230452326,size=s] or [flickr-photoset:id=72157594262419167,size=m].
  • Indirizzi web o e-mail vengono trasformati in link automaticamente

Maggiori informazioni sulle opzioni di formattazione.

CAPTCHA
Per provare che sei un visitatore umano, rispondi a questa domanda. È per evitare l'inserimento di messaggi spam.
Image CAPTCHA
Enter the characters shown in the image without spaces, also respect upper and lower case.