[inizio] [indice generale] [precedente] [successivo] [indice analitico] [contributi]


240. Emergenza

Nel momento dell'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.

240.1 Dischetti

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:

240.1.1 Dischetti di avvio

Un dischetto di avvio può essere utile quando, per qualche motivo, il metodo normale di caricamento del sistema operativo non funziona più. Esistono almeno tre tipi di dischetti di questo tipo:

240.1.1.1 Settore di avvio senza il kernel

La prima soluzione, quella del dischetto senza kernel, non è adatta per 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 l'eseguibile `lilo' con questa configurazione, si ottiene la scrittura del primo settore del primo dischetto (il dischetto deve essere stato inizializzato in precedenza, che può anche non contenere alcun filesystem). Ma in questo modo si intende che i file per il caricamento del sistema si devono trovare 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.

Quando si avvia con un dischetto fatto in questo modo, il programma contenuto nel primo settore va alla ricerca del kernel, e degli altri file necessari per il caricamento del sistema, nel disco fisso nel momento dell'utilizzo di LILO. Se il sistema non si avvia perché questi file o il kernel sono stati spostati, a nulla serve un dischetto fatto in questo modo.

240.1.1.2 Settore di avvio e kernel

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, la directory `/etc/' con il file `lilo.conf' e che sia stata riprodotta la directory `/dev/' con il file di dispositivo `fd0' (assieme agli altri file di dispositivo necessari a individuare i dischi o le partizioni a cui si vuole fare riferimento). Quindi è sufficiente eseguire `lilo' con l'opzione `-r', come descritto nella sezione 10.2.6.

Esiste anche la possibilità di usare SYSLINUX, che permette di realizzare un dischetto con le stesse caratteristiche, e con meno difficoltà. SYSLINUX è descritto nel capitolo 10.

Rispetto alla prossima tecnica, un dischetto contenente LILO e il kernel, come appena descritto, è uno strumento di avvio più completo perché permette di specificare, sia attraverso la configurazione del file `/etc/lilo.conf' che per mezzo del cosiddetto bootprompt, alcuni parametri di avvio particolari del quale il proprio sistema potrebbe avere bisogno.

240.1.1.3 Immagine del kernel

L'ultima possibilità è la più semplice, e sotto questo aspetto anche 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, però, potrebbe non sapere quale dispositivo contiene il filesystem principale 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

240.1.2 Dischetti di una distribuzione

La maggior parte delle distribuzioni GNU/Linux predispone dei dischetti di emergenza che consentono generalmente di accedere al disco fisso e di fare delle piccole riparazioni.

Tra tutti, i dischetti più rudimentali sono quelli della distribuzione Slackware. La loro semplicità è da considerare un pregio, dal momento che utilizzandoli ci si trova di fronte un sistema GNU/Linux più o meno tradizionale, senza ottimizzazioni particolari.

240.1.3 Dischetti realizzati appositamente

Ogni sistema ha le proprie caratteristiche ed esigenze. I dischetti di emergenza preparati da altri, oppure ottenuti da una distribuzione GNU/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 è una tappa importante per chi vuole amministrare seriamente il proprio sistema.

240.2 Personalizzazione di dischetti di emergenza

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.

240.2.1 Loopback block device

Per poter costruire o almeno personalizzare dei dischetti di emergenza è particolarmente utile attivare nel kernel la gestione diretta delle immagini di questi: Loopback device support ( 20.2.6).

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> <punto-di-innesto>

240.2.2 disco RAM

Il filesystem principale può essere caricato in memoria centrale (RAM) e montato da lì. Si ottiene un cosiddetto disco RAM. 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 disco RAM può essere ottenuto a partire da un'immagine compressa: è il kernel stesso che l'espande in memoria all'atto del caricamento. Quindi, si può fare stare in un dischetto un'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 che è stato trasferito nella RAM, può essere rimosso subito dopo il suo caricamento, permettendo il riutilizzo dell'unità a dischetti, magari per accedere ad altri programmi di utilità non inclusi nel disco RAM.

Per la gestione di un disco RAM occorre che il kernel sia configurato appositamente: RAM disk support ( 20.2.6).

240.2.3 Scostamento (offset)

Quando il kernel carica un disco RAM 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 disco RAM è contenuta in un dischetto separato, questa si troverà normalmente a partire dall'inizio di questo, cioè da uno scostamento pari a zero.

240.3 Dischetti Slackware

I dischetti della distribuzione Slackware sono i più semplici ed efficaci in situazioni di emergenza. Per essere avviati necessitano di un dischetto di avvio (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 reperibili normalmente presso gli indirizzi seguenti:

http://metalab.unc.edu/pub/Linux/distributions/slackware/rootdsks/

http://metalab.unc.edu/pub/Linux/distributions/slackware/bootdsks.144/

Il dischetto migliore per la soluzione di problemi è rappresentato dall'immagine compressa `rescue.gz'. Se si intende utilizzare anche un dischetto di avvio 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, e contiene in pratica un disco in formato Second-extended (Ext2) di qualche Mbyte. Questo implica che per poterne fare uso occorre molta memoria RAM.

Nelle prime versioni della distribuzione Slackware era distribuita un'immagine `rescue.gz' molto più piccola, che poteva essere espansa e collocata comodamente su un dischetto da 1440 Kbyte. Questa immagine è ancora disponibile e si trova nel percorso `rootdsks/obsolete/rescue.gz'. Il fatto di poterla decomprimere su un dischetto da 1440 Kbyte permette di evitare il caricamento nella RAM. Per elaboratori aventi fino a 8 Mbyte di memoria RAM, questo è l'unico dischetto di emergenza che possa essere utilizzato ragionevolmente.

Se si intende utilizzare l'immagine `rootdsks/obsolete/rescue.gz', è necessario avviare con un kernel in grado di gestire i vecchi binari a.out.

240.3.1 Organizzazione dei dischetti Slackware

Come già accennato, la distribuzione Slackware mette a disposizione immagini di dischetti di avvio, contenenti essenzialmente il kernel, e di dischetti contenenti il filesystem principale (root).

Le immagini per l'avvio rappresentano dischetti con un filesystem normale, contenente un settore di avvio, la directory `/boot/' e il kernel. Si tratta in pratica di dischetti realizzati in modo analogo a quanto descritto in precedenza nella sezione 240.1.1, quando si faceva riferimento a dischetti contenenti questi elementi. Le immagini dei dischetti di avvio, anche se non sono di dimensioni pari a quelle di un dischetto normale, non dovrebbero essere compresse, e si possono copiare semplicemente sul dispositivo del dischetto di destinazione.

dd if=net.i of=/dev/fd0

Le immagini dei dischetti contenenti il sistema minimo (root), sono invece dischetti di qualche Mbyte, compressi in modo da poter essere collocati all'interno di un dischetto da 1440 Kbyte, costringendo però all'uso di un disco RAM.

240.3.2 Utilizzare un kernel personalizzato

Per abbinare un kernel personalizzato a un dischetto contenente il sistema minimo della distribuzione Slackware, si potrebbe ricostruire un dischetto di avvio 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 caricamento del sistema. Il filesystem principale viene caricato da un dischetto, quindi si scrive questo messaggio nel kernel attraverso `rdev'.

rdev /dev/fd0 /dev/fd0

I dischetti contenenti il sistema minimo della distribuzione Slackware non prevedono il controllo del filesystem e il successivo montaggio in lettura e scrittura. In pratica, il filesystem principale deve essere montato 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 disco RAM 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 disco RAM si deve utilizzare `rdev' nel modo seguente:

rdev -r /dev/fd0 32768

infatti, 2^15 + 0 + 0 = 32768.

240.4 Kernel per dischetti di emergenza

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.

240.4.1 Tastiera

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 USA.

Si può risolvere il problema direttamente nel kernel senza dover tentare di inserire il programma `loadkeys' in dischetti già troppo piccoli. È sufficiente trovare il file della mappa della tastiera italiana (di solito si tratta del file `it.map' collocato nella directory `/usr/share/keymaps/<piattaforma>/qwerty/', oppure `/usr/share/keymaps/<piattaforma>/qwerty/') e quindi generare il sorgente `defkeymap.c'. Si procede come segue, nel caso si utilizzi la piattaforma i386.

cd /usr/src/linux/drivers/char

loadkeys --mktable /usr/share/keymaps/i386/qwerty/it.map > defkeymap.c

La compilazione successiva di un nuovo kernel utilizzerà la mappa italiana come predefinita e non ci sarà bisogno di utilizzare `loadkeys'.

240.5 Cavi

Quando si ha la disponibilità di più elaboratori, è 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 nell'appendice B. 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 servente NFS.

240.5.1 Ethernet

Attraverso una connessione Ethernet, con un'interfaccia riconosciuta come `eth0', si può agire come nell'esempio seguente. Si suppone in particolare che l'indirizzo di rete sia 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 l'elaboratore 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 l'elaboratore 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 l'elaboratore 192.168.1.1 metta a disposizione il suo filesystem a partire dalla directory radice.

mount -t nfs 192.168.1.1:/ /mnt

240.5.2 PLIP

Nel caso di una connessione PLIP, la procedura è un po' differente. In particolare bisogna ricordare che l'elaboratore 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 elaboratore ha una connessione PLIP stabile, e di conseguenza non si trova ad avere un indirizzo e una tabella di instradamento già pronti.

Dal lato dell'elaboratore avviato con i dischetti si procede come segue:

rescue# ifconfig plip1 192.168.1.17 pointopoint 192.168.1.1

rescue# route add -host 192.168.1.17 plip1

rescue# route add -host 192.168.1.1 plip1

Dal lato dell'elaboratore servente si effettua l'operazione inversa.

server# ifconfig plip1 192.168.1.1 pointopoint 192.168.1.17

server# route add -host 192.168.1.1 plip1

server# route add -host 192.168.1.17 plip1

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

240.5.3 Considerazioni accessorie

Il dischetto di emergenza ha bisogno di un altro punto di innesto per accedere a un disco fisso locale. È sufficiente creare un'altra directory.

Quando si accede a un servente NFS e non è possibile farlo mantenendo i privilegi dell'utente `root', 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 nell'elaboratore di origine e dando a questo archivio tutti i permessi necessari.

240.6 Utenti e gruppi

Quando si utilizza un sistema operativo minimo, avviato attraverso dischetti di emergenza, per recuperare i dati da uno o più archivi, occorre fare mente locale al problema dell'abbinamento utenti/gruppi, UID/GID.

Trattandosi di un sistema minimo, conterrà alcuni nomi di utenti e di gruppi, presumibilmente non «umani», ma comunque esistenti. Solitamente, questi nomi di utenti e di gruppi sono standardizzati, tuttavia il loro abbinamento con numeri UID/GID non è sempre uniforme. A questo punto, se si recuperano i dati di un sistema in cui questi nomi non corrispondono esattamente, si rischia di riprodurre una copia differente, che non sarà valida quando il sistema normale sarà ripristinato.

Se non ci sono alternative, si può accettare l'inconveniente, riavviare il sistema rigenerato e ripetere il recupero. In questo modo, i file verranno sovrascritti e le proprietà saranno abbinate in base ai nuovi file `/etc/passwd' e `/etc/group'.

In generale, proprio per questo problema, sarebbe opportuno che il dischetto di emergenza contenesse esclusivamente l'indicazione dell'utente e del gruppo `root', eliminando qualunque altro tipo di utente di sistema.

---------------------------

Appunti Linux 2000.04.12 --- Copyright © 1997-2000 Daniele Giacomini --  daniele @ pluto.linux.it


[inizio] [indice generale] [precedente] [successivo] [indice analitico] [contributi]