Nel momento nell'imprevisto si può agire solo se si è stati previdenti, pensando ai tipi di situazioni che si possono presentare e preparando gli strumenti necessari in anticipo. Le copie di sicurezza sono la prima cosa da fare per prepararsi ai guai, ma da sole non bastano: occorrono altri strumenti per rimettere in sesto un sistema prima di poter effettuare un eventuale recupero dalle copie.
Di fronte a un qualunque problema di una gravità tale da non permettere l'avvio di un sistema locale, l'unica possibilità di intervenire è data da strumenti su dischetti. Esistono diversi tipi di dischetti che possono essere stati preparati in precedenza:
Un dischetto di avvio può essere utile quando, per qualche motivo, il sistema di boot normale non funziona più. Esistono almeno tre tipi di dischetti di questo tipo:
La prima soluzione, quella del dischetto senza kernel, non è adatta ad avviare un sistema in difficoltà: è solo un modo per verificare una configurazione di LILO quando non si vuole interferire con l'MBR del disco fisso. In pratica si ottiene semplicemente indicando nel file /etc/lilo.conf la riga boot=/dev/fd0, come nell'esempio seguente.
boot=/dev/fd0
prompt
timeout=50
image=/boot/vmlinuz
label=linux
root=/dev/hda2
read-only
Quando viene avviato lilo con questa configurazione, si ottiene la scrittura del primo settore del primo dischetto (il dischetto deve essere stato inizializzato in precedenza, ma può anche non contenere alcun filesystem). Ma i file del boot si intende che si trovino nella directory /boot/ del momento in cui si esegue lilo, e quindi nel filesystem in funzione in quel momento e non nel dischetto. Inoltre, anche il kernel /boot/vmlinuz si intende contenuto in quel filesystem e non nel dischetto.
Nel momento dell'avvio con un dischetto fatto in questo modo, il programma contenuto nel primo settore va alla ricerca dei file di boot e del kernel che si trovavano nel disco fisso nel momento dell'utilizzo del programma lilo.
Se il sistema non si avvia perché i file di boot o il kernel è stato spostato, a nulla serve un dischetto fatto in questo modo.
Per fare in modo che il dischetto avvii un kernel contenuto al suo interno, è necessario che questo dischetto contenga un filesystem, che vi sia stata copiata la directory /boot/ con il suo contenuto, e che prima dell'avvio del programma lilo, la directory /boot/ contenuta nel filesystem in funzione, sia stata temporaneamente sostituita con un link simbolico che punti a quella del dischetto. Questa tecnica è stata descritta nella sezione `LILO su un dischetto'.
Rispetto alla prossima tecnica, un dischetto contenente LILO e il kernel, come appena descritto, è uno strumento di avvio più completo perché permette di specificare, attraverso la configurazione del file /etc/lilo.conf, alcuni parametri di boot particolari del quale il proprio sistema potrebbe avere bisogno.
L'ultima possibilità è la più semplice e, sotto questo aspetto, la più sicura: il file del kernel viene copiato sul dispositivo del dischetto, senza fare uso di alcun filesystem. Si può utilizzare uno dei due modi seguenti.
# cp vmlinuz /dev/fd0
# dd if=vmlinuz of=/dev/fd0
Evidentemente, il file del kernel è speciale perché riesce ad avviare se stesso. Il kernel da solo, potrebbe però non sapere quale dispositivo contiene il filesystem root da montare al momento dell'avvio. È necessario utilizzare il programma rdev per inserire questa e altre notizie nel kernel.
Supponendo che si debba avviare la partizione /dev/hda2, inizialmente in sola lettura, si procede come segue per fare queste annotazioni in un kernel copiato in un dispositivo /dev/fd0.
# rdev /dev/fd0 /dev/hda2
# rdev -R /dev/fd0 1
I dischetti di installazione di un distribuzione Linux, sono solitamente indicati come un possibile strumento per avviare un computer in difficoltà e sistemare la sua configurazione.
Quando si utilizzano distribuzioni sofisticate e particolarmente ``amichevoli'' nei confronti dell'utilizzatore inesperto, questi dischetti sono organizzati ottimamente per l'installazione di Linux e non per il loro utilizzo fuori dagli schemi. Di fatto, questi sono sicuramente adatti a rifare una mini installazione di Linux, con la quale poi si può procedere a un recupero delle copie di sicurezza (che si spera siano state fatte in precedenza).
Esiste tuttavia un eccezione a questa situazione generale: i dischetti di avvio della distribuzione Slackware. Questa distribuzione è stata una delle prime, e i sui strumenti di installazione sono rimasti piuttosto rudimentali. In questo senso, i suoi dischetti di avvio per l'installazione sono ancora abbastanza generici da presentarsi realmente come dei sistemi Linux in miniatura.
Ogni sistema ha le proprie caratteristiche ed esigenze. I dischetti di emergenza preparati da altri, oppure ottenuti da una distribuzione Linux, possono adattarsi a un certo insieme di situazioni, ma non a tutte.
Quando si vuole essere sicuri di avere gli strumenti giusti al momento giusto, occorre che questi siano stati preparati e collaudati bene, in modo da non sprecare tempo inutilmente.
In sostanza, la realizzazione o la personalizzazione di dischetti di emergenza è la tappa obbligata per chi vuole amministrare seriamente il proprio sistema.
L'utilizzo di dischetti di emergenza preparati da altri è un buon punto di partenza, ma le particolarità che ogni sistema può avere consigliano almeno una personalizzazione del kernel.
Per poter costruire o almeno personalizzare dei dischetti di emergenza è particolarmente utile attivare nel kernel la gestione diretta delle immagini di questi: CONFIG_BLK_DEV_LOOP Loopback device support ( `Loopback device support').
In questo modo, un'immagine non compressa di un dischetto può essere montata con un comando simile a quello seguente.
mount
-o loop -t <tipo-di-filesystem> <file-immagine> <mount-point>
Un filesystem root può essere caricato in memoria centrale (RAM) e montato da lì. Si ottiene un cosiddetto ramdisk. A parte ogni considerazione sui vantaggi che questo può avere nelle prestazioni del sistema, si tratta di una modalità quasi obbligata per l'utilizzo di dischetti di emergenza. Infatti, un ramdisk può essere ottenuto a partire da una immagine compressa: è il kernel stesso che la espande in memoria all'atto del caricamento. Quindi, si può fare stare in un dischetto una immagine di dimensioni superiori alla sua capacità.
Oltre a questo vantaggio, che però richiede la presenza di molta memoria RAM, un dischetto contenente un filesystem root trasferito nella RAM può essere subito rimosso, permettendo il riutilizzo dell'unità a dischetti, magari per accedere ad altri programmi di utilità non inclusi nel ramdisk.
Per la gestione di un ramdisk occorre che il kernel sia appositamente configurato: CONFIG_BLK_DEV_RAM RAM disk support ( `RAM disk support').
Quando il kernel carica un ramdisk da un'immagine contenuta in un dischetto, deve conoscere la posizione di inizio di questa immagine. Ciò è importante quando sia il kernel che l'immagine da caricare risiedono nello stesso dischetto. Quando l'immagine da caricare nel ramdisk è contenuta in un dischetto separato, questa sarà normalmente contenuta a partire dall'inizio di questo, cioè dall'offset zero.
I dischetti root della distribuzione Slackware sono il più semplici ed efficaci in situazioni di emergenza. Per essere avviati necessitano di un dischetto di boot contenente il kernel, ma questo può essere eventualmente predisposto localmente in modo da avere a disposizione la configurazione più adatta al proprio sistema.
Questi dischetti sono normalmente reperibili presso gli indirizzi seguenti.
ftp://sunsite.unc.edu/pub/Linux/distributions/slackware/rootdsks
ftp://sunsite.unc.edu/pub/Linux/distributions/slackware/bootdsks.144
Il dischetto di root migliore per la soluzione di problemi è rappresentato dall'immagine compressa rescue.gz. Se si intende utilizzare anche un dischetto di boot ottenuto dalla distribuzione, occorre sceglierlo in base alle indicazioni che si trovano nei file di testo inclusi nelle directory indicate.
L'immagine rootdsks/rescue.gz è compressa, come si vede dall'estensione, e può essere decompressa prima della copia nel dischetto di destinazione, dato che la sua dimensione normale corrisponde proprio a un dischetto da 1440KB. Questo fatto è molto importante, perché il dischetto che si ottiene copiandovi sopra una immagine non compressa può essere montato senza il bisogno di creare un ramdisk. Quindi, un dischetto del genere è indicato anche per computer con poca memoria RAM a disposizione.
Come già accennato, la distribuzione Slackware mette a disposizione immagini di dischetti boot, contenenti essenzialmente il kernel, e root contenenti il filesystem root.
Le immagini di boot sono dischetti Minix normali, contenenti un settore di avvio, la directory /boot/ e il kernel. Si tratta in pratica di dischetti realizzati in modo analogo a quanto descritto nella precedente sezione `Dischetti di avvio', quando si faceva riferimento a dischetti contenenti questi elementi.
Le immagini di questi dischetti, anche se non sono di dimensioni pari a quelle di un dischetto normale, non sono compresse e si possono copiare semplicemente sul dispositivo del dischetto di destinazione.
# dd if=net.i of=/dev/fd0
Le immagini di root sono invece dischetti Minix da 1440KB compressi. Ciò permette loro di essere utilizzati anche a partire da dischetti da 1200KB, ma come già chiarito, ciò costringe all'uso di un ramdisk.
<!> La dimensione eccezionalmente piccola dei programmi contenuti all'interno di un dischetto root di questa distribuzione deriva dal fatto che si tratta di versioni particolarmente vecchie di questi e che in più sono ancora compilate in modalità a.out. Questo fatto va tenuto in considerazione nel caso si voglia abbinare un kernel personalizzato: deve essere in grado di funzionare con binari a.out.
Per riprodurre tali dischetti, sarebbe meglio decomprimerli per potere sfruttare la possibilità di utilizzarli con sistemi dotati di poca memoria.
# cat rescue.gz | gzip -d | dd of=/dev/fd0
Per abbinare un kernel personalizzato a un dischetto root della distribuzione Slackware, si potrebbe ricostruire un dischetto boot seguendo le stesse modalità usate dalla distribuzione stessa, oppure in maniera più semplice, copiando il kernel in un dischetto direttamente attraverso il suo dispositivo e poi intervenendo con il programma rdev. Quest'ultima è la modalità che viene descritta.
# dd if=zImage of=/dev/fd0
La copia di un kernel in un dischetto, attraverso il suo dispositivo, genera il solito dischetto di avviamento già descritto tante volte. Questo kernel su dischetto deve però essere informato di dove e come fare il boot.
Il boot viene eseguito da un dischetto, quindi attraverso rdev si scrive questo messaggio nel kernel.
# rdev /dev/fd0 /dev/fd0
I dischetti di root della distribuzione Slackware non prevedono il controllo del filesystem e il successivo mount in lettura e scrittura. In pratica, il filesystem root deve essere inizialmente in lettura-scrittura.
# rdev -R /dev/fd0 0
Infine si deve specificare che:
Per fare questo si agisce su una serie di bit configurabili attraverso rdev
con l'opzione -r:
Se si vuole utilizzare il ramdisk si deve utilizzare rdev nel modo seguente:
# rdev -r /dev/fd0 49152
infatti, 2^15 + 2^14 + 0 = 49152.
Se invece non si vuole il ramdisk si deve utilizzare rdev nel modo seguente:
# rdev -r /dev/fd0 32768
infatti, 2^15 + 0 + 0 = 32768.
Quando si configura un kernel da utilizzare assieme a dischetti di emergenza, occorre tenere presente che non è ragionevolmente possibile utilizzare i moduli, ed è importante attivare determinate caratteristiche che di solito non vengono considerate per i sistemi normali.
I dischetti di emergenza più compatti sono nel vecchio formato a.out. Il kernel deve essere stato predisposto per gestirli.
CONFIG_BINFMT_AOUT Kernel support for a.out binaries
Il filesystem più utilizzato per i dischetti di emergenza o di installazione è il Minix, anche quando si tratta di immagini compresse.
CONFIG_MINIX_FS Minix fs support
Anche se non si intende utilizzare dischetti caricati in memoria RAM, vale la pena di preparare un kernel che ne permetta anche l'utilizzo.
CONFIG_BLK_DEV_RAM RAM disk support
Un kernel per un dischetto di emergenza deve permettere la gestione della rete (TCP/IP), e in particolare, invece di attivare la gestione della porta parallela per la stampa, conviene attivare la gestione della connessione PLIP.
CONFIG_PLIP PLIP (parallel port) support
Quando si usano dei dischetti di emergenza si hanno già molte limitazioni, e a queste si aggiunge anche la scomodità di una tastiera che non combacia con quella statunitense.
Si può risolvere il problema direttamente nel kernel senza dover tentare di inserire il programma loadkeys in dischetti già troppo piccoli. È sufficiente localizzare la mappa della tastiera italiana (di solito si tratta del file it.map collocato nella directory /usr/lib/kbd/keytables/) e quindi generare il sorgente defkeymap.c. Si procede come segue.
# cd /usr/src/linux/drivers/char
# loadkeys --mktable /usr/lib/kbd/keytables/it.map > defkeymap.c
La successiva compilazione di un nuovo kernel utilizzerà la mappa italiana come predefinita e non ci sarà bisogno di utilizzare loadkeys.
Quando si ha la disponibilità di più computer, è probabile che il danno presentatosi su uno di questi non si sia riprodotto in tutti. Una piccola rete locale potrebbe essere di aiuto in situazioni di emergenza e in sua mancanza potrebbero andare bene anche dei cavi paralleli PLIP.
Questo tipo di cavo viene descritto nella appendice `Cablaggi'. La sua realizzazione non è difficile: basta un piccolo saldatore, un po' di stagno, due connettori maschi DB-25 e una piattina multipolare con almeno 13 fili. La schermatura non è necessaria.
Con i dischetti della distribuzione Slackware, preferibilmente con l'immagine resque.gz, è possibile stabilire una semplice connessione con un server NFS.
Attraverso una connessione Ethernet, con una interfaccia riconosciuta come eth0, si può agire come nell'esempio seguente. Si suppone in particolare che l'indirizzo di rete si 192.168.1.0, che la maschera di rete sia 255.255.255.0 e di poter utilizzare l'indirizzo IP 192.168.1.17 per il computer avviato con i dischetti di emergenza.
# ifconfig eth0 192.168.1.17 netmask 255.255.255.0
# route add -net 192.168.1.0 netmask 255.255.255.0
Per verificare la connessione si può fare un ping verso il computer da raggiungere: potrebbe trattarsi dell'indirizzo 192.168.1.1.
# ping 192.168.1.1
Se tutto è andato bene si può procedere. Si suppone che il computer 192.168.1.1 metta a disposizione il suo filesystem a partire dalla radice.
# mount -t nfs 192.168.1.1:/ /mnt
Nel caso di una connessione PLIP, la procedura è un po' differente. In particolare bisogna ricordare che il computer dal quale si vogliono attingere i dati attraverso il protocollo NFS, deve avere un kernel compilato in modo da gestire questo tipo di connessione.
Si fa riferimento allo stesso esempio riportato nella sezione precedente. L'unica differenza sta nell'interfaccia usata per la comunicazione: si suppone che sia stata riconosciuta la plip1 da entrambi i lati.
Il procedimento di connessione va fatto da entrambi i capi, infatti, raramente un computer ha una connessione PLIP stabile, e di conseguenza non si trova ad avere un indirizzo ed una tabella di instradamento già pronti.
Dal lato del computer avviato con i dischetti si procede come segue.
rescue# ifconfig plip1 192.168.1.17 pointopoint 192.168.1.1
rescue# route add 192.168.1.17
Dal lato del computer server si effettua l'operazione inversa.
server# ifconfig plip1 192.168.1.1 pointopoint 192.168.1.17
server# route add 192.168.1.1
Per verificare la connessione si può fare un ping.
rescue# ping 192.168.1.1
Se tutto è andato bene si può procedere montando il filesystem di rete.
rescue# mount -t nfs 192.168.1.1:/ /mnt
Il dischetto di emergenza ha bisogno di una altro mount point per accedere ad un disco fisso locale. È sufficiente creare un'altra directory.
Quando si accede a un server NFS è pressoché impossibile riuscire a farlo
mantenendo i privilegi dell'utente root, per quanto le documentazioni su
/etc/exports chiariscano che basta utilizzare l'opzione
no_root_squash.
Questo significa che una semplice copia attraverso cp -dpR non da
un risultato garantito: alcuni file potrebbero risultare inaccessibili in lettura.
La cosa si risolve facilmente impacchettando quello che serve nel server
e dando a questo archivio tutti i permessi necessari.
1997.10.26 - Scritto da Daniele Giacomini daniele@calion.com (vedi copyright: Appunti Linux).