Squaqquerare i dischi

Spiego subito l'origine di questo post.

Capita che l'altro giorno abbia avuto qualche problema di noia e caldo, ma tanto caldo che la goccia di condensa che scaturiva dal condizionatore, evaporava prima di toccare terra ! Ma tanto caldo che mi è toccato mettere in rc.local, la seguente sequenza  :

cpufreq-set -c 0 -u 1.73Ghz
cpufreq-set -c 1 -u 1.73Ghz
cpufreq-set -c 2 -u 1.73Ghz
cpufreq-set -c 3 -u 1.73Ghz

per evitare che il mio quadriprocessore si spegnesse continuamente, non so se rendo l'idea ;) !

In questo momento noioso ho pensato di provare Ubuntu, perché avevo sentito in giro che alcuni reduci, erano riusciti a farla diventare una distribuzione per programmatori umani, distruggendo pezzetti di Unity.

Purtroppo, mentre mi inoltravo per questa selva oscura che la diritta via era smarrita, raccoglievo lentamente i "perché" che trovavo sparsi qui e là sul cammino.

Ora, è ben noto che la quantità dei "perché" che una persona può raccogliere, dipendono dalla persona e dallo stato d'animo.

Nonostante la noia, in quanto sentimento vacuo, lasci spazio ad un enorme numero di "perché", dopo pochi minuti sono riuscito rapidamente a riempire le scatole e ho optato per un ritorno sulla retta via, disseminandola per altro di allegorie dal vago sfondo dissacratorio.

Chiedo venia per tali allegorie e per tale scelta infausta ma non è questo il punto del post, il fatto è che il passaggio da un sistema operativo all'altro è stato fatto con una chiavetta USB da 4 giga e molta indifferenza e allora, visto che il proposto proposito era fallito, mi sono detto : ... perché non spiego due cose su come distruggere un disco e ripristinare tutto con gioia e senza problemi.

Già che ci sono magari insegno anche un po` di arte del volo che come diceva il caro Douglas Adams : "consiste nel lanciarsi contro la terra senza colpirla" o quanto meno evitare le conseguenze del colpo.

Così ho cercato un termine per descrivere la cosa più invereconda che si potesse fare a un disco di sistema, ho tentato di ispirarmi al verso del pinguino, ma non ho trovato rapidamente su Internet una precisa definizione di tale verso, tranne scoprire che alcuni "ragliano".

Turbato da questa notizia mi sono inventato un termine alternativo per il titolo che volevo dare al post. Un titolo che rendesse bene l'idea dell'azione completamente generica che può compiere un qualsiasi sistemista apatico e proveniente da mondi alieni e scimmieschi, la prima volta che si trova con un # di fronte e il comando dd già pronto tra le dita.

Gioie e dolori del disco di sistema

Torniamo sulla terra e partiamo col dire che il disco, specialmente quello di sistema, è nella maggior parte dei sistemi operativi commerciali, assolutamente inviolabile.

Esistono vari tools per modificare, aggiungere togliere e backuppare partizioni ma nella maggioranza dei casi la maggior parte delle persone utilizza tools che fanno il disk dump a blocchi di tutto, con grande dispendio di energie e di mezzi.

Sarebbe bello, senza troppe complicazioni, spedirsi dischi via rete, con nonchalance, salvare tutti i propri dati e creare un'altra macchina perfettamente funzionante, insomma far danzare le partizioni tra DOM e dischi fissi, e in sintesi squaqquerare il disco come ci pare e piace.

Ebbene, in Linux è possibile fare qualsiasi cosa con un po`di fantasia e di conoscenza.

Ho già spiegato in un post precedente, che il disco può essere partizionato per riservarsi i propri dati, montando la home separatamente.

Di solito il disco di sistema, non contiene i dati utente e si reinstalla ma ci sono un milione di motivi, tra i quali il caldo e la noia, che possono indurre a risentimenti temporanei nei confronti della vostra macchina o a scelte sciagurate e che richiedono poi un rapido recovery della situazione.

Con e senza il rescue disk

In Linux c'è il concetto di resque disk, che in pratica è un CD live pieno di utilities.

Per il backup si può fare con o senza il resque disk per il recovery invece ci vuole per forza almeno un Live CD.

È importante che il disco Live sia allo stesso numero di bit del sistema installato, cioè 32 o 64 bit.

Se mi usate un disco a 64 bit su un sistema a 32 o viceversa, la prima volta che mi fate un chroot, potete causare danni inimmaginabili.

Già che ci siete non mischiate pere con banane e vedete di trovare qualcosa con una versione del kernel piuttosto vicina se non identica a quella che avete sul sistema.

Comunque, partire con un CD live vi permette di non "montare" il disco e vederlo da un punto di vista esterno. Ciò è molto utile.

Già ! Perché c'è gente che conosco che di fronte ad un disco di sistema pensano di salvare i dati impunemente con un bel tar czf lamiacopiasicura.tgz / , e sono quelli che normalmente perdono ogni speranza dopo aver perso circa 10 ore ed essersi trovati un tarball malato e di dimensioni immense.

Non si fa così !

Non si fa perché se il disco è montato non solo ci possono essere altri volumi in /media o /mnt (per esempio il disco in cui volete metterlo ....) ma anche le cartelle che avevo definito unbackupable, come la proc, la sys e la dev, che sono dinamiche. Insomma roba dura da digerire, specie se poi cerchi di ripristinarla e spacchi tutto.

Il modo migliore è quello di eseguire il tar da un disco esterno Live, ma può anche essere che non vogliate farlo, perché non avete lì il CD o perché non gradite riavviare la macchina.

Se avete il Live CD, prima di tutto collegate il disco esterno, che dovrebbe finire in /media/diskname, aprite un terminale di root e poi, una volta appurato il device del disco che vi accingete a salvare (/dev/sdaX) date qualcosa tipo :

mkdir /mnt/mydisk
mount /dev/sdaX /mnt/mydisk
cd /mnt/mydisk
tar cvfz /media/diskname/System.20120707152345.tgz .
cd /
sync
umount /mnt/mydisk

Così facendo trasferiremo tutto il tarball dei files di sistema compressi che nel mio caso, essendo una Debian di circa 5.5 giga stanno su una chiavetta di 4.

Notate l'uso improprio e smodato del sync, che ho imparato dagli script di chiusura di Slackware (Patrik dixit), e l'uso della data in formato perfettamente ordinabile che uso come chiave per i miei files di backup.

Importante, se non volete impazzire in seguito, è anche salvarsi una tabellina con questo comando :

ls -la /dev/disk/by-uuid > /media/diskname/UUID.20120707152345.txt

poi capirete perché .

Motivi per non usare il rescue disk

Ci sono vari motivi più o meno validi, tra cui spiccano la pigrizia e la fretta, che potrebbero indurvi a risolvere la cosa sbrigativamente.

La buona notizia è che non c'è problema a patto che siate gli unici ad usare il computer in quel momento.

Potete per esempio dare un :

 init 1 

Che nella maggior parte dei casi vi fa accedere al disco in single user mode, e ripetere la procedura di cui sopra, senza il live CD (che ricordiamo ci vuole comunque per il recovery).

Vediamo di capire due cose:

1. Il single user mode vi serve perché abbatte tutti i servizi che avete in memoria, compreso l'ambiente grafico, altrimenti il backup che state creando potrebbe mancare di coerenza.
2. Nella procedura fate una seconda volta un mount della stessa partizione che avete montato come / e questo vi serve perché se rimontate la partizione, lì dentro le famose directory unbackupable diverranno backupable, cioè saranno una esatta copia fisica del disco e non quelle montate presenti nel vostro sistema, esattamente come se usaste un disco Live.

Se il doppio mount non funziona in certe condizioni, lasciate perdere e usate il live cd ma di solito non ci sono problemi.

Ripristiniamo con un live CD

Dunque,arrivati qui dovremmo avere un disco col nostro tarball, il live cd col giusto kernel e una partizione più o meno vuota dove infilarlo.

Dovete partire col LiveCD aprire un terminale (anche grafico se volete e se c'è) e prima di eseguire il mount, della partizione, assicurarvi che sia vuoto. Se non lo è dovete procedere (sempre da root) con un mkfs.ext4 /dev/sdaX o simili in modo da cancellare completamente il contenuto della partizione riformattando .... ATTENZIONE CHE SIA QUELLA GIUSTA !!!

Usate anche lo stesso file system di quella vecchia. Se cambiate il file system potreste avere vari problemi oppure passarla liscia modificando solo /etc/fstab, ma non ci giurerei.

Una volta ripulita la partizione potete tranquillamente attaccare il disco con l'immagine al live CD e dare qualcosa tipo :

mkdir /mnt/mydisk

mount /dev/sda3 /mnt/mydisk

cd /mnt/mydisk

tar xvfzps /media/diskname/System.20120707152345.tgz .

cd /

sync

Notate la sequenza xvfzps che dovrebbe contribuire a espandere il disco esattamente come l'avete trovato quando avete salvato i dati, le quali casualmente, sono le stesse sequenze che trovate negli scripts di installazione di Slackware (Patrik docet).

Notate anche che manca umount, ma non è una dimenticanza, infatti non abbiamo finito .

Lunga e diritta correva la strada

Si non abbiamo finito, perché qui sorgono i veri problemi !

Nel vecchio sistema Linux, quando ancora c'era il lilo al posto del grub, avremmo infatti dovuto rilanciare il lilo, ma nel nuovo sistema abbiamo a che fare con due grandi innovazioni, il grub, e soprattutto i DISK UID, che permettono la gestione flessibile delle partizioni ma sono una spina nel fianco per questi giochetti.

Nel mondo moderno ad ogni partizione coincide un codice di disco differente, quindi che dobbiamo fare ?

Ricordate la tabellina che vi ho detto di salvare in /media/diskname/UUID.20120707152345.txt ?

Ecco è il momento di dare :

cat /media/diskname/UUID.20120707152345.txt

e tenerselo pronto su un terminale, possibilmente a portata di copia incolla.

Da un altro terminale diamo :

ls -la /dev/disk/by-uuid

confrontandola con la tabellina di prima.

Se avete giocato con un altro sistema sicuramente avrete il disco dove c'è montata / che avete riformattato e poi il sistema vi ha sicuramente riformattato in automatico la partizione di swap.

Le informazioni sui codici vecchi, oltre che sulla tabellina che vi siete salvati, dovreste trovarli in /etc/fstab che è uno dei punti critici, il meno critico in realtà, il più critico è purtroppo GRUB che specialmente nella sua ultima versione è un po` troppo "delicato".

Qui ci sono due scelte. Se avete un sistema semplice in cui c'è solo il vostro sistema e avete temporaneamente riformattato con pentimento, potete ritornare indietro.

Potete quindi mettere i vecchi codici alle due o tre partizioni riformattate, con un comando tipo :

tune2fs /dev/sdaX -U <vecchio codice uuid>

dove sdax è ovviamente la partizione che ha il nuovo UUID sbagliato e l'altro è il codice che recuperate dalla tabellina che avete salvato.  Non vi preoccupate se il sistema vi dà un errore quando tentate di cambiare l'UID della partizione di swap, va tutto bene !

La seconda scelta invece consiste nel cambiare i files sensibili agli UUID e tenersi quelli nuovi. È un po`più complicato ma è più corretto.

Per cambiare gli UUID potete usare un editor grafico dal LiveCD e modificare :

/mnt/mydisc/etc/fstab 

/mnt/mydisc/boot/grub/grub.cfg

Se siete bravi potete anche usare il sed :

sed -i "s/<vecchio codice>/<nuovo codice>/g" <file da cambiare>

e sostituire al volo tutte le presenze.

L'ultimo passaggio

Adesso è il momento di entrare nel sistema che abbiamo appena ricostruito ma non ancora smontato con :

mount -o bind /dev /mnt/mydisk/dev

mount -o bind /sys /mnt/mydisk/sys

mount -o bind /proc /mnt/mydisk/proc

chroot /mnt/mydisk 

et voilà ! Siamo nel nostro vecchio disco dall'aria familiare e diamo :

grub-install /dev/sda 

immaginando ovviamente che il GRUB sia installato nel MBR del /dev/sda.

Ora usciamo e diamo umount del disco, con qualcosa tipo :

exit
umount /mnt/mydisk

Ripartiamo e tutto sarà esattamente come quando l'abbiamo lasciato prima di fare danni o almeno si spera.

Vedo Pinguini Volare

 
Ora, insegneremo come fare volare un Pinguino, cioè data la macchina A con il nostro sistema operativo e la macchina B vuota (naturalmente sulla stessa rete) e con caratteristiche simili ma non necessariamente identiche, sempre PC ma con schede grafiche diverse dimensioni di disco diversi e processori diversi (anche se della stessa categoria), copiare al "volo" il sistema da una macchina all'altra.

Bene, per prima cosa mettete un LiveCD nella macchina B e date il boot.

Partizionate il disco tranquillamente riservando abbastanza spazio al sistema operativo. Quanto spazio occupa il sistema lo potete sapere andando sulla macchina A con il semplice comando df.

La messa a punto del disco o la si fa a mano con i vari mkfs, mkswap, parted eccetera o con le utilities nel LiveCD, tendenzialmente il famoso gparted, tools insomma, con i quali creiamo la partizione di swap e il system disk cioè quello che andrà montato in /. Per eventuali altri dischi/partizioni faremo con comodo in seguito.

Ricordiamo sempre anche il comando che ci serve per sapere gli UUID, che è ls -la /dev/disk/by-uuid .

Una volta preparate sul disco B vediamo il nome di queste due partizioni, tipo /dev/sdaX .

Ora, da un terminale da root, diamo sulla macchina B i primi tre comandi della sequenza che abbiamo già visto :

mkdir /mnt/mydisk

mount /dev/sdaX /mnt/mydisk

cd /mnt/mydisk

e poi diamo un comando che può essere leggermente diverso a seconda della versione di netcat che avete sul vostro sistema.

Nel netcat originale che trovate su Debian per esempio, potete usare gli switch -l -p <port number>, nella orribile versione moderna e "sicura" che trovate sul live cd di Ubuntu non c'è il -p perché è un comando ridondante e implicito nel -l che diventa -l <port number>.

Comunque in sintesi il comando è :

nc -l -p 9823 | tar xvpsz .

Con un numero di porta a caso e dove manca il flag f di tar.

Dall'altra parte entrate in init 1 e rimontate il disco come ho già spiegato nel backup senza resque disk, poi stesso procedimento :

mkdir /mnt/mydisk
mount /dev/sdaX /mnt/mydisk
cd /mnt/mydisk
tar cvz . | nc -q 0 <B ip address> 9823

dove sdaX è la partizione di sistema sul disco A e B ip address è l'ip address della macchina B che potete recuperare con un semplice ifconfig sul live cd.

Appena dato l'invio, vedrete il pinguino volare da una macchina all'altra, volo che dovrebbe terminare alla fine del trasferimento.

Note dolenti

La parte finale, come nel caso precedente è un pasticcio, per il fatto che non ho trovato allo stato attuale un buon configuratore funzionante di GRUB 2.0, senza passare dall'installazione del sistema operativo.

Per /etc/fstab non c'è problema, è molto più facile, comunque questa è la parte del discorso che richiede maggiore destrezza.

Si tratta come avrete capito di modificare sulla macchina B gli UUID nel file /etc/fstab e /boot/grub/grub.cfg con quelli delle nuove partizioni, in modo da rispettare le nuove regole, come avevamo fatto prima.

Qui ci sono due avvertenze :

1. Dovete cambiare tutti gli UID nei files perché sono tutti diversi.
2. Potreste non avere bisogno di tutte le partizioni oppure aggiungene altre, dovete giocare un po`col file grub.cfg e fate un po`a occhio, tanto il sistema si trova ancora al sicuro su A.

Alla fine uscite, riavviate e il vostro pinguino dovrebbe essersi clonato e trasferito da una macchina all'altra.

Conclusioni

Questo è un esempio di quello che si può fare con un sistema operativo "vero".

Potreste anche trovarvi un giorno in condizioni assurde tipo il fatto di operare su server moderni che raccolgano le virtualizzazioni di server reali e obsoleti che avete in azienda, nel qual caso dovrete magari smazzarvela con RAID software e cosucce di questo tipo.

Esistono varie tecniche e sicuramente potrete trovare anche modi migliori di quelli che ho indicato io ma ciò che ho cercato di trasmettere, è più che altro lo spirito dei pinguini volanti che squaqquerano e che sono convinto, se non lo conoscevate ancora,  d'ora in poi resterà comunque sempre con voi.

Amen.