[successivo] [precedente] [inizio] [fine] [indice generale] [indice ridotto] [indice analitico] [volume] [parte]
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.
Di fronte a un problema qualunque di una gravità tale da non permettere l'avvio di un sistema locale, l'unica possibilità di intervenire è data da strumenti su dischetti (oppure su CD-ROM, ma non è questo l'argomento del capitolo). Esistono diversi tipi di dischetti che possono essere stati preparati in precedenza:
dischetti di avvio;
dischetti di installazione della distribuzione GNU/Linux;
dischetti preparati appositamente.
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:
La soluzione del dischetto senza kernel non è adatta per avviare un sistema in difficoltà: è solo un modo per verificare una configurazione di un sistema di avvio come LILO quando non si vuole interferire con l'MBR del disco fisso. In pratica, nel caso di LILO si ottiene semplicemente indicando nel file /etc/lilo.conf la riga boot=/dev/fd0, come nell'esempio seguente:
|
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 e può anche non contenere alcun file system). 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, ovvero nel file system in funzione in quel momento e non nel dischetto. Inoltre, anche il kernel /boot/vmlinuz si intende contenuto in quel file system e non nel dischetto.
Se si utilizza GRUB, il file /boot/grub/menu.lst rimane lo stesso, ma si danno dei comandi differenti per inserire il settore di avvio nel dischetto. Si osservi che il dischetto deve essere inserito nell'unità prima di avviare l'eseguibile grub:
# grub[Invio]
grub> root (hd0,1)[Invio]
Filesystem type is ext2fs, partition type 0x83 |
grub> setup (fd0)[Invio]
Checking if "/boot/grub/stage1" exists... yes Checking if "/boot/grub/stage2" exists... yes Checking if "/boot/grub/e2fs_stage1_5" exists... yes Running "embed /boot/grub/e2fs_stage1_5 (fd0)"... failed (this is not fatal) Running "embed /boot/grub/e2fs_stage1_5 (hd0,1)"... failed (this is not fatal) Running "install /boot/grub/stage1 d (fd0) /boot/grub/stage2 p \ |
grub> quit[Invio]
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 o di GRUB. Se il sistema non si avvia perché questi file o il kernel sono stati spostati, 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 file system e un sistema di avvio.
Nel caso di LILO deve contenere una copia della directory /boot/ con il suo contenuto, la directory /etc/ con il file lilo.conf e deve essere riprodotta anche 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 52.3.
Nel caso di GRUB, il dischetto deve contenere la directory /boot/grub/ con i file stage1, stage2 e menu.lst. Il file del kernel può trovarsi in qualunque posizione (con qualunque nome), purché il file menu.lst sia stato predisposto di conseguenza. Fatto questo, si rende avviabile il dischetto nel modo consueto di GRUB:
# grub[Invio]
grub> root (fd0)[Invio]
grub> setup (fd0)[Invio]
grub> quit[Invio]
È bene ricordare che 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 49.
Rispetto alla prossima tecnica, un dischetto contenente il sistema di avvio e il kernel, come appena descritto, è uno strumento di avvio più completo perché permette di specificare, sia attraverso la configurazione del sistema di avvio, sia per mezzo dei comandi che, a seconda del tipo sistema di avvio, possono essere impartiti prima del caricamento del kernel, alcuni parametri di avvio particolari del quale il proprio sistema potrebbe avere bisogno.
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 file system. Si può utilizzare uno dei due modi seguenti.
# cp vmlinuz /dev/fd0[Invio]
# dd if=vmlinuz of=/dev/fd0[Invio]
Evidentemente, il file del kernel è speciale perché riesce ad avviare se stesso. Il kernel da solo, però, potrebbe non sapere quale dispositivo contiene il file system principale da innestare al momento dell'avvio. È necessario utilizzare il programma rdev, oppure knl 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[Invio]
# rdev -R /dev/fd0 1[Invio]
Con knl si può procedere così:
# knl /dev/fd0 --root=/dev/hda2[Invio]
# knl /dev/fd0 --flags=ro[Invio]
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.
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.
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 (sezione 72.2.10).
In questo modo, un'immagine non compressa di un dischetto può essere innestata con un comando simile a quello seguente:
mount -o loop -t tipo_di_file_system file_immagine punto_di_innesto |
Il file system principale può essere caricato in memoria centrale (RAM) e innestato 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 la 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 file system 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 servizio non inclusi nel disco RAM.
Per la gestione di un disco RAM occorre che il kernel sia configurato appositamente (72.2.10).
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 trova normalmente a partire dall'inizio del dischetto, cioè da uno scostamento pari a zero.
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://distro.ibiblio.org/pub/linux/distributions/slackware/slackware/rootdisks/>
<http://distro.ibiblio.org/pub/linux/distributions/slackware/slackware/bootdisks/>
Il dischetto migliore per la soluzione di problemi è rappresentato dall'immagine compressa rescue.dsk. 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.dsk è compressa e contiene in pratica un disco in formato Ext2 di qualche mebibyte (simbolo: «Mibyte»). Questo implica che per poterne fare uso occorre molta memoria RAM.
Come già accennato, la distribuzione Slackware mette a disposizione immagini di dischetti di avvio, contenenti essenzialmente il kernel, assieme a immagini di dischetti contenenti il file system principale (root).
Le immagini per l'avvio rappresentano dischetti con un file system 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 680.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[Invio]
Le immagini dei dischetti contenenti il sistema minimo (root), sono invece dischetti di qualche mebibyte, compressi in modo da poter essere collocati all'interno di un dischetto da 1 440 Kibyte, costringendo però all'uso di un disco RAM.
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 o con knl. Viene descritta l'ultima di queste modalità.
# dd if=bzImage of=/dev/fd0[Invio]
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 file system principale viene caricato da un dischetto, quindi si scrive questo messaggio nel kernel attraverso rdev.
# rdev /dev/fd0 /dev/fd0[Invio]
In alternativa, con knl:
# knl /dev/fd0 --root=/dev/fd0[Invio]
I dischetti contenenti il sistema minimo della distribuzione Slackware non prevedono il controllo del file system e il successivo innesto in lettura e scrittura. In pratica, il file system principale deve essere innestato inizialmente in lettura e scrittura.
# rdev -R /dev/fd0 0[Invio]
Infine si deve specificare che:
l'immagine del dischetto contenente il sistema (compressa o meno che sia) si trova in un dischetto separato e parte dalla posizione iniziale: lo scostamento è pari a zero;
si vuole, oppure non si vuole, che tale dischetto sia caricato in un disco RAM;
si vuole un preavviso per sapere quando si può togliere il dischetto del kernel per inserire il dischetto contenente il sistema.
Per fare questo si agisce su una serie di bit configurabili attraverso rdev con l'opzione -r:
i primi 11 (dal bit 0 al bit 10) permettono di definire l'indirizzo dello scostamento (in blocchi di 1 024 byte);
il bit 15 indica che si vuole avere una pausa per lo scambio dei dischetti.
Se si vuole caricare il file system principale in un disco RAM si deve utilizzare rdev nel modo seguente:
# rdev -r /dev/fd0 49152[Invio]
infatti, 215 + 214 + 0 = 49 152.
Se invece non si vuole il disco RAM si deve utilizzare rdev nel modo seguente:
# rdev -r /dev/fd0 32768[Invio]
infatti, 215 + 0 + 0 = 32 768.
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 obsoleti sono nel vecchio formato a.out. Il kernel deve essere stato predisposto per gestirli:
Kernel support for a.out binaries
Il file system più utilizzato in passato per i dischetti di emergenza, specialmente quando questi dovevano essere di dimensioni minime, è Minix. Anche se adesso i dischetti di emergenza che si trovano in circolazione sono prevalentemente in formato Ext2, conviene includere la gestione di questo vecchio tipo di formato:
Minix fs support
Anche se non si intendono utilizzare dischetti caricati in memoria RAM, vale la pena di preparare un kernel che ne permetta comunque l'utilizzo:
RAM disk support
Porta parallela PLIP.
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:
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 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.kmap collocato nella directory /usr/share/keymaps/piattaforma/qwerty/) e quindi generare il sorgente defkeymap.c. Si procede come segue, nel caso si utilizzi la piattaforma x86.
# cd sorgenti_linux[Invio]
# cd drivers/char[Invio]
# loadkeys --mktable /usr/share/keymaps/i386/qwerty/it.kmap \
\ > defkeymap.c[Invio]
La compilazione successiva di un nuovo kernel si trova così a gestire la mappa italiana come predefinita, senza bisogno di utilizzare loadkeys.
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 nella parte xii. 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.
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[Invio]
# route add -net 192.168.1.0 netmask 255.255.255.0 dev eth0[Invio]
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[Invio]
Se tutto è andato bene si può procedere. Si suppone che l'elaboratore 192.168.1.1 metta a disposizione il suo file system a partire dalla directory radice.
# mount -t nfs 192.168.1.1:/ /mnt[Invio]
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, per cui 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[Invio]
rescue# route add -host 192.168.1.17 dev plip1[Invio]
rescue# route add -host 192.168.1.1 dev plip1[Invio]
Dal lato dell'elaboratore servente si effettua l'operazione inversa:
server# ifconfig plip1 192.168.1.1 pointopoint 192.168.1.17[Invio]
server# route add -host 192.168.1.1 dev plip1[Invio]
server# route add -host 192.168.1.17 dev plip1[Invio]
Per verificare la connessione si può provare con una richiesta di eco:
rescue# ping 192.168.1.1[Invio]
Se tutto è andato bene si può procedere innestando il file system di rete:
rescue# mount -t nfs 192.168.1.1:/ /mnt[Invio]
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 dà 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.
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, può contenere alcuni nomi di utenti e di gruppi, presumibilmente non «umani», che siano 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 è più valida quando il sistema operativo normale viene ripristinato.
Se non ci sono alternative, si può accettare l'inconveniente, riavviare il sistema rigenerato e ripetere il recupero. In questo modo, i file vengono sovrascritti e la proprietà di questi viene abbinata 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. |
yard(8) (1)
Si tratta di un insieme di programmi per organizzare e facilitare la realizzazione di dischetti di emergenza.
Historic Linux
Small Linux
LOAF: Linux on a floppy
Tomsrtbt: the most GNU/Linux on one floppy
Pocket Linux
Trinux
Linux Embedded Appliance Firewall
Appunti di informatica libera 2007.02 --- Copyright © 2000-2007 Daniele Giacomini -- <daniele (ad) swlibero·org>
Dovrebbe essere possibile fare riferimento a questa pagina anche con il nome dischetti_di_emergenza_con_gnu_linux.htm
[successivo] [precedente] [inizio] [fine] [indice generale] [indice ridotto] [indice analitico]
