|
Äîêóìåíò âçÿò èç êýøà ïîèñêîâîé ìàøèíû. Àäðåñ
îðèãèíàëüíîãî äîêóìåíòà
: http://www.arcetri.astro.it/irlab/doc/library/linux/AppLinux/al258.htm
Äàòà èçìåíåíèÿ: Tue Sep 21 18:08:58 1999 Äàòà èíäåêñèðîâàíèÿ: Sat Dec 22 13:25:27 2007 Êîäèðîâêà: |
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:
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:
dischetti con un settore di avvio, ma senza kernel;
dischetti con un settore di avvio e con il kernel;
dischetti contenenti solo l'immagine del 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.
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
|
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 9. |
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.
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
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: Loopback device support ( 19.2.6).
In questo modo, un'immagine non compressa di un dischetto puÐ essere montata con un comando simile a quello seguente:
mount |
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 ( 19.2.6).
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.
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/current/rootdsks/
http://metalab.unc.edu/pub/Linux/distributions/slackware/current/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 |
|
Se si intende utilizzare l'immagine |
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
199.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.
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:
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 1024 byte);
il bit 14 indica che si vuole caricare un disco RAM;
il bit 15 indica che si vuole avere una pausa per lo scambio dei dischetti.
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.
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.
Gestione dei binari a.out.
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
Filesystem Minix.
Il filesystem 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 Second-extended, conviene mantenere il supporto a questo vecchio tipo di formato.
Minix fs support
dischi RAM.
Anche se non si intende 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.map collocato nella directory /usr/share/keymaps/<piattaforma>/qwerty/, oppure /usr/lib/kbd/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.
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 server 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
# 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
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 server 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
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 server NFS e non Õ possibile farlo mantenendo i privilegi dell'utente root, una semplice copia attraverso cp 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.
-dpR
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 |
---------------------------
Appunti Linux 1999.09.21 --- Copyright © 1997-1999 Daniele Giacomini -- daniele @ pluto.linux.it