Software Raid 1: configurazione e verifiche: differenze tra le versioni

Da Guide@Debianizzati.Org.
Vai alla navigazione Vai alla ricerca
(tolta categoria "Da Adottare" (era stata inserita a mano))
 
(13 versioni intermedie di 5 utenti non mostrate)
Riga 1: Riga 1:
== Introduzione ==
{{Guida da adottare}}{{Versioni compatibili|Sarge|}}{{Template:RAID}}
= Introduzione =


Questa guida, intende aiutare l'utente a verificare e rifinire la configurazione di un SOFTWARE-RAID-1 su '''Debian Sarge''' a seguito di un'installazione raid effettuata al momento del partizionamento, ed a verificarne l'effettiva efficacia in caso di problemi ad uno dei due dischi avvalendosi di grub come strumento di aiuto in casi di emergenza.
Questa guida intende aiutare l'utente a verificare e rifinire la configurazione di un SOFTWARE-RAID-1 su '''Debian Sarge''' a seguito di un'installazione raid effettuata al momento del partizionamento, ed a verificarne l'effettiva efficacia, in caso di problemi ad uno dei due dischi, avvalendosi di grub come strumento di aiuto in casi di emergenza.


E' scritto in modo semplice come controllare il proprio raid installato, come collaudare il raid simulando un guasto ad uno dei due dischi, quali problemi possono sorgere e come risolverli, in modo da essere pronti e sapere cosa fare se il guasto dovesse avvenire veramente.
È scritto in modo semplice come controllare il proprio raid installato, come collaudare il raid simulando un guasto ad uno dei due dischi, quali problemi possono sorgere e come risolverli, in modo da essere pronti e sapere cosa fare se il guasto dovesse avvenire veramente.


{{ Warningbox |
{{ Warningbox |
Se pero' mentre fate queste prove, il pc vi "scoppia", non potete prendervela con questa guida, mentre correzioni ed integrazioni alla presente sono ben accette. }}
Se però, mentre fate queste prove, il PC vi "scoppia", non potete prendervela con questa guida, mentre correzioni ed integrazioni alla presente sono ben accette. }}
Questa guida non tratta la migrazione raid, documentata dettagliatamente in <tt>/usr/share/doc/mdadm/rootraiddoc.97.html</tt>, anche se ci sono alcuni suggerimenti all'inizio di questo documento non presenti nel <tt>rootraiddoc.97.html</tt> che potrebbero essere di aiuto.
Questa guida non tratta la migrazione raid, documentata dettagliatamente in <code>/usr/share/doc/mdadm/rootraiddoc.97.html</code>, anche se ci sono alcuni suggerimenti all'inizio di questo documento non presenti nel <code>rootraiddoc.97.html</code> che potrebbero essere di aiuto.


Con sarge, il ''debian-installer'' prevede una costruzione del raid direttamente durante la fase di partizionamento (attenzione che puo' anche fallire, non e' al "100%" sicuro che vada a buon fine). Utilizzando l'initrd, i moduli per il raid sono ora precaricati prima del boot del sistema e pertanto non e' necessario avere il supporto raid compilato nel kernel.
Da Debian Sarge, il ''debian-installer'' prevede una costruzione del raid direttamente durante la fase di partizionamento (attenzione che può anche fallire, non è al "100%" sicuro che vada a buon fine). Utilizzando l'initrd, i moduli per il raid sono ora precaricati prima del boot del sistema e pertanto non è necessario avere il supporto raid compilato nel kernel.


== Note sulla migrazione da un sistema non-raid ad uno raid ==
{{ Warningbox |
Da Debian Squeeze il boot loader di default è diventato '''grub2'''. Tutti i paragrafi di questa guida che trattano della configurazione del boot loader non sono perciò più utilizzabili. }}


La migrazione da un sistema non-raid ad uno raid e' ampiamente e perfettamente descritta nel documento '''/usr/share/doc/mdadm/rootraiddoc.97.html''' che contempla sia una migrazione con lilo e supporto md compilato NEL kernel, sia una migrazione con grub con supporto md NON nel kernel ma nel initrd, ovvero l'estensione del kernel con moduli che vengono precaricati in un "ramdisk" prima di lanciare il boot vero e proprio del sistema.
= Note sulla migrazione da un sistema non-raid ad uno raid =
 
La migrazione da un sistema non-raid ad uno raid è ampiamente e perfettamente descritta nel documento <code>/usr/share/doc/mdadm/rootraiddoc.97.html</code> che contempla sia una migrazione con ''lilo'' e supporto ''md'' compilato NEL kernel, sia una migrazione con grub con supporto ''md'' NON nel kernel ma nell'initrd, ovvero l'estensione del kernel con moduli che vengono precaricati in un "ramdisk" prima di lanciare il boot vero e proprio del sistema.


A questo proposito, giusto due note che potrebbero esservi utili:
A questo proposito, giusto due note che potrebbero esservi utili:
Riga 21: Riga 25:
Regola a prescindere da qualunque flame: SWAP VA IN RAID! Altrimenti si rischia corruzione di dati nella memoria del sistema.
Regola a prescindere da qualunque flame: SWAP VA IN RAID! Altrimenti si rischia corruzione di dati nella memoria del sistema.


La parte piu' "complessa" della migrazione potrebbe essere proprio la partizione di swap, che va articolata in questi passaggi:
La parte più "complessa" della migrazione potrebbe essere proprio la partizione di swap, che va articolata in questi passaggi:


* commentare /etc/fstab  --> swap
* commentare /etc/fstab  --> swap
Riga 32: Riga 36:
* <code>mkswap -c /dev/md3</code>  (per esempio)
* <code>mkswap -c /dev/md3</code>  (per esempio)
* <code>swapon md3</code>
* <code>swapon md3</code>
* in <tt>/etc/fstab</tt>, prima in hda, poi nel raid, metteremo:  
* in <code>/etc/fstab</code>, prima in hda, poi nel raid, metteremo:  


   /dev/md3  none  swap sw  0  0
   /dev/md3  none  swap sw  0  0
Riga 38: Riga 42:
:<big>''' 2. Copiare le partizioni a "runlevel 1" o in "single" mode'''</big>
:<big>''' 2. Copiare le partizioni a "runlevel 1" o in "single" mode'''</big>


Una cosa che non c'e' nel RootRaidDoc97 e' il suggerimento di andare in "init 1" per disattivare il piu' servizi possibili prima di copiare da hd a md-degraded. Se decidete di farlo, ci sono diverse possibilita':
Una cosa che non c'è nel RootRaidDoc97 è il suggerimento di andare in "init 1" per disattivare più servizi possibili prima di copiare da hd a md-degraded. Se decidete di farlo, ci sono diverse possibilità:


* riavviare Lilo con "LinuxXXX single" (praticamente un <code>init 1</code>), oppure ancora piu' drastico, riavviare Lilo con LinuxXXX init=/bin/bash in modo da ottenere un avvio con '/' in readonly;
* riavviare Lilo con "LinuxXXX single" (praticamente un <code>init 1</code>) oppure, ancora più drasticamente, riavviare Lilo con LinuxXXX init=/bin/bash in modo da ottenere un avvio con '/' in readonly;


* Avere in menu.lst (grub) l'opzione "single" dopo il kernel. Se non l'avete basta duplicare una voce normale di avvio, aggiungere <code>(recovery mode)</code> alla fine del title, ed aggiungere <code>single</code> alla fine della riga del kernel. E' possibile al posto di single mettere anche <code>init=/bin/bash</code>
* Avere in <code>menu.lst</code> (grub) l'opzione "single" dopo il kernel. Se non l'avete basta duplicare una voce normale di avvio, aggiungere <code>(recovery mode)</code> alla fine del title, ed aggiungere <code>single</code> alla fine della riga del kernel. È possibile al posto di 'single' mettere anche <code>init=/bin/bash</code>
    
    
* Usare una distribuzione live con supporto raid montando opportunamente  
* Usare una distribuzione live con supporto raid montando opportunamente le partizioni sorgenti e di destinazione.
le partizioni sorgenti e di destinazione.


* senza bisogno di riavviare la macchina, digitare in un terminale il comando "telinit 1" oppure "init 1".
* senza bisogno di riavviare la macchina, digitare in un terminale il comando "telinit 1" oppure "init 1".


Gia che ci siamo, ricordiamo i comandi piu' usati per copiare da non-raid a raid:
Già che ci siamo, ricordiamo i comandi più usati per copiare da non-raid a raid:


# cp -axu  /  /mnt/md0  
<pre># cp -axu  /  /mnt/md0 </pre>


O, alternativamente, si può copiare il root system con <code>find</code> in pipe a <code>cpio</code>, così:
O, alternativamente, si può copiare il root system con <code>find</code> in pipe a <code>cpio</code>, così:


# cd /
<pre># cd /
# find . -xdev -print | cpio -dvpm /mnt/md0
# find . -xdev -print | cpio -dvpm /mnt/md0</pre>
o anche:     


o anche     
<pre># find . -xdev -print0 | cpio -0pdvum --sparse /mnt</pre>


# find . -xdev -print0 | cpio -0pdvum --sparse /mnt
Per il resto delle istruzioni vale quanto scritto nel <code>RootRaidDoc.97.html</code>.


Per il resto delle istruzioni vale quanto scritto nel RootRaidDoc.97.html.
Occupiamoci ora del raid già funzionante della nostra cara Debian.


Occupiamoci ora del raid gia' funzionante della nostra cara debian.
= Files di una Debian installata direttamente in raid. =


== Files di una debian installata direttamente in raid. ==
Si suppone un sw-raid-1 hda + hdc con almeno due partizioni in raid cioè root ( / ) e swap. Il bootloader grub è stato installato nel [[MBR]] di hda durante l'installazione.
 
Se avete optato per una installazione raid con il debian-installer al momento del partizionamento e tutto è andato a buon fine, mamma Debian dovrebbe aver fatto quasi tutto il lavoro per voi.  
Si suppone un sw-raid-1 hda + hdc con almeno due partizioni in raid cioe' "/" e swap. Il bootloader grub e' stato installato nel [[MBR]] di hda durante l'installazione.
Se avete optato per una installazione raid con il debian-installer al momento del partizionamento e tutto e' andato a buon fine, mamma debian dovrebbe aver fatto quasi tutto il lavoro per voi.  


'''Quasi.'''
'''Quasi.'''


Quello che manca di sicuro e' la installazione di grub del [[MBR]] da hda sul secondo disco (Trattata avanti, da lèggere!!). Inoltre e' compito dell'amministratore vedere che tutti gli altri parametri nei vari files siano stati assegnati correttamente verificandoli.
Quello che manca di sicuro è l'installazione di grub del [[MBR]] sul secondo disco (Trattata avanti, da lèggere!!). Inoltre è compito dell'amministratore vedere che tutti gli altri parametri nei vari file siano stati assegnati correttamente verificandoli.


Vediamo alcune differenze nei files di configurazione tra un sistema non-raid ed uno raid.
Vediamo alcune differenze nei file di configurazione tra un sistema non-raid ed uno raid.


* Verifica delle unita' riconosciute da grub
* Verifica delle unità riconosciute da grub:


  Non raid:
<pre>Non raid:
     cat /boot/grub/device.map
     cat /boot/grub/device.map
     (hd0)  /dev/hda
     (hd0)  /dev/hda
Riga 85: Riga 87:
     cat /boot/grub/device.map
     cat /boot/grub/device.map
     (hd0)  /dev/hda
     (hd0)  /dev/hda
     (hd1)  /dev/hdc
     (hd1)  /dev/hdc</pre>


* Parti rilevanti diverse in /boot/grub/menu.lst
* Parti rilevanti diverse in <code>/boot/grub/menu.lst</code>:


  Non Raid:
<pre>Non Raid:
     # kopt=root=/dev/hda1 ro
     # kopt=root=/dev/hda1 ro
   - Una voce esempio:     
   - Una voce esempio:     
Riga 106: Riga 108:
     initrd          /boot/initrd.img-2.6.8-2-386
     initrd          /boot/initrd.img-2.6.8-2-386
     savedefault
     savedefault
     boot
     boot</pre>


* Il file "script" dentro initrd
* Il file "script" dentro initrd:


  Non Raid:
<pre>Non Raid:
     NO-raid:~# cd /tmp/
     NO-raid:~# cd /tmp/
     NO-raid:/tmp# mkdir checkRD
     NO-raid:/tmp# mkdir checkRD
Riga 136: Riga 138:
       mdadm -A /dev/md0 -R -u 1b1d819d:1d22603a:9be3ef56:bbdb1083  
       mdadm -A /dev/md0 -R -u 1b1d819d:1d22603a:9be3ef56:bbdb1083  
               /dev/hda1 /dev/hdc1
               /dev/hda1 /dev/hdc1
     SI-raid:/tmp/checkRD# umount RD
     SI-raid:/tmp/checkRD# umount RD</pre>


* Il file <tt>/etc/mdadm/mdadm.conf</tt>
* Il file <code>/etc/mdadm/mdadm.conf</code>:


  Raid:
<pre>Raid:
     DEVICE partitions
     DEVICE partitions
     ARRAY /dev/md1 level=raid1 num-devices=2 UUID=42b38c30:b5f7607b:
     ARRAY /dev/md1 level=raid1 num-devices=2 UUID=42b38c30:b5f7607b:
                       a1816991:4e0bdf0f devices=/dev/hda2,/dev/hdc2
                       a1816991:4e0bdf0f devices=/dev/hda2,/dev/hdc2
     ARRAY /dev/md0 level=raid1 num-devices=2 UUID=1b1d819d:1d22603a:
     ARRAY /dev/md0 level=raid1 num-devices=2 UUID=1b1d819d:1d22603a:
                       9be3ef56:bbdb1083 devices=/dev/hda1,/dev/hdc1
                       9be3ef56:bbdb1083 devices=/dev/hda1,/dev/hdc1</pre>


Comunque, a parte l'installazione di grub anche nel secondo [[MBR]] (quello di hdc), da fare a manina e testare, la debian dovrebbe aver fatto tutto il lavoro di costruzione opportuno e la configurazione precisa di tutti i files citati sopra durante la costruzione dell'initrd per il raid e la configurazione di grub per l'avvio in raid con kernel e initrd caricati da hda.
Comunque, a parte l'installazione di grub anche nel secondo [[MBR]] (quello di hdc), da fare a manina e testare, la Debian dovrebbe aver fatto tutto il lavoro di costruzione opportuno e la configurazione precisa di tutti i file citati sopra durante la costruzione dell'initrd per il raid e la configurazione di grub per l'avvio in raid con kernel e initrd caricati da hda.


== Grub sul Master Boot Record del secondo disco in raid. ==
= Grub sul Master Boot Record del secondo disco in raid. =


Dovendo installare su entrambi i dischi grub nel [[MBR]] per far avviare un raid con un solo disco, qualunque dei due esso possa essere, il classico problema e' assicurarsi che possa partire da hda o da hdc in caso di guasto di uno dei due dischi, sempre ammesso che il bios supporti l'avvio da piu' dischi e sia possibile specificarne l'ordine di boot, per esempio prima "hdc" piuttosto che "hda", cosa ottimale, auspicabile, ma alla fine non indispensabile come vedremo.
Dovendo installare su entrambi i dischi grub nel [[MBR]] per far avviare un raid con un solo disco, qualunque dei due esso possa essere, il classico problema è assicurarsi che possa partire da hda o da hdc in caso di guasto di uno dei due dischi, sempre ammesso che il BIOS supporti l'avvio da più dischi e sia possibile specificarne l'ordine di boot. Per esempio prima "hdc" e poi "hda", cosa ottimale, auspicabile, ma alla fine, come vedremo, non indispensabile.


Veniamo al primo punto, ovvero installare grub anche nel [[MBR]] di hdc, cosa che rappresenta il 99% delle operazioni da fare su un sistema raid appena avviato.
Veniamo al primo punto, ovvero installare grub anche nel [[MBR]] di hdc, cosa che rappresenta il 99% delle operazioni da fare su un sistema raid appena avviato.
In "letteratura" si trovano sostanzialmente due tipi di procedure suggerite; la prima piu' diffusa e avvalorata anche dal Software-Raid-HOWTO (tldp.org), consiste nell'inserire nel [[MBR]] di hdc la stessa configurazione del [[MBR]] di hda, confidando nel fatto che quando dovesse mancare hda, hdc in qualche modo prenderebbe il posto di hda e automagicamente tutto dovrebbe andare; vedremo poi, che proprio cosi' non e', pero' dato che male non fa, e' la procedura che consiglio pure io comunque di attuare, ovvero:
In "letteratura" si trovano sostanzialmente due tipi di procedure suggerite; la prima, più diffusa e avvalorata anche dal Software-Raid-HOWTO (tldp.org), consiste nell'inserire nel [[MBR]] di hdc la stessa configurazione del [[MBR]] di hda, confidando nel fatto che quando dovesse mancare hda, hdc in qualche modo prenderebbe il posto di hda e automagicamente tutto dovrebbe andare; vedremo poi, che proprio così non è. Comunque, dato che male non fa, è la procedura che consiglio pure io di attuare, ovvero:


; Procedura1: In console:
; Procedura1: In console:
    # grub
<pre>  # grub
             (se avete /boot/grub/device.map corretto, usate
             (se avete /boot/grub/device.map corretto, usate
                 grub --device-map /boot/grup/device.map
                 grub --device-map /boot/grup/device.map
               perche' e' molto piu' veloce)
               perché è molto più veloce)
     >> grub> device (hd0) /dev/hdc
     >> grub> device (hd0) /dev/hdc
     >> grub> root (hd0,0)
     >> grub> root (hd0,0)
     >> grub> setup (hd0)
     >> grub> setup (hd0)
     >> grub> quit
     >> grub> quit</pre>


Fatto. Ora il sistema e' in grado di avviarsi anche da hdc se il bios lo permette.
Fatto. Ora il sistema è in grado di avviarsi anche da hdc se il BIOS lo permette.
Ma questo lo avete provato prima di fare il raid, vero? (Ripeto pero', non e' indispensabile).
Ma questo lo avete provato prima di fare il raid, vero? (Ripeto però, non è indispensabile).


Poi c'e' la seconda procedura:
Poi c'è la seconda procedura:


; Procedura2: In console:
; Procedura2: In console:
    # grub --device-map=/boot/grub/device.map
<pre>  # grub --device-map=/boot/grub/device.map
     >> root (hd0,0)
     >> root (hd0,0)
     >> setup (hd0)
     >> setup (hd0)
     >> root (hd1,0)
     >> root (hd1,0)
     >> setup (hd1)
     >> setup (hd1)
     >> quit  
     >> quit </pre>


Che assegna in maniera "democratica" a tutti e due gli [[MBR]] la stessa configurazione di <tt>grub/menu.lst</tt>.
Che assegna in maniera "democratica" a tutti e due gli [[MBR]] la stessa configurazione di <code>grub/menu.lst</code>.


In pratica i due metodi dovrebbero essere equivalenti, in teoria non lo so e non lo ho trovato scritto da nessuna parte (e se stava scritto non l'ho capito forse) o meglio, da quello che ho letto, il comando "device" utilizzato nella prima procedura con grub dovrebbe essere usato nel caso non vi sia un valido /boot/grub/devices.map (e non e' il nostro caso) mentre sembra venga utilizzato solamente per "ingannare" temporaneamente sulla destinazione del Master Boot Record dove verra' installato grub. Concorderete che la seconda procedura sembra molto piu' chiara, anche se le prove mi dicono che pure questo secondo metodo non e' esente da problemi in caso di guasto di uno dei due dischi del raid (in particolare del primo - hda).
In pratica i due metodi dovrebbero essere equivalenti, in teoria non lo so e non lo ho trovato scritto da nessuna parte (e se stava scritto non l'ho capito forse). O meglio, da quello che ho letto, il comando "device" utilizzato nella prima procedura con grub dovrebbe essere usato nel caso non vi sia un valido <code>/boot/grub/devices.map</code> (e non è il nostro caso) mentre sembra venga utilizzato solamente per "ingannare" temporaneamente sulla destinazione del Master Boot Record dove verrà installato grub. Concorderete che la seconda procedura sembra molto più chiara, anche se le prove mi dicono che pure questo secondo metodo non è esente da problemi in caso di guasto di uno dei due dischi del raid (in particolare del primo - hda).


== Post-installazione Raid. ==
= Post-installazione Raid. =


Una volta tirato su il raid con migrazione o durante l'installazione assieme al partizionamento,  
Una volta tirato su il raid con migrazione o durante l'installazione assieme al partizionamento,  


'''Prima di tutto''' fate un disco grub per qualsiasi evenienza: <tt>grub-floppy /dev/fd0</tt>.
'''Prima di tutto''' fate un disco grub per qualsiasi evenienza: <code>grub-floppy /dev/fd0</code>.


Grub-floppy e' un utility del pacchetto debian di grub, ma esiste ampia documentazione che spiega a costruirne uno anche manualmente mettendo sul floppy i files giusti nella sequenza ed al posto giusto (ad es. vedi [[Guida a Grub]]). Esiste anche documentazione per prepararsi un grub avviabile da cd.
Grub-floppy è un utility del pacchetto Debian di grub, ma esiste ampia documentazione che spiega a costruirne uno anche manualmente mettendo sul floppy i file giusti nella sequenza ed al posto giusto (ad es. vedi [[Guida a Grub]]). Esiste anche documentazione per prepararsi un grub avviabile da cd.


Usate tutti i riferimenti nel <tt>/boot/grub/menu.lst</tt> riferendovi ad hd0 e /dev/mdX (in realta' dovrebbero gia' esserci, messi in automatico durante l'installazione).
Usate tutti i riferimenti nel <code>/boot/grub/menu.lst</code> riferendovi ad hd0 e <code>/dev/mdX</code> (in realtà dovrebbero già esserci, messi in automatico durante l'installazione).


Clonate l'[[MBR]] secondo la "procedura1" di cloning. Se avete dubbi potete usare anche la "procedura2", entrambi descritte in precedenza.
Clonate l'[[MBR]] secondo la "procedura1" di cloning. Se avete dubbi potete usare anche la "procedura2", entrambi descritte in precedenza.
Riga 199: Riga 201:
Prova di funzionamento:
Prova di funzionamento:
* Inserire il floppy di recupero grub
* Inserire il floppy di recupero grub
* Riavviare il pc
* Riavviare il PC
* Se l'ordine di boot nel bios e' corretto, verra' intercettato il floppy e avviato grub che ci fornira' una potente console di avvio. Scriviamo nell'ordine (adattando, al caso):
* Se l'ordine di boot nel bios è corretto, verrà intercettato il floppy e avviato grub che ci fornirà una potente console di avvio. Scriviamo nell'ordine (adattando, al caso):
    
    
    grub>  
<pre>  grub>  
     1. grub>root (hd1,0)
     1. grub>root (hd1,0)
     2. grub>kernel /boot/vmlinuz-2.6.8-blabla root=/dev/md0 ro
     2. grub>kernel /boot/vmlinuz-2.6.8-blabla root=/dev/md0 ro
     3. grub>initrd /boot/initrd-2.6.8-blabla
     3. grub>initrd /boot/initrd-2.6.8-blabla
     4. grub>boot
     4. grub>boot</pre>


:''Spieghiamo:''
:''Spieghiamo:''
:; 1 : diciamo a grub la partizione dove si trova <tt>/boot</tt>  (non "/" !!!)
:; 1 : diciamo a grub la partizione dove si trova <code>/boot</code>  (non "/" !!!)
{{Warningbox|Se non ci fosse il disco in hda, e vorreste avviare da hdc,
{{Warningbox|Se non ci fosse il disco in hda, e vorreste avviare da hdc,
per la questione della "catena grub" che viene scalata in mancanza di
per la questione della "catena grub" che viene scalata in mancanza di
un'unita' elencata in devices.map, dovreste mettere "root (hd0,0)" !!!}}
un'unità elencata in devices.map, dovreste mettere "root (hd0,0)" !!!}}


:; 2 : diciamo dove sta il kernel (funziona anche il l'autocompletamento con TAB)
:; 2 : diciamo dove si trova il kernel (funziona anche il l'autocompletamento con TAB)
:; 3 : diciamo dove sta l'initrd
:; 3 : diciamo dove si trova l'initrd
:; 4 : diciamo a grub, caricato kernel e initrd di avviare il sistema.
:; 4 : diciamo a grub, caricato kernel e initrd, di avviare il sistema.


Se il sistema si avvia, abbiamo tutto quello che ci serve.
Se il sistema si avvia, abbiamo tutto quello che ci serve.


== Avaria di uno dei due dischi in raid. ==
= Avaria di uno dei due dischi in raid. =


Vediamo invece problematiche di raid boot quando uno dei dischi provoca un degraded raid a seconda se e' hda, hdc, oppure se manca hda o hdc, oppure se si ripristina un hda o hdc, e cosa fare se il raid in qualunque di queste condizioni non dovesse partire.  
Vediamo invece problematiche di raid boot quando uno dei dischi provoca un degraded raid a seconda se è hda, hdc, oppure se manca hda o hdc, oppure se si ripristina un hda o hdc, e cosa fare se il raid in qualunque di queste condizioni non dovesse partire.  


Se il raid va in degraded mode ed il disco incriminato e' hdc ovvero /proc/mdstat indica "(U_)", non ci sono grandi problemi. Il boot naturale su hda e' sempre li'; si puo' avviare un sistema con un disco solo o cambiare hdc, partizionare il disco nuovo, e ripristinare facilmente il raid.  
Se il raid va in degraded mode ed il disco incriminato è hdc ovvero <code>/proc/mdstat</code> indica "(U_)", non ci sono grandi problemi. Il boot naturale su hda è sempre ; si può avviare un sistema con un disco solo o cambiare hdc, partizionare il disco nuovo, e ripristinare facilmente il raid.  


Se invece il raid va in degraded mode ed il disco incriminato e' hda "(_U)", allora qualche problema potrebbe anche esserci, ma anche soluzioni, per fortuna.
Se invece il raid va in degraded mode ed il disco incriminato è hda "(_U)", allora qualche problema potrebbe anche esserci, ma anche soluzioni, per fortuna.


Per esempio se togliete fisicamente hda dopo averlo marcato 'failed' e rimosso, e lasciate il raid con solo hdc, la "procedura1" di cloning del [[MBR]] sopperisce perfettamente al problema, in quanto grub usa una "catena" di dischi, e non trovando hd0, hd1 diventa hd0 e se il bios permette un boot di hdc allora il raid partira' anche con un disco solo in hdc. Questa cosa potrebbe funzionare quindi e sarebbe vincolata solo al bios-hardware.
Per esempio se togliete fisicamente hda dopo averlo marcato 'failed' e rimosso, e lasciate il raid con solo hdc, la "procedura1" di cloning del [[MBR]] sopperisce perfettamente al problema, in quanto grub usa una "catena" di dischi, e non trovando hd0, hd1 diventa hd0 e, se il bios permette il boot di hdc, allora il raid partirà anche col solo disco hdc. Questa cosa potrebbe funzionare e sarebbe vincolata solo al bios-hardware.


''Pero' non finisce qua:''
''Però non finisce qua:''
nel momento in cui andate ad inserire un disco vuoto nuovo in hda senza [[MBR]] e partizioni, o peggio magari con un [[MBR]] gia' usato, o con altre partizioni contenenti un altro sistema, e' molto probabile che, o non parta niente, o parta il sistema che non c'entra niente e che sta su hda (a me e' capitato di veder partire un GAG). Per capirci, anche riuscendo a settare il bios con hdc come 1st boot target, non e' detto che il sistema faccia il boot, perche' ammesso che appaia il menu' di grub si dovrebbero modificare i riferimenti "al volo" di root (/boot) da hd0 a hd1. Per eseguire questa operazione, occorre che appaia il menu' di grub, dopodiche' ci si posiziona sulla voce del menu' che si vuole temporaneamente modificare e si preme il tasto "e" (il tasto "c" vi restituisce la console di grub); si modifica la root di grub da (hd0,0) a (hd1,0) e si preme il tasto "b" per continuare con il boot. E questa procedura appena descritta e' l'ultima possibilita' che resta per avviare un raid degraded "(_U)" da hdc, ovvero con l'aiuto del bios, intervenendo al volo su grub, e senza usare il floppy disk.
nel momento in cui andate ad inserire un disco vuoto nuovo in hda senza [[MBR]] e partizioni, o peggio magari con un [[MBR]] già usato, o con altre partizioni contenenti un altro sistema, è molto probabile che: o non parta niente, o parta il sistema che non c'entra niente e che si trova su hda (a me è capitato di veder partire un GAG). Per capirci, anche riuscendo a settare il BIOS con hdc come 1st boot target, non è detto che il sistema faccia il boot perché, ammesso che appaia il menù di grub, si dovrebbero modificare "al volo" i riferimenti di root (/boot) da hd0 a hd1. Per eseguire questa operazione occorre che appaia il menù di grub, dopodiché ci si posiziona sulla voce del menù che si vuole temporaneamente modificare e si preme il tasto "e" (il tasto "c" vi restituisce la console di grub); si modifica la root di grub da (hd0,0) a (hd1,0) e si preme il tasto "b" per continuare con il boot. Questa procedura appena descritta è l'ultima possibilità che resta per avviare un raid degraded "(_U)" da hdc, ovvero con l'aiuto del BIOS, intervenendo al volo su grub e senza usare il floppy disk.


In realta' se si riesce a far partire il disco da hdc come 1st boot target del bios basterebbe avere nel menu.lst una cosa di questo tipo gia' pronta per questa evenienza:
In realtà, se si riesce a far partire il disco da hdc come 1st boot target del BIOS, basterebbe avere nel file <code>/boot/grub/menu.lst</code> delle righe simili alle seguenti, in grado di far fronte alla precedente evenienza:


<pre>
<pre>
Riga 244: Riga 246:
</pre>
</pre>


In questo caso occorrerebbe fare attenzione al fatto che <code>update-grub</code>, che viene chiamato in causa dopo l'installazione di nuovi kernel, creerebbe un nuovo <tt>menu.lst</tt> facendo sparire tutte le modifiche apportate manualmente, perlomeno quelle tra
In questo caso occorrerebbe fare attenzione al fatto che il comando<code>update-grub</code>, che viene eseguito dopo l'installazione di nuovi kernel, creerebbe un nuovo <code>menu.lst</code> facendo sparire tutte le modifiche apportate manualmente, perlomeno quelle tra:
   
   
### BEGIN AUTOMAGIC KERNELS LIST
<pre> ### BEGIN AUTOMAGIC KERNELS LIST</pre>


e
e


### END DEBIAN AUTOMAGIC KERNELS LIST
<pre> ### END DEBIAN AUTOMAGIC KERNELS LIST</pre>


per cui attenzione a porre le personalizzazioni di <tt>menu.lst</tt> '''fuori da questo blocco'''. In caso di problemi sappiate che <tt>update-grub</tt> salva una copia di backup del <tt>menu.lst</tt> in <tt>/boot/grub/menu.lst~</tt>. Per ulteriori info leggete la [[Guida a Grub]], <tt>man update-grub</tt> e <tt>/etc/kernel-img.conf</tt>. Per stare tranquilli è consigliabile fare una copia di <tt>menu.lst</tt> e verificate i vari files dopo ogni installazione di qualche nuovo kernel ([[Debian Kernel Howto|alla debian-way]] ovviamente).
per cui attenzione a porre le personalizzazioni di <code>menu.lst</code> '''fuori da questo blocco'''. In caso di problemi sappiate che <code>update-grub</code> salva una copia di backup del <code>/boot/grub/menu.lst</code> in <code>/boot/grub/menu.lst~</code>. Per ulteriori info leggete la [[Guida a Grub]], <code>man update-grub</code> e <code>/etc/kernel-img.conf</code>. Per stare tranquilli è consigliabile fare una copia di <code>menu.lst</code> e verificare i vari file dopo ogni installazione di qualche nuovo kernel ([[Debian Kernel Howto|alla debian-way]] ovviamente).


Vedremo piu' avanti durante la fase di test del raid altri tipi di problemi che possono sorgere.
Vedremo più avanti durante la fase di test del raid altri tipi di problemi che possono sorgere.


== Simulazione di avaria di un disco e sua sostituzione. ==
= Simulazione di avaria di un disco e sua sostituzione. =


A raid funzionante dove /proc/mdstat --> "(UU)" per tutte le partizioni usate nel raid, mandiamo in avaria simulata il disco hda.
A raid funzionante dove <code>/proc/mdstat</code> --> "(UU)" per tutte le partizioni usate nel raid, mandiamo in avaria simulata il disco hda.


Se il vostro bios permette di far avviare hdc come 1st boot target aggiungete pure queste righe dopo <tt>### END DEBIAN AUTOMAGIC KERNELS LIST</tt> in <tt>/boot/grub/menu.lst</tt>:
Se il vostro BIOS permette di far avviare hdc come 1st boot target aggiungete pure queste righe dopo <code>### END DEBIAN AUTOMAGIC KERNELS LIST</code> in <code>/boot/grub/menu.lst</code>:


<pre>
<pre>
Riga 273: Riga 275:
Ora la sequenza di comandi:
Ora la sequenza di comandi:
<pre>  
<pre>  
  mdadm --set-faulty /dev/md0 /dev/hda1    ( --> "/" )
mdadm --set-faulty /dev/md0 /dev/hda1    ( --> "/" )
  mdadm --remove /dev/md1 /dev/hda1
mdadm --remove /dev/md1 /dev/hda1
  mdadm --set-faulty /dev/md1 /dev/hda2    ( --> "swap" )
mdadm --set-faulty /dev/md1 /dev/hda2    ( --> "swap" )
  mdadm --remove /dev/md1 /dev/hda1
mdadm --remove /dev/md1 /dev/hda1
</pre>
</pre>


Ripetere per eventuali altre partizioni.
Ripetere per eventuali altre partizioni.


A questo punto siamo in "(_U)" con tutte le partizioni del raid (verificare con cat /proc/mdstat).  
A questo punto siamo in "(_U)" con tutte le partizioni del raid (verificare con cat <code>/proc/mdstat</code>).  


Ora che il raid e' in degraded mode, senza riavviare,
Ora che il raid è in degraded mode, senza riavviare, diamo un bel:
diamo un bel <tt>cfdisk /dev/hda</tt> e CANCELLIAMO TUTTE LE PARTIZIONI.
<pre># cfdisk /dev/hda</pre> e CANCELLIAMO TUTTE LE PARTIZIONI.


Ora per essere sicuri che il disco sia completamente pulito, dovremmo vuotare di ogni suo contenuto anche l'[[MBR]] usando un sistema brutale ma efficace, ovvero un comando del tipo
Per essere sicuri che il disco sia completamente pulito, dovremmo vuotare di ogni suo contenuto anche l'[[MBR]] usando un sistema brutale ma efficace, ovvero un comando del tipo:
<pre>
<pre>
# dd if=/dev/zero of=/dev/hda bs=512 count=1
# dd if=/dev/zero of=/dev/hda bs=512 count=1
</pre>
</pre>
Pero' occorre fare attenzione! La struttura del [[MBR]] e' la seguente:
Però occorre fare attenzione! La struttura del [[MBR]] è la seguente:
<pre>
<pre>
466 bytes : codice boot
466 bytes : codice boot
Riga 296: Riga 298:
   2 bytes : "magic number 55AA"  
   2 bytes : "magic number 55AA"  
</pre>
</pre>
Pertanto a seconda di come vorrete condurre le prove, potrebbe essere che vi basti eliminare il codice boot e salvaguardare la tabella delle partizioni; quindi sarebbe sufficiente:
Pertanto, a seconda di come vorrete condurre le prove, potrebbe essere che vi basti eliminare il codice boot e salvaguardare la tabella delle partizioni; quindi sarebbe sufficiente:
* dd if=/dev/zero of=/dev/hda bs=466 count=1
<pre># dd if=/dev/zero of=/dev/hda bs=466 count=1</pre>
Un modo piu' attento di procedere contemplerebbe il salvataggio dei dati che state per cancellare, quindi un backup di sicurezza non starebbe male:
Un modo più prudente di procedere contemplerebbe il salvataggio dei dati che state per cancellare, quindi un backup di sicurezza non sarebbe male:
* dd if=/dev/hda bs=512 count=1 of=/root/mbr_images/myFullMBR_512
<pre># dd if=/dev/hda bs=512 count=1 of=/root/mbr_images/myFullMBR_512
* dd if=/dev/hda bs=466 count=1 of=/root/mbr_images/myBootMBR_466
# dd if=/dev/hda bs=466 count=1 of=/root/mbr_images/myBootMBR_466
* dd if=/dev/hda bs=1 count=66 skip=446 of=/root/mbr_images/myPartitionsMBR_66
# dd if=/dev/hda bs=1 count=66 skip=446 of=/root/mbr_images/myPartitionsMBR_66</pre>
(vedere http://lists.pluto.it/pipermail/pluto-help/2004-December/019117.html).
(vedere http://lists.pluto.it/pipermail/pluto-help/2004-December/019117.html).
Insomma, l'ideale sarebbe avere proprio un altro disco completamente pulito. Tutto questo perche' se non puliamo il [[MBR]] di hda, al reboot verra' letto il Master Boot Record con lo "Stage1" di grub e poi si inchiodera' il sistema perche' i riferimenti alle rimanenti parti di grub ormai eliminato insieme alle partizioni non saranno trovati.
Insomma, l'ideale sarebbe avere proprio un altro disco completamente pulito. Tutto questo perché, se non puliamo il [[MBR]] di hda, al reboot verrà prima letto il Master Boot Record con lo "Stage1" di grub e poi si inchioderà il sistema poiché i riferimenti alle rimanenti parti di grub, ormai eliminato insieme alle partizioni, non saranno trovati.


Fatta la pulizia del [[MBR]] procediamo con un <code># reboot</code>.
Fatta la pulizia del [[MBR]] procediamo con un:
<pre># reboot</pre>.


Nel 99,99% dei casi non dovrebbe partire.
Nel 99,99% dei casi non dovrebbe partire.


== Recupero del sistema. ==
= Recupero del sistema. =


Se potete avviare da hdc come 1st boot target e scegliere la voce che abbiamo aggiunto sopra dopo <tt>### END DEBIAN AUTOMAGIC KERNELS LIST</tt> fatelo e saltate la fase successiva del floppy (oppure fatela comunque o provate entrambe le strade).
Se potete avviare da hdc come 1st boot target e scegliere la voce che abbiamo aggiunto sopra dopo <code>### END DEBIAN AUTOMAGIC KERNELS LIST</code> potete saltare la seguente parte in cui si spiega come riavviare usando un floppy disk (oppure leggetela comunque o provate entrambe le strade).


Inserire il floppy e resettone hardware; poi con grub fatto partire da floppy:
Inserire il floppy e forzate il riavvio del PC; con grub fatto partire da floppy:
<pre>
<pre>
     grub>  
     grub>  
Riga 321: Riga 324:
     grub>boot
     grub>boot
</pre>
</pre>
Dato che questa prova e' gia' stata fatta all'inizio, non dovrebbero essere novita'.
Dato che questa prova è già stata fatta all'inizio, non dovrebbero essere novità.


Copiamo le partizioni da hdc ad hda (disco nuovo), attenzione a non sbagliare:
Copiamo le partizioni da hdc ad hda (disco nuovo), attenzione a non sbagliare:
Riga 327: Riga 330:
# sfdisk -d /dev/hdc | sfdisk /dev/hda
# sfdisk -d /dev/hdc | sfdisk /dev/hda
</pre>
</pre>
potrebbe essere necessario
potrebbe essere necessario:
<pre>
<pre>
# sfdisk -d /dev/hdc | sfdisk --force /dev/hda
# sfdisk -d /dev/hdc | sfdisk --force /dev/hda
</pre>
</pre>
se non volete rischiare, ma salvare in un file per le "emergenze" (che non e' una cattiva idea)
se non volete rischiare e salvare in un file per le "emergenze" (che non è una cattiva idea):
<pre>
<pre>
# sfdisk -d /dev/hdc > /root/mbr_hdc.txt
# sfdisk -d /dev/hdc > /root/mbr_hdc.txt
Riga 337: Riga 340:
</pre>
</pre>


{{ Warningbox | Verificare per quanto sopra eventuali problemi con le partizioni
{{ Warningbox | Verificare per quanto sopra eventuali problemi con le partizioni logiche. Forse da usare sfdisk con le opzioni <code>-O e -I</code>.
logiche. Forse da usare sfdisk con le opzioni <tt>-O e -I</tt>.
Interessante anche l'opzione <code>-V -l</code> per il check delle partizioni.  
Interessante anche l'opzione <code>-V -l</code> per il check delle partizioni.  
<code>man sfdisk</code>.}}
<code>man sfdisk</code>.}}


Infine potete anche creare le partizioni manualmente con <code>fdisk /dev/hda</code>. Attenzione! Non possono essere piu' piccole di quelle su hdc altrimenti non potra' avvenire la ricostruzione del raid. Inoltre, se usate fdisk, ricordatevi di rendere avviabile la partizione che contiene /boot e marcare le partizioni del raid come type "fd".
Infine potete anche creare le partizioni manualmente con <code>fdisk /dev/hda</code>. Attenzione! Non possono essere più piccole di quelle su hdc altrimenti non potrà avvenire la ricostruzione del raid. Inoltre, se usate fdisk, ricordatevi di rendere avviabile la partizione che contiene /boot e marcare le partizioni del raid come type "fd".


Ricostruiamo il raid.
Ricostruiamo il raid.
Riga 354: Riga 356:
</pre>
</pre>


Con un occhio su /proc/mdstat per verificare la progressione della ricostruzione; in pratica alla fine appare comunque un messaggio sulla console. Ora il sistema dovrebbe essere di nuovo a posto "(UU)" per tutte le partizioni in raid.
con un occhio su <code>/proc/mdstat</code> per verificare la progressione della ricostruzione; alla fine apparirà comunque un messaggio sulla console. Ora il sistema dovrebbe essere di nuovo a posto "(UU)" per tutte le partizioni in raid.
 
{{ Warningbox | Nel caso in cui il disco hda appartenesse ad un raid funzionante, è possibile che il comando --zero-superblock restituisca l'errore ''Couldn't open /dev/hda1 for write - not zeroing''. In questo caso è necessario prima stoppare il raid e quindi azzerare il superblock, con i comandi
<pre>
# mdadm -S /dev/mdX  #mdX è il dispositivo raid riferito a /dev/hda1
# mdadm -S /dev/mdY  #mdY è il dispositivo raid riferito a /dev/hda2
# mdadm --zero-superblock /dev/hda1
eccetera
</pre>
}}
 


Infine ripristiniamo l'[[MBR]] su hda, cosa da non dimenticare.
Infine ripristiniamo l'[[MBR]] su hda, cosa da non dimenticare:
<pre>
<pre>
# grub
# grub
     (se device.map e' corretto, e' piu' veloce:
     (se device.map è corretto, è più veloce:
     grub --device-map=/boot/grub/device.map)
     grub --device-map=/boot/grub/device.map)
   grub> root (hd0,0)
   grub> root (hd0,0)
Riga 366: Riga 378:
</pre>
</pre>


'''Importante''': in console da DENTRO il sistema, MAI USARE il comando "boot" ma "quit". Il comando "boot" si usa da console attivata da floppy o nel menu.lst.
'''Importante''': in console da DENTRO il sistema, MAI USARE il comando "boot" ma "quit". Il comando "boot" si usa da console attivata da floppy o nel file <code>menu.lst</code>.


Togliere il floppy (si puo' fare subito dopo il boot).
Togliere il floppy (si può fare subito dopo il boot).


'''Reboot "prova del 9" finale.'''
'''Reboot "prova del 9" finale.'''


== Effetti ottici..... molto magnetici! ==
= Effetti ottici..... molto magnetici! =


Per non creare confusione, questa nota si trova in un paragrafo dedicato. La fase di simulazione di avaria poteva anche essere fatta in questo modo:
Per non creare confusione, questa nota si trova in un paragrafo dedicato. La fase di simulazione di avaria poteva anche essere fatta in questo modo:


Spegnamo il pc ed estraiamo hda. (si assume che il bios riesce ad avviare da hdc)
Spegniamo il pc ed estraiamo hda. (si assume che il BIOS riesca ad avviare da hdc)


Riaccendiamo; dovrebbe partire in degraded mode, tipo "(_U)" per tutte le md esistenti sui due dischi.
Riaccendiamo; dovrebbe partire in degraded mode, tipo "(_U)" per tutte le md esistenti sui due dischi.


Bene, spegnamo, rimettiamo hda e riavviamo.
Bene, spegniamo, rimettiamo hda e riavviamo.


Il raid naturalmente si riavvia sempre in degraded mode "(_U)"; poi restituiamo hda al raid attendendo il tempo necessario con un occhio su /proc/mdstat:
Il raid naturalmente si riavvia sempre in degraded mode "(_U)"; poi restituiamo hda al raid attendendo il tempo necessario con un occhio su <code>/proc/mdstat</code>:
<pre>
<pre>
       mdadm --add /dev/md0 /dev/hda1
       mdadm --add /dev/md0 /dev/hda1
Riga 391: Riga 403:
'''Curiosità:'''
'''Curiosità:'''


Rimettendo un disco facente parte di uno swap_in_raid ho notato
Rimettendo un disco facente parte di uno swap_in_raid ho notato che l'unione delle partizioni di swap_in_raid viene fatta automaticamente dal sistema (apparentemente non occorre mdadm --add), cioè il raid swap si porta automaticamente in uno stato "(UU)". Dopodiché si potranno aggiungere al raid le varie partizioni di hda aggiungendole man mano ai rispettivi md con 'mdadm --add'
che la unione delle partizioni di swap_in_raid viene fatta automaticamente dal sistema (apparentemente non occorre mdadm --add), cioe' il raid swap si porta automaticamente in uno stato "(UU)". Dopodiche' si potranno aggiungere al raid le varie partizioni di hda aggiungendole man mano ai rispettivi md con 'mdadm --add'


Sembrerebbe tutto bello, pulito e lineare.
Sembrerebbe tutto bello, pulito e lineare.
In realta' non e' cosi' banale.
In realtà non è così banale.


Ovvero, e' da spiegare perche' il raid si avvia normalmente in tutti e due i casi:
Ovvero, bisogna spiegare perché il raid si avvia normalmente in tutti e due i casi:


a) Quando spegnamo il pc, estraiamo hda, e accendiamo, nella catena grub, hd1 diventa hd0 e grub "rialloca" il sistema di boot e riesce a partire grazie ai suoi riferimenti "hd0" anche nel [[MBR]] di hdc.
a) Quando spegniamo il PC, estraiamo hda e accendiamo, nella catena grub, hd1 diventa hd0 e grub "rialloca" il sistema di boot e riesce a partire grazie ai suoi riferimenti "hd0" anche nel [[MBR]] di hdc.


b) Quando spegnamo il pc, rimettiamo hda, e riaccendiamo, il sistema va in degraded raid e "lavora" solo hdc, ma tutto il sistema di boot viene comunque letto da hda. Per questo nella procedura "pulita" abbiamo cercato "di rasare" il piu' possibile hda, proprio per non incorrere in "false partenze" che potrebbero indurre a vedere le cose in maniera distorta dal loro reale funzionamento (pero' potrebbe valere anche per chi scrive.)
b) Quando spegniamo il PC, rimettiamo hda e riaccendiamo, il sistema va in degraded raid e "lavora" solo hdc, ma tutto il sistema di boot viene comunque letto da hda. Per questo nella procedura "pulita" abbiamo cercato "di rasare" il più possibile hda, proprio per non incorrere in "false partenze" che potrebbero indurre a vedere le cose in maniera distorta dal loro reale funzionamento (però potrebbe valere anche per chi scrive.)


Per questo ho optato per il recovery via floppy. Siate metodici ed il piu' fedeli possibile alla realta' nelle prove.
Per questo ho optato per il recovery via floppy. Siate metodici e, nelle prove, il più fedeli possibile alla realtà.


== Servizi in <tt>/etc/init.d/</tt> ==
= Servizi in <code>/etc/init.d/</code> =


Il pacchetto '''<tt>mdadm</tt>''' installa '''due''' servizi, posti al solito in <tt>/etc/init.d/</tt>.
Il pacchetto '''<code>mdadm</code>''' installa '''due''' servizi, posti al solito in <code>/etc/init.d/</code>.


Il primo è <tt>mdadm</tt> (il suo file di configurazione è <tt>/etc/default/mdadm</tt>) serve per l'avvio del ''RAID monitor daemon'' in fase di boot.
Il primo è <code>mdadm</code> (il suo file di configurazione è <code>/etc/default/mdadm</code>) serve per l'avvio del ''RAID monitor daemon'' in fase di boot.


Il demone si occupa di informare sullo stato del raid l'utente root o l'utente "normale" (indicato in <tt>/etc/aliases</tt> come destinatario per la posta di root). Il suo comportamento si può configurare in <tt>/etc/default/mdadm</tt>. La notifica sullo stato del raid è particolarmente utile nell'eventualita' di un guasto ad un disco.
Il demone si occupa di informare sullo stato del raid l'utente root o l'utente "normale" (indicato in <code>/etc/aliases</code> come destinatario per la posta di root). Il suo comportamento si può configurare in <code>/etc/default/mdadm</code>. La notifica sullo stato del raid è particolarmente utile nell'eventualità di un guasto ad un disco.


Il secondo servizio è <tt>mdadm-raid</tt> (il file di configurazione è sempre <tt>/etc/default/mdadm</tt>) e serve per attivare le partizioni in raid non ancora inizializzate ed attive (descritte in <tt>/etc/mdadm/mdadm.conf</tt>). Una possibilita' potrebbe essere per esempio un raid di partizioni non attivato durante il montaggio del filesystem e quindi non descritto in /etc/fstab.
Il secondo servizio è <code>mdadm-raid</code> (il file di configurazione è sempre <code>/etc/default/mdadm</code>) e serve per attivare le partizioni in raid non ancora inizializzate ed attive (descritte in <code>/etc/mdadm/mdadm.conf</code>). Una possibilità potrebbe essere per esempio un raid di partizioni non attivato durante il montaggio del filesystem e quindi non descritto in <code>/etc/fstab</code>.


Vedere anche:
Vedere anche:
* [[SysV | Il sistema SysV per la gestione dei Runlevel]]
* [[SysV | Il sistema SysV per la gestione dei Runlevel]]


== Debian "dietro le quinte" del raid ==
= Debian: "dietro le quinte" del raid =


Alla fine di tutto questo discorso, non bisogna dimenticare che la debian toglie diverse castagne dal fuoco, e molte procedure sono automatizzate. Per esempio ci sono tanti file di config e scriptini che girano, per esempio all'aggiornamento di un kernel. Vediamone uno, che casualmente coinvolge kernel, initrd e quindi anche raid.
Alla fine di tutto questo discorso, non bisogna dimenticare che la Debian toglie diverse castagne dal fuoco e molte procedure sono automatizzate. Per esempio ci sono tanti file di config e scriptini che girano, come nel caso di un aggiornamento del kernel. Vediamone uno, che casualmente coinvolge kernel, initrd e quindi anche raid.
<pre>
<pre>
   # cat /etc/kernel-img.conf
   # cat /etc/kernel-img.conf
Riga 432: Riga 443:
   postrm_hook  = /sbin/update-grub
   postrm_hook  = /sbin/update-grub
</pre>
</pre>
uhm.... consiglio di leggersi <tt>man update-grub</tt> e <tt>man 5 kernel-img.conf</tt>  (in ''kernel-package'').
uhm.... consiglio di leggersi <code>man update-grub</code> e <code>man 5 kernel-img.conf</code>  (in ''kernel-package'').


Quanto sopra potremmo anche considerarlo "trasparente", pero' non bisogna mai dimenticarsi di esplorare il sistema e capire cosa e' coinvolto nei vari processi automatizzati di debian.
Quanto sopra potremmo anche considerarlo "trasparente", però non bisogna mai dimenticarsi di esplorare il sistema e capire cos'è coinvolto nei vari processi automatizzati di Debian.


Per esempio provare a scrivere in console "update" e poi battere TAB TAB.
Provare ad esempio a scrivere in console "update" e poi battere TAB TAB.
Li conoscete tutti?
Li conoscete tutti?
E' possibile rintracciare anche altri comandi che fanno parte del magico mondo di configurazione debian, o quanto meno e' bene sapere che esistono e darci un'occhiata, con "locate config | grep bin".
È possibile rintracciare anche altri comandi che fanno parte del magico mondo di configurazione Debian, o quanto meno è bene sapere che esistono e darci un'occhiata, con "locate config | grep bin".


== Comandi "mdadm" di maggior utilizzo ==
= Comandi "mdadm" di maggior utilizzo =
 
Per concludere, una serie di comandi "mdadm" per l'amministrazione del raid di piu' frequente utilizzo.


Per concludere, una serie di comandi "mdadm" per l'amministrazione del raid utilizzati più frequentemente:
* Cancellare informazioni "MD" dal superblocco di una partizione:
<pre>
#  mdadm --zero-superblock /dev/hdXx
</pre>
* Azzerare sempre il superblocco delle partizioni di un'unità disco prima di aggiungerle ad un raid in particolare se quelle partizioni sono già state usate in un precedente raid e quindi contengono delle informazioni che potrebbero confondere il sistema; vedere rootraiddoc.97.html.
* Rimuovere una partizione da un array:
<pre>
#  mdadm --set-faulty /dev/md1 /dev/hda1
#  mdadm --remove /dev/md1 /dev/hda1
</pre>
* Sostituire un disco guasto, o aggiunta di una partizione ad un raid:
<pre>
#  mdadm --add /dev/md1 /dev/hda1
</pre>
(le partizioni devono già esistere; questa operazione formatta e copia i dati dal disco esistente al nuovo disco)
* Creare il file mdadm.conf:
<pre>
#  echo "DEVICE /dev/hda /dev/hdc" > /etc/mdadm/mdadm.conf
#  mdadm --brief --detail --verbose /dev/md0 >> /etc/mdadm/mdadm.conf
#  mdadm --brief --detail --verbose /dev/md1 >> /etc/mdadm/mdadm.conf
</pre>
* Per fermare completamente un array:
<pre>
<pre>
- Cancellare informazioni "MD" dal superblocco di una partizione:
mdadm -S /dev/md0
  mdadm --zero-superblock /dev/hdXx
</pre>
</pre>
Azzerare sempre il superblocco delle partizioni di un'unita' disco prima di aggiungerle ad un raid in particolare se quelle partizioni sono gia' state usate in un precedente raid e quindi contengono delle informazioni che potrebbero confondere il sistema; vedere rootraiddoc.97.html.
(NB: Non è possibile farlo "da dentro" il raid)
* Ottenere informazioni sul raid:
<pre>
<pre>
- Rimuovere una partizione da un array:
mdadm --examine --scan
  mdadm --set-faulty /dev/md1 /dev/hda1
mdadm --query --detail /dev/md0
  mdadm --remove /dev/md1 /dev/hda1
# mdadm --examine --brief --scan
- Sostituire un disco guasto, o aggiungere una partizione ad un raid:
  mdadm --add /dev/md1 /dev/hda1
  (le partizioni devono gia' esistere; questa operazione formatta e copia i dati
  dal disco esistente al nuovo disco)
- Creare il file mdadm.conf:
  echo "DEVICE /dev/hda /dev/hdc" > /etc/mdadm/mdadm.conf
  mdadm --brief --detail --verbose /dev/md0 >> /etc/mdadm/mdadm.conf
  mdadm --brief --detail --verbose /dev/md1 >> /etc/mdadm/mdadm.conf
- Per fermare completamente un array:
  mdadm -S /dev/md0
    (NB: Non e' possibile farlo "da dentro" il raid)
- Ottenere informazioni sul raid:
  mdadm --examine --scan
  mdadm --query --detail /dev/md0
</pre>   
</pre>   


Sul RootRaidDoc97 c'e' un recupero veramente d'emergenza per avviare un raid dove proprio non ci sia possibilita' di avviare un supporto raid sul sistema in questione. Vedete di non trovarvi in questa situazione  :-)
Sul RootRaidDoc97 è descritta una procedura di recupero veramente d'emergenza per avviare un raid dove proprio non ci sia possibilità di avviare un supporto raid sul sistema in questione. Vedete di non trovarvi in questa situazione  :-)


== Link ==
= Link =
L'ultimo rootraiddoc.XX.html:
L'ultimo rootraiddoc.XX.html:
* http://alioth.debian.org/project/showfiles.php?group_id=30283
* http://alioth.debian.org/project/showfiles.php?group_id=30283
Riga 480: Riga 498:
* http://www.gnu.org/software/grub/
* http://www.gnu.org/software/grub/
* [[Guida_a_Grub]]
* [[Guida_a_Grub]]
The Linux Documentation Project: Software Raid Howto (il documento piu' aggiornato):
The Linux Documentation Project: Software Raid Howto (il documento più aggiornato):
* http://www.tldp.org/HOWTO/Software-RAID-HOWTO.html
* http://www.tldp.org/HOWTO/Software-RAID-HOWTO.html
* http://www.tldp.org/HOWTO/Software-RAID-HOWTO-7.html#ss7.3  
* http://www.tldp.org/HOWTO/Software-RAID-HOWTO-7.html#ss7.3  
Riga 504: Riga 522:
* http://www.midhgard.it/docs/index_en.html  
* http://www.midhgard.it/docs/index_en.html  


 
[[Categoria:Grub]][[Categoria:Hard Disk]]
--
Autore: [[Utente:Robiz|Robiz]]
[[Categoria:Sistema]]

Versione attuale delle 11:25, 22 apr 2015

Guida da adottare! Bannermv.png


Edit-clear-history.png Attenzione. Questa guida è da considerarsi abbandonata, per via del tempo trascorso dall'ultima verifica.

Potrà essere resa obsoleta, previa segnalazione sul forum, se nessuno si propone per l'adozione.


Debian-swirl.png Versioni Compatibili

Debian 3.1 "sarge"
RAID

Sommario

Durante l'installazione
  1. Generale
  2. Raid 1 ed LVM
Dopo l'installazione
  1. Generale
  2. Raid 1

Introduzione

Questa guida intende aiutare l'utente a verificare e rifinire la configurazione di un SOFTWARE-RAID-1 su Debian Sarge a seguito di un'installazione raid effettuata al momento del partizionamento, ed a verificarne l'effettiva efficacia, in caso di problemi ad uno dei due dischi, avvalendosi di grub come strumento di aiuto in casi di emergenza.

È scritto in modo semplice come controllare il proprio raid installato, come collaudare il raid simulando un guasto ad uno dei due dischi, quali problemi possono sorgere e come risolverli, in modo da essere pronti e sapere cosa fare se il guasto dovesse avvenire veramente.

Warning.png ATTENZIONE

Se però, mentre fate queste prove, il PC vi "scoppia", non potete prendervela con questa guida, mentre correzioni ed integrazioni alla presente sono ben accette.


Questa guida non tratta la migrazione raid, documentata dettagliatamente in /usr/share/doc/mdadm/rootraiddoc.97.html, anche se ci sono alcuni suggerimenti all'inizio di questo documento non presenti nel rootraiddoc.97.html che potrebbero essere di aiuto.

Da Debian Sarge, il debian-installer prevede una costruzione del raid direttamente durante la fase di partizionamento (attenzione che può anche fallire, non è al "100%" sicuro che vada a buon fine). Utilizzando l'initrd, i moduli per il raid sono ora precaricati prima del boot del sistema e pertanto non è necessario avere il supporto raid compilato nel kernel.

Warning.png ATTENZIONE

Da Debian Squeeze il boot loader di default è diventato grub2. Tutti i paragrafi di questa guida che trattano della configurazione del boot loader non sono perciò più utilizzabili.


Note sulla migrazione da un sistema non-raid ad uno raid

La migrazione da un sistema non-raid ad uno raid è ampiamente e perfettamente descritta nel documento /usr/share/doc/mdadm/rootraiddoc.97.html che contempla sia una migrazione con lilo e supporto md compilato NEL kernel, sia una migrazione con grub con supporto md NON nel kernel ma nell'initrd, ovvero l'estensione del kernel con moduli che vengono precaricati in un "ramdisk" prima di lanciare il boot vero e proprio del sistema.

A questo proposito, giusto due note che potrebbero esservi utili:

1. Migrazione di swap

Regola a prescindere da qualunque flame: SWAP VA IN RAID! Altrimenti si rischia corruzione di dati nella memoria del sistema.

La parte più "complessa" della migrazione potrebbe essere proprio la partizione di swap, che va articolata in questi passaggi:

  • commentare /etc/fstab --> swap
  • cat /proc/swaps (oppure swapon -s)
  • swapoff /dev/hd{disk}{nSWAP}
  • controllare con free.

Poi per creare swap in raid avremo

  • mkswap -c /dev/md3 (per esempio)
  • swapon md3
  • in /etc/fstab, prima in hda, poi nel raid, metteremo:
 /dev/md3  none  swap sw  0  0
2. Copiare le partizioni a "runlevel 1" o in "single" mode

Una cosa che non c'è nel RootRaidDoc97 è il suggerimento di andare in "init 1" per disattivare più servizi possibili prima di copiare da hd a md-degraded. Se decidete di farlo, ci sono diverse possibilità:

  • riavviare Lilo con "LinuxXXX single" (praticamente un init 1) oppure, ancora più drasticamente, riavviare Lilo con LinuxXXX init=/bin/bash in modo da ottenere un avvio con '/' in readonly;
  • Avere in menu.lst (grub) l'opzione "single" dopo il kernel. Se non l'avete basta duplicare una voce normale di avvio, aggiungere (recovery mode) alla fine del title, ed aggiungere single alla fine della riga del kernel. È possibile al posto di 'single' mettere anche init=/bin/bash
  • Usare una distribuzione live con supporto raid montando opportunamente le partizioni sorgenti e di destinazione.
  • senza bisogno di riavviare la macchina, digitare in un terminale il comando "telinit 1" oppure "init 1".

Già che ci siamo, ricordiamo i comandi più usati per copiare da non-raid a raid:

# cp -axu  /  /mnt/md0 

O, alternativamente, si può copiare il root system con find in pipe a cpio, così:

# cd /
# find . -xdev -print | cpio -dvpm /mnt/md0

o anche:

# find . -xdev -print0 | cpio -0pdvum --sparse /mnt

Per il resto delle istruzioni vale quanto scritto nel RootRaidDoc.97.html.

Occupiamoci ora del raid già funzionante della nostra cara Debian.

Files di una Debian installata direttamente in raid.

Si suppone un sw-raid-1 hda + hdc con almeno due partizioni in raid cioè root ( / ) e swap. Il bootloader grub è stato installato nel MBR di hda durante l'installazione. Se avete optato per una installazione raid con il debian-installer al momento del partizionamento e tutto è andato a buon fine, mamma Debian dovrebbe aver fatto quasi tutto il lavoro per voi.

Quasi.

Quello che manca di sicuro è l'installazione di grub del MBR sul secondo disco (Trattata avanti, da lèggere!!). Inoltre è compito dell'amministratore vedere che tutti gli altri parametri nei vari file siano stati assegnati correttamente verificandoli.

Vediamo alcune differenze nei file di configurazione tra un sistema non-raid ed uno raid.

  • Verifica delle unità riconosciute da grub:
Non raid:
    cat /boot/grub/device.map
    (hd0)   /dev/hda
  Raid:
    cat /boot/grub/device.map
    (hd0)   /dev/hda
    (hd1)   /dev/hdc
  • Parti rilevanti diverse in /boot/grub/menu.lst:
Non Raid:
    # kopt=root=/dev/hda1 ro
  - Una voce esempio:    
    title           Debian GNU/Linux, kernel 2.6.8-2-386
    root            (hd0,0)
    kernel          /boot/vmlinuz-2.6.8-2-386 root=/dev/hda1 ro
    initrd          /boot/initrd.img-2.6.8-2-386
    savedefault
    boot
  Raid:
    # kopt=root=/dev/md0 ro
  - Una voce esempio:    
    title           Debian GNU/Linux, kernel 2.6.8-2-386
    root            (hd0,0)
    kernel          /boot/vmlinuz-2.6.8-2-386 root=/dev/md0 ro
    initrd          /boot/initrd.img-2.6.8-2-386
    savedefault
    boot
  • Il file "script" dentro initrd:
Non Raid:
    NO-raid:~# cd /tmp/
    NO-raid:/tmp# mkdir checkRD
    NO-raid:/tmp# cd checkRD
    NO-raid:/tmp/checkRD# cp /boot/initrd.img-2.6.8-2-386 .
    NO-raid:/tmp/checkRD# mkdir RD
    NO-raid:/tmp/checkRD# mount -t cramfs initrd.img-2.6.8-2-386 RD -o loop
    NO-raid:/tmp/checkRD# cat RD/script
      unload_unused_ide '' pdc202xx_new ecc.ecc.ecc.
      ROOT=/dev/hda1
    NO-raid:/tmp/checkRD# umount RD
    
  Raid:
    SI-raid:~# cd /tmp/
    SI-raid:/tmp# mkdir checkRD
    SI-raid:/tmp# cd checkRD/
    SI-raid:/tmp/checkRD# cp /boot/initrd.img-2.6.8-2-386 .
    SI-raid:/tmp/checkRD# mkdir RD
    SI-raid:/tmp/checkRD# mount -t cramfs initrd.img-2.6.8-2-386 RD -o loop
    SI-raid:/tmp/checkRD# cat RD/script
      unload_unused_ide '' pdc202xx_new ecc.ecc.ecc.ecc.
      mdadm -A /dev/md1 -R -u 98533c90:d9371f7f:81d1ed14:52ac901a 
               /dev/hda2 /dev/hdc2 
      ROOT=/dev/md0
      mdadm -A /dev/md0 -R -u 1b1d819d:1d22603a:9be3ef56:bbdb1083 
               /dev/hda1 /dev/hdc1
    SI-raid:/tmp/checkRD# umount RD
  • Il file /etc/mdadm/mdadm.conf:
Raid:
    DEVICE partitions
    ARRAY /dev/md1 level=raid1 num-devices=2 UUID=42b38c30:b5f7607b:
                       a1816991:4e0bdf0f devices=/dev/hda2,/dev/hdc2
    ARRAY /dev/md0 level=raid1 num-devices=2 UUID=1b1d819d:1d22603a:
                       9be3ef56:bbdb1083 devices=/dev/hda1,/dev/hdc1

Comunque, a parte l'installazione di grub anche nel secondo MBR (quello di hdc), da fare a manina e testare, la Debian dovrebbe aver fatto tutto il lavoro di costruzione opportuno e la configurazione precisa di tutti i file citati sopra durante la costruzione dell'initrd per il raid e la configurazione di grub per l'avvio in raid con kernel e initrd caricati da hda.

Grub sul Master Boot Record del secondo disco in raid.

Dovendo installare su entrambi i dischi grub nel MBR per far avviare un raid con un solo disco, qualunque dei due esso possa essere, il classico problema è assicurarsi che possa partire da hda o da hdc in caso di guasto di uno dei due dischi, sempre ammesso che il BIOS supporti l'avvio da più dischi e sia possibile specificarne l'ordine di boot. Per esempio prima "hdc" e poi "hda", cosa ottimale, auspicabile, ma alla fine, come vedremo, non indispensabile.

Veniamo al primo punto, ovvero installare grub anche nel MBR di hdc, cosa che rappresenta il 99% delle operazioni da fare su un sistema raid appena avviato. In "letteratura" si trovano sostanzialmente due tipi di procedure suggerite; la prima, più diffusa e avvalorata anche dal Software-Raid-HOWTO (tldp.org), consiste nell'inserire nel MBR di hdc la stessa configurazione del MBR di hda, confidando nel fatto che quando dovesse mancare hda, hdc in qualche modo prenderebbe il posto di hda e automagicamente tutto dovrebbe andare; vedremo poi, che proprio così non è. Comunque, dato che male non fa, è la procedura che consiglio pure io di attuare, ovvero:

Procedura1
In console:
   # grub
             (se avete /boot/grub/device.map corretto, usate
                 grub --device-map /boot/grup/device.map
              perché è molto più veloce)
    >> grub> device (hd0) /dev/hdc
    >> grub> root (hd0,0)
    >> grub> setup (hd0)
    >> grub> quit

Fatto. Ora il sistema è in grado di avviarsi anche da hdc se il BIOS lo permette. Ma questo lo avete provato prima di fare il raid, vero? (Ripeto però, non è indispensabile).

Poi c'è la seconda procedura:

Procedura2
In console:
   # grub --device-map=/boot/grub/device.map
    >> root (hd0,0)
    >> setup (hd0)
    >> root (hd1,0)
    >> setup (hd1)
    >> quit 

Che assegna in maniera "democratica" a tutti e due gli MBR la stessa configurazione di grub/menu.lst.

In pratica i due metodi dovrebbero essere equivalenti, in teoria non lo so e non lo ho trovato scritto da nessuna parte (e se stava scritto non l'ho capito forse). O meglio, da quello che ho letto, il comando "device" utilizzato nella prima procedura con grub dovrebbe essere usato nel caso non vi sia un valido /boot/grub/devices.map (e non è il nostro caso) mentre sembra venga utilizzato solamente per "ingannare" temporaneamente sulla destinazione del Master Boot Record dove verrà installato grub. Concorderete che la seconda procedura sembra molto più chiara, anche se le prove mi dicono che pure questo secondo metodo non è esente da problemi in caso di guasto di uno dei due dischi del raid (in particolare del primo - hda).

Post-installazione Raid.

Una volta tirato su il raid con migrazione o durante l'installazione assieme al partizionamento,

Prima di tutto fate un disco grub per qualsiasi evenienza: grub-floppy /dev/fd0.

Grub-floppy è un utility del pacchetto Debian di grub, ma esiste ampia documentazione che spiega a costruirne uno anche manualmente mettendo sul floppy i file giusti nella sequenza ed al posto giusto (ad es. vedi Guida a Grub). Esiste anche documentazione per prepararsi un grub avviabile da cd.

Usate tutti i riferimenti nel /boot/grub/menu.lst riferendovi ad hd0 e /dev/mdX (in realtà dovrebbero già esserci, messi in automatico durante l'installazione).

Clonate l'MBR secondo la "procedura1" di cloning. Se avete dubbi potete usare anche la "procedura2", entrambi descritte in precedenza.

Warning.png ATTENZIONE
A raid funzionante, è importantissimo che proviate ad avviare il raid da hdc con il floppy


Prova di funzionamento:

  • Inserire il floppy di recupero grub
  • Riavviare il PC
  • Se l'ordine di boot nel bios è corretto, verrà intercettato il floppy e avviato grub che ci fornirà una potente console di avvio. Scriviamo nell'ordine (adattando, al caso):
   grub> 
    1. grub>root (hd1,0)
    2. grub>kernel /boot/vmlinuz-2.6.8-blabla root=/dev/md0 ro
    3. grub>initrd /boot/initrd-2.6.8-blabla
    4. grub>boot
Spieghiamo:
1
diciamo a grub la partizione dove si trova /boot (non "/" !!!)
Warning.png ATTENZIONE
Se non ci fosse il disco in hda, e vorreste avviare da hdc,

per la questione della "catena grub" che viene scalata in mancanza di un'unità elencata in devices.map, dovreste mettere "root (hd0,0)" !!!


2
diciamo dove si trova il kernel (funziona anche il l'autocompletamento con TAB)
3
diciamo dove si trova l'initrd
4
diciamo a grub, caricato kernel e initrd, di avviare il sistema.

Se il sistema si avvia, abbiamo tutto quello che ci serve.

Avaria di uno dei due dischi in raid.

Vediamo invece problematiche di raid boot quando uno dei dischi provoca un degraded raid a seconda se è hda, hdc, oppure se manca hda o hdc, oppure se si ripristina un hda o hdc, e cosa fare se il raid in qualunque di queste condizioni non dovesse partire.

Se il raid va in degraded mode ed il disco incriminato è hdc ovvero /proc/mdstat indica "(U_)", non ci sono grandi problemi. Il boot naturale su hda è sempre lì; si può avviare un sistema con un disco solo o cambiare hdc, partizionare il disco nuovo, e ripristinare facilmente il raid.

Se invece il raid va in degraded mode ed il disco incriminato è hda "(_U)", allora qualche problema potrebbe anche esserci, ma anche soluzioni, per fortuna.

Per esempio se togliete fisicamente hda dopo averlo marcato 'failed' e rimosso, e lasciate il raid con solo hdc, la "procedura1" di cloning del MBR sopperisce perfettamente al problema, in quanto grub usa una "catena" di dischi, e non trovando hd0, hd1 diventa hd0 e, se il bios permette il boot di hdc, allora il raid partirà anche col solo disco hdc. Questa cosa potrebbe funzionare e sarebbe vincolata solo al bios-hardware.

Però non finisce qua: nel momento in cui andate ad inserire un disco vuoto nuovo in hda senza MBR e partizioni, o peggio magari con un MBR già usato, o con altre partizioni contenenti un altro sistema, è molto probabile che: o non parta niente, o parta il sistema che non c'entra niente e che si trova su hda (a me è capitato di veder partire un GAG). Per capirci, anche riuscendo a settare il BIOS con hdc come 1st boot target, non è detto che il sistema faccia il boot perché, ammesso che appaia il menù di grub, si dovrebbero modificare "al volo" i riferimenti di root (/boot) da hd0 a hd1. Per eseguire questa operazione occorre che appaia il menù di grub, dopodiché ci si posiziona sulla voce del menù che si vuole temporaneamente modificare e si preme il tasto "e" (il tasto "c" vi restituisce la console di grub); si modifica la root di grub da (hd0,0) a (hd1,0) e si preme il tasto "b" per continuare con il boot. Questa procedura appena descritta è l'ultima possibilità che resta per avviare un raid degraded "(_U)" da hdc, ovvero con l'aiuto del BIOS, intervenendo al volo su grub e senza usare il floppy disk.

In realtà, se si riesce a far partire il disco da hdc come 1st boot target del BIOS, basterebbe avere nel file /boot/grub/menu.lst delle righe simili alle seguenti, in grado di far fronte alla precedente evenienza:

title        Debian GNU/Linux, kernel 2.6.8-2-686 HD1 BOOT 
root         (hd1,0)
kernel       /boot/vmlinuz-2.6.8-2-686 root=/dev/md0 ro
initrd       /boot/initrd.img-2.6.8-2-686
savedefault
boot

In questo caso occorrerebbe fare attenzione al fatto che il comandoupdate-grub, che viene eseguito dopo l'installazione di nuovi kernel, creerebbe un nuovo menu.lst facendo sparire tutte le modifiche apportate manualmente, perlomeno quelle tra:

 ### BEGIN AUTOMAGIC KERNELS LIST

e

 ### END DEBIAN AUTOMAGIC KERNELS LIST

per cui attenzione a porre le personalizzazioni di menu.lst fuori da questo blocco. In caso di problemi sappiate che update-grub salva una copia di backup del /boot/grub/menu.lst in /boot/grub/menu.lst~. Per ulteriori info leggete la Guida a Grub, man update-grub e /etc/kernel-img.conf. Per stare tranquilli è consigliabile fare una copia di menu.lst e verificare i vari file dopo ogni installazione di qualche nuovo kernel (alla debian-way ovviamente).

Vedremo più avanti durante la fase di test del raid altri tipi di problemi che possono sorgere.

Simulazione di avaria di un disco e sua sostituzione.

A raid funzionante dove /proc/mdstat --> "(UU)" per tutte le partizioni usate nel raid, mandiamo in avaria simulata il disco hda.

Se il vostro BIOS permette di far avviare hdc come 1st boot target aggiungete pure queste righe dopo ### END DEBIAN AUTOMAGIC KERNELS LIST in /boot/grub/menu.lst:

   title        Debian GNU/Linux, kernel 2.6.8-2-686 HD1 BOOT 
   root         (hd1,0)
   kernel       /boot/vmlinuz-2.6.8-2-686 root=/dev/md0 ro
   initrd       /boot/initrd.img-2.6.8-2-686
   savedefault
   boot

Ora la sequenza di comandi:

	 
#  mdadm --set-faulty /dev/md0 /dev/hda1     ( --> "/" )
#  mdadm --remove /dev/md1 /dev/hda1
#  mdadm --set-faulty /dev/md1 /dev/hda2     ( --> "swap" )
#  mdadm --remove /dev/md1 /dev/hda1

Ripetere per eventuali altre partizioni.

A questo punto siamo in "(_U)" con tutte le partizioni del raid (verificare con cat /proc/mdstat).

Ora che il raid è in degraded mode, senza riavviare, diamo un bel:

# cfdisk /dev/hda

e CANCELLIAMO TUTTE LE PARTIZIONI.

Per essere sicuri che il disco sia completamente pulito, dovremmo vuotare di ogni suo contenuto anche l'MBR usando un sistema brutale ma efficace, ovvero un comando del tipo:

# dd if=/dev/zero of=/dev/hda bs=512 count=1

Però occorre fare attenzione! La struttura del MBR è la seguente:

466 bytes : codice boot
 64 bytes : tabella partizioni
  2 bytes : "magic number 55AA" 

Pertanto, a seconda di come vorrete condurre le prove, potrebbe essere che vi basti eliminare il codice boot e salvaguardare la tabella delle partizioni; quindi sarebbe sufficiente:

# dd if=/dev/zero of=/dev/hda bs=466 count=1

Un modo più prudente di procedere contemplerebbe il salvataggio dei dati che state per cancellare, quindi un backup di sicurezza non sarebbe male:

# dd if=/dev/hda bs=512 count=1 of=/root/mbr_images/myFullMBR_512
# dd if=/dev/hda bs=466 count=1 of=/root/mbr_images/myBootMBR_466
# dd if=/dev/hda bs=1 count=66 skip=446 of=/root/mbr_images/myPartitionsMBR_66

(vedere http://lists.pluto.it/pipermail/pluto-help/2004-December/019117.html). Insomma, l'ideale sarebbe avere proprio un altro disco completamente pulito. Tutto questo perché, se non puliamo il MBR di hda, al reboot verrà prima letto il Master Boot Record con lo "Stage1" di grub e poi si inchioderà il sistema poiché i riferimenti alle rimanenti parti di grub, ormai eliminato insieme alle partizioni, non saranno trovati.

Fatta la pulizia del MBR procediamo con un:

# reboot

.

Nel 99,99% dei casi non dovrebbe partire.

Recupero del sistema.

Se potete avviare da hdc come 1st boot target e scegliere la voce che abbiamo aggiunto sopra dopo ### END DEBIAN AUTOMAGIC KERNELS LIST potete saltare la seguente parte in cui si spiega come riavviare usando un floppy disk (oppure leggetela comunque o provate entrambe le strade).

Inserire il floppy e forzate il riavvio del PC; con grub fatto partire da floppy:

    grub> 
    grub>root (hd1,0)
    grub>kernel /boot/vmlinuz-2.6.8-blabla root=/dev/md0 ro
    grub>initrd /boot/initrd-2.6.8-blabla
    grub>boot

Dato che questa prova è già stata fatta all'inizio, non dovrebbero essere novità.

Copiamo le partizioni da hdc ad hda (disco nuovo), attenzione a non sbagliare:

# sfdisk -d /dev/hdc | sfdisk /dev/hda

potrebbe essere necessario:

# sfdisk -d /dev/hdc | sfdisk --force /dev/hda

se non volete rischiare e salvare in un file per le "emergenze" (che non è una cattiva idea):

# sfdisk -d /dev/hdc > /root/mbr_hdc.txt
# sfdisk /dev/hda < /root/mbr_hdc.txt
Warning.png ATTENZIONE
Verificare per quanto sopra eventuali problemi con le partizioni logiche. Forse da usare sfdisk con le opzioni -O e -I.

Interessante anche l'opzione -V -l per il check delle partizioni. man sfdisk.


Infine potete anche creare le partizioni manualmente con fdisk /dev/hda. Attenzione! Non possono essere più piccole di quelle su hdc altrimenti non potrà avvenire la ricostruzione del raid. Inoltre, se usate fdisk, ricordatevi di rendere avviabile la partizione che contiene /boot e marcare le partizioni del raid come type "fd".

Ricostruiamo il raid.

  # mdadm --zero-superblock /dev/hda1
  # mdadm --zero-superblock /dev/hda2
  # mdadm --add /dev/md0 /dev/hda1
  # mdadm --add /dev/md1 /dev/hda2

  Ripetere per eventuali altre partizioni.

con un occhio su /proc/mdstat per verificare la progressione della ricostruzione; alla fine apparirà comunque un messaggio sulla console. Ora il sistema dovrebbe essere di nuovo a posto "(UU)" per tutte le partizioni in raid.

Warning.png ATTENZIONE
Nel caso in cui il disco hda appartenesse ad un raid funzionante, è possibile che il comando --zero-superblock restituisca l'errore Couldn't open /dev/hda1 for write - not zeroing. In questo caso è necessario prima stoppare il raid e quindi azzerare il superblock, con i comandi
# mdadm -S /dev/mdX  #mdX è il dispositivo raid riferito a /dev/hda1
# mdadm -S /dev/mdY  #mdY è il dispositivo raid riferito a /dev/hda2
# mdadm --zero-superblock /dev/hda1
eccetera



Infine ripristiniamo l'MBR su hda, cosa da non dimenticare:

# grub
    (se device.map è corretto, è più veloce:
    grub --device-map=/boot/grub/device.map)
  grub> root (hd0,0)
  grub> setup (hd0)
  grub> quit

Importante: in console da DENTRO il sistema, MAI USARE il comando "boot" ma "quit". Il comando "boot" si usa da console attivata da floppy o nel file menu.lst.

Togliere il floppy (si può fare subito dopo il boot).

Reboot "prova del 9" finale.

Effetti ottici..... molto magnetici!

Per non creare confusione, questa nota si trova in un paragrafo dedicato. La fase di simulazione di avaria poteva anche essere fatta in questo modo:

Spegniamo il pc ed estraiamo hda. (si assume che il BIOS riesca ad avviare da hdc)

Riaccendiamo; dovrebbe partire in degraded mode, tipo "(_U)" per tutte le md esistenti sui due dischi.

Bene, spegniamo, rimettiamo hda e riavviamo.

Il raid naturalmente si riavvia sempre in degraded mode "(_U)"; poi restituiamo hda al raid attendendo il tempo necessario con un occhio su /proc/mdstat:

      mdadm --add /dev/md0 /dev/hda1
      mdadm --add /dev/md1 /dev/hda2
      ecc.ecc.

Curiosità:

Rimettendo un disco facente parte di uno swap_in_raid ho notato che l'unione delle partizioni di swap_in_raid viene fatta automaticamente dal sistema (apparentemente non occorre mdadm --add), cioè il raid swap si porta automaticamente in uno stato "(UU)". Dopodiché si potranno aggiungere al raid le varie partizioni di hda aggiungendole man mano ai rispettivi md con 'mdadm --add'

Sembrerebbe tutto bello, pulito e lineare. In realtà non è così banale.

Ovvero, bisogna spiegare perché il raid si avvia normalmente in tutti e due i casi:

a) Quando spegniamo il PC, estraiamo hda e accendiamo, nella catena grub, hd1 diventa hd0 e grub "rialloca" il sistema di boot e riesce a partire grazie ai suoi riferimenti "hd0" anche nel MBR di hdc.

b) Quando spegniamo il PC, rimettiamo hda e riaccendiamo, il sistema va in degraded raid e "lavora" solo hdc, ma tutto il sistema di boot viene comunque letto da hda. Per questo nella procedura "pulita" abbiamo cercato "di rasare" il più possibile hda, proprio per non incorrere in "false partenze" che potrebbero indurre a vedere le cose in maniera distorta dal loro reale funzionamento (però potrebbe valere anche per chi scrive.)

Per questo ho optato per il recovery via floppy. Siate metodici e, nelle prove, il più fedeli possibile alla realtà.

Servizi in /etc/init.d/

Il pacchetto mdadm installa due servizi, posti al solito in /etc/init.d/.

Il primo è mdadm (il suo file di configurazione è /etc/default/mdadm) serve per l'avvio del RAID monitor daemon in fase di boot.

Il demone si occupa di informare sullo stato del raid l'utente root o l'utente "normale" (indicato in /etc/aliases come destinatario per la posta di root). Il suo comportamento si può configurare in /etc/default/mdadm. La notifica sullo stato del raid è particolarmente utile nell'eventualità di un guasto ad un disco.

Il secondo servizio è mdadm-raid (il file di configurazione è sempre /etc/default/mdadm) e serve per attivare le partizioni in raid non ancora inizializzate ed attive (descritte in /etc/mdadm/mdadm.conf). Una possibilità potrebbe essere per esempio un raid di partizioni non attivato durante il montaggio del filesystem e quindi non descritto in /etc/fstab.

Vedere anche:

Debian: "dietro le quinte" del raid

Alla fine di tutto questo discorso, non bisogna dimenticare che la Debian toglie diverse castagne dal fuoco e molte procedure sono automatizzate. Per esempio ci sono tanti file di config e scriptini che girano, come nel caso di un aggiornamento del kernel. Vediamone uno, che casualmente coinvolge kernel, initrd e quindi anche raid.

  # cat /etc/kernel-img.conf
  do_symlinks = yes
  relative_links = yes
  do_bootloader = no
  do_bootfloppy = no
  do_initrd = yes
  link_in_boot = no
  postinst_hook = /sbin/update-grub
  postrm_hook   = /sbin/update-grub

uhm.... consiglio di leggersi man update-grub e man 5 kernel-img.conf (in kernel-package).

Quanto sopra potremmo anche considerarlo "trasparente", però non bisogna mai dimenticarsi di esplorare il sistema e capire cos'è coinvolto nei vari processi automatizzati di Debian.

Provare ad esempio a scrivere in console "update" e poi battere TAB TAB. Li conoscete tutti? È possibile rintracciare anche altri comandi che fanno parte del magico mondo di configurazione Debian, o quanto meno è bene sapere che esistono e darci un'occhiata, con "locate config | grep bin".

Comandi "mdadm" di maggior utilizzo

Per concludere, una serie di comandi "mdadm" per l'amministrazione del raid utilizzati più frequentemente:

  • Cancellare informazioni "MD" dal superblocco di una partizione:
#  mdadm --zero-superblock /dev/hdXx
  • Azzerare sempre il superblocco delle partizioni di un'unità disco prima di aggiungerle ad un raid in particolare se quelle partizioni sono già state usate in un precedente raid e quindi contengono delle informazioni che potrebbero confondere il sistema; vedere rootraiddoc.97.html.
  • Rimuovere una partizione da un array:
#  mdadm --set-faulty /dev/md1 /dev/hda1
#  mdadm --remove /dev/md1 /dev/hda1
  • Sostituire un disco guasto, o aggiunta di una partizione ad un raid:
#  mdadm --add /dev/md1 /dev/hda1

(le partizioni devono già esistere; questa operazione formatta e copia i dati dal disco esistente al nuovo disco)

  • Creare il file mdadm.conf:
#  echo "DEVICE /dev/hda /dev/hdc" > /etc/mdadm/mdadm.conf
#  mdadm --brief --detail --verbose /dev/md0 >> /etc/mdadm/mdadm.conf
#  mdadm --brief --detail --verbose /dev/md1 >> /etc/mdadm/mdadm.conf
  • Per fermare completamente un array:
#  mdadm -S /dev/md0

(NB: Non è possibile farlo "da dentro" il raid)

  • Ottenere informazioni sul raid:
#  mdadm --examine --scan
#  mdadm --query --detail /dev/md0
# mdadm --examine --brief --scan

Sul RootRaidDoc97 è descritta una procedura di recupero veramente d'emergenza per avviare un raid là dove proprio non ci sia possibilità di avviare un supporto raid sul sistema in questione. Vedete di non trovarvi in questa situazione  :-)

Link

L'ultimo rootraiddoc.XX.html:

Mdadm e Grub

The Linux Documentation Project: Software Raid Howto (il documento più aggiornato):

Grub + Raid e discussione sulla "clonazione" del MBR da hda ad hdc:

Articolo da "debian-administration" ed un suo aggiornamento entrambi con ampie discussioni:

Altre guide relative a "migrazione" su software-raid:

Quando il gioco si fa duro: Root-on-LVM-on-RAID HOWTO