File System Error(s) non è la morte del pinguino

Si sarà ingelosito per l’arrivo del nuovo membro della famiglia. Forse sentitosi un po’ messo in disparte questo week end, stamane in ufficio accendo il portatilonzo e non mi va a dare una cinquantina di errori nel file system?! Non andava più nemmeno l’avvio in recovery mode. Che cosa antipatica! Soprattutto quando hai una marea di cose da fare e sono tutte dentro il pupetto.

La soluzione è però abbastanza semplice. Basta avere un cd con una distro live disponibile. Inserite il cd ed avviate con boot da cdrom. Dalla distro live controllate che riusciate a montare la partizione con il file system corrotto. Se ci riuscite avete ottime probebilità di riuscire a recuperare il tutto!

Smontate il volume (mai effettuare controlli su file system montati) ed usate fsck sulla partizione interessata:

fsck -c /dev/sda2

Nel mio sistema /dev/sda2 è il device della partizione corrotta. Voi cambierete la direttiva in funzione del vostro sistema.

A questo punto fsck controllerà l’integrità dei blocchi che compongono il file system e tenterà di fixare gli errori trovati. Di base basta confermare ogni richiesta di intervento. Se i problemi sono esclusivamente software allora recupererete ogni funzionalità. In caso contrario è probabile che sia danneggiata irreversibilmente la superficie del disco. Dopo aver bestiemmiato per i tre minuti canonici, procuratevi al più presto un HDD esterno e cercate di recuperare il recuperabile montando la partizione /home/. Dopo di che, passate da un buon rivenditore di hardware 🙂

Per facilitare qualsiasi operazione di recupero, ricordate che è buona norma installare il file system in una partizione separata rispetto a quella contenente la vostra home con tutti i dati non di sistema.

Una buona partizione del disco prevede una struttura simile alla seguente:

  • Partizione contenente il file di swap (calcolata al doppio della RAM di sistema)
  • Partizione di root (/) contenente il file system
  • Partizione /home/

Sono però molti i sostenitori dell’inutilità sopravvenuta del swap. Oramai i sistemi montano tantissima RAM fisica ed ulteriore memoria volatile spesso non serve. Io prudenzialmente lo prevedo sempre. Se avete tanta RAM a disposizione, magari prevedete una partizione di swap uguale o dimezzata rispetto ad essa.

15 thoughts on “File System Error(s) non è la morte del pinguino”

  2. @ Lorenzo: in Ubuntu il file rc.local praticamente fa niente, dovresti avere solo questo dentro:

    exit 0

    Se è diverso dovresti dirmi cosa fa esattamente. Ma l'inconveniente quando occorre esattamente? All'avvio di gdm?

  3. A volte è meglio dare direttamente il comando relativo al filesystem usato : ad esempio se la/e partizione/i è/sono formattata/e con reiserfs è meglio usare reiserfsck perchè il wrapper fsck , almeno nel mio caso, si mangia alcune opzioni che di solito uso per controlli più approfonditi.

    Comunque finchè il kernel monta il filesystem in modalità rw nella fase del boot, ciò è indice che il fs , anche se corrotto, è integro nelle sue parti fondamentali.

    A volte può essere necessario fare un controllo sui blocchi o nei casi più gravi una ricostruzione dell'albero.

    I problemi sorgono quando il kernel , dopo aver effettuato tutti i controlli, non ne vuole sapere di montare il fs in modalità rw, forzando il mount in sola modalità ro sin dal boot.

    In questo caso la prima cosa da fare è un backup delle intere partizioni con dd_rescue o strumenti simili , evitando di usare strumenti per il backup sui file.

    Solo a questo punto , e sottolineo SOLO , si può procedere al check del/i filesystem/s in modalità approfondita con controllo del SuperBlock , del journal , etc etc … nella maggior parte di casi che rientrano in questa fascia, un semplice check non riscontra alcuna corruzione o se viene riscontrata e corretta , il sistema continua a fare il mount in modalità ro; il controllo approfondito può rilevare un superblock corrotto ( percentuale bassa ) , una corruzione del journal ( percentuale media ) , una corruzione dell'area dati ( percentuale media ) o blocchi danneggiati ( percentuale elevata ). Nel caso il controllo riscontri blocchi danneggiati , il consiglio migliore che si possa dare è cambiare disco prima che succeda l'irreparabile. Una volta ripristinata la/e partizione/i sul nuovo disco , si può procedere con il check e la (eventuale) ricostruzione.

    Ultimamente mi è capitato di dover ripristinare un fs formattato reiserfs sul quale il problema è stato riscontrato solo con un reiserfsck –rebuild-tree -S /dev/hd?? . Lo switch -S ha eseguito il controllo sull'intera partizione evidenziando dei blocchi danneggiati.

    Penso che a questo punto si sia capito qual è stato il rimedio 😉

    E comunque l'anno scorso , sempre nello stesso periodo , con un reiserfsck –rebuild-tree /dev/hd?? avevo risolto tutto.

    Nella mia esperienza i veri guai al fs capitano _sempre_ nel periodo tra fine maggio e inizio giugno , a settembre e tra novembre / inizio dicembre.

    Non so se per motivi climatici – con conseguente dilatazione o restrizione termica delle superfici metalliche – o per problemi di qualche altra natura ( tensione elettrica ballerina per via dell'adeguamento dinamico del carico per far fronte al consumo più elevato – picco di ben 246 V misurato a inizio giugno sul mio contatore. Neanche l'UPS sembra poterlo fermare adeguatamente :O )

    P.S. dalle prossime installazioni non userò più reiser come journaling filesystems : credo che mi affiderò a Jfs o Xfs – quest'ultimo è più adatto a ospitare file di grosse dimensioni 😉

  6. @davidonzo: Allora… io non ho ubuntu installato, ho solamente vista.

    Parto dal lettore CD nel quale ho inserito il CD di Gutsy (non può essere stato masterizzato male perché è quello originale inviato da loro dalla norvegia).

    Seleziono l'opzione per installare il sistema operativo (facendo quindi partire la versione live).

    Caricati i fle in una schermata DOS leggo:

    * Starting deferred execution scheduler atd [OK]

    * Starting periodic command scheduler crond [OK]

    * Checking battery state… [OK]

    * Running local boot scripts (/etc/rc.local) [OK]

    _

    E rimane così…

    Sembra essere un problema della scheda video (ATI Radeon X1550PRO PCI-express 512 MB)!

  8. Una partizione di swap serve assolutamente nel momento in cui ho intenzione, soprattutto nei portatili, di utilizzare la funzione di ibernazione del computer, per intenderci quella che copia il contenuto della ram sul disco rigido garantendo un rapido riavvio della macchina.

    Per questo scopo è necessaria una partizione di swap grande almeno quanto la memoria installata.

  10. @lorenzone92

    prova a disabilitare lo splash screen con l'opzione "nosplash" e ad abilitare i messaggi del kernel con "verbose" al boot. Così ti puoi rendere conto da cosa possa dipendere ; i soli messaggi di boot di rc non ti possono essere utili 😉

    che Ubuntu 7.10 potesse avere problemi di questa natura l'ho capito quando ho ritrovato nella versione definitiva , il timing attivo sui messaggi del kernel ; direttamente dalla documentazione del kernel su questa funzione si legge :

    "Show timing information on printks PRINTK_TIME

    Selecting this option causes timing information to be

    included in printk output. This allows you to measure

    the interval between kernel operations, including bootup

    operations. <b>This is useful for identifying long delays

    in kernel startup.</b>"

    personalmente ho sperimentato qualche problema di rallentamento delle operazioni di boot solo *dopo* aver installato Ubuntu : è mia abitudine essere paziente e non ho indagato a fondo la questione, tenuto conto anche che dopo due o tre volte il problema non si è più presentato :

  12. Ah ma ti si deve proprio dire tutto 😀 …

    Se sei con il livecd premi F6 alla schermata di boot ( prima che parta il sistema – meglio precisare 😀 ) : sulla riga che ti appare in basso, sostuisci le direttive "quiet splash" con "verbose nosplash"

    se hai già il sistema installato e ti appare Grub , seleziona la voce per l'avvio di Ubuntu , premi il tasto "e" , ti dovrebbero apparire tre righe : quella che ti interessa è la seconda ; selezionala e premi di nuovo "e" ; scorri la linea di comando fino a che non trovi le due direttive "quiet splash" : come sopra , sostuiscile con "verbose nosplash"

    Occhio che siamo OT : anzi chiedo venia al padrone di casa 😉

  13. @ jj: fate fate pure, almeno questo spazio diventa utile 🙂

    @ lorenzo: mi raccomando in queste cose, fai pianino pianino senza fretta. Una soluzione si trova sempre.

    Ho controllato e la tua scheda video sembra essere supportata.

    Mi sa che la cosa migliore è installare tutto senza usare il metodo grafico aggiornando immediatamente dopo con gli ultimi update.

  14. Azz … questa ve la devo scrivere : filesystem reiserfs che viene montato readonly.

    – Check normale -> No corruption found

    – Superblock -> Correct

    – Journal Check -> No corruption found

    – Check approfondito -> No corruption found

    Monto il filesystem da un LiveCD … tutti i file fondamentali per l'avvio sono presenti e apparentemente della dimensione corretta ; controllo l'hash di alcuni binari fondamentali : corretto !!!

    Controllo i file speciali … eccolo !!!!!

    Il file /dev/null è un diventato un file NORMALE :O …

    Rimonto in modalità rw :

    mount -t reiserfs -o remount,rw /dev/sda3 /mnt

    mknod -m=0666 /dev/null c 1 3

    sync

    umount /dev/sda3

    shutdown -r now

    Risultato : il file system viene montato correttamente e il sistema ritorna a funzionare 🙂

Comments are closed.