Newsgroup: it.comp.os.linux.sys
Titolo: EXT3 corrotto: e' possibile recuperare?

Ciao a tutti!
ho una RH7.2 con tutto il filesystem EXT3 (no partizioni, tutto sotto
/ )
Questa mattina l'ho trovata 'piantata' (con il prompt di login, potevo
scrivere qualsiasi cosa ma non lo interpretava)
ho riavviato ed arriva fino ad un certo punto (montaggio del fs) poi da
kernel panic.
le ultime righe interessanti sono le seguenti:
- EXT3-fs error (device ide0(3,1)): ext3_check_descriptors: inode table
for group 0 not in group (block 131072)!
- EXT3-fs: group descriptors corrupted!
- mount: error 22 mounting ext3
- pivotroot: pivot-root (/sysroot, /sysroot/initrd) failed: 2
- Kernel panic: No init found. Try passing init= option to kernel
c'e' possibilita' di rimediare o devo procedere al formattone?
Grazie
Manuel
--
             Prima di postare FAQ, controlla su Google:
  >>   
http://groups.google.com/advanced_group_search
   <<
   Problemi di netiquette? 
http://www.nic.it/NA/netiquette.txt
Vuoi imparare linux? 
http://a2.swlibero.org
 - ICQ 117744323


prova a far partire il sistema con disco di rescue e dai un fsck -f 
/dev/hda1 o quello che č. E in bocca al lupo... ecco perchč mi rifiuto 
tuttora di installare journaled su macchine di produzione.. :-P
Anche se č da un po' che ho in testing jfs e pare sano.. se va avanti 
cosě tra un sei mesi mi fido anche... :-P
-- 
Emanuele "SKULL" Balla
--------------------------------------------------------------------
"How should I know if it works?  That's what beta testers are for.  I only
coded it."
(Attributed to Linus Torvalds, somewhere in a posting)

 c'e' possibilita' di rimediare o devo procedere al formattone?
Se riesci, avvia con una minidistro, e monta come ext2 in RO.
Poi, vai di fsck.
Bye,
 Emmanuele.
-- 
Emmanuele Bassi (Zefram)           [ 
http://www.radiance.d2g.com/~zefram
 ]
GnuPG Key fingerprint = 4DD0 C90D 4070 F071 5738  08BD 8ECC DB8F A432 0FF4

 scrivere qualsiasi cosa ma non lo interpretava)
Hai possibilita' di partire in single user mode e fare fsck sulla
partizione?
-- 
Pierluigi De Rosa (
tho...@durin.khazad-dum.net
).
<<      LINUX: the choice of a GNU generation     >>
<<   For my real address... ask the Balrog.       >>
* Sostenete la Lega per la Soppressione dei Troll *

 ha scritto
[cut]
grazie a tutti e tre.
Ho provato, ma purtroppo tutto il filesystem sembra essere compromesso.
la maggior parte degli inode sono sbagliati, ho corretto tutto quello
che mi ha proposto di correggere...
alla fine la macchina parte, poi mi chiede in che runlevel voglio
partire (!) al che, specificando 2 o 3 si blocca ancora...
niente, ho provveduto a reinstallare (non c'era roba importante) pero'
sono rimasto un po' male :-(
Ciao


 sono rimasto un po' male :-(
Si, perchè non hai accettato il mio consiglio :)
Adesso che lo hai capito, usa reiserfs, e gli altri testali solamente.
Saluti

 partire (!) al che, specificando 2 o 3 si blocca ancora...
Uhm.. e dandogli ancora una ennesima botta di fsck giusto per esser
certi che non abbia dimenticato di fixare qualcosa? Oppure potresti (se
te lo permette) partire in single user mode e verificare se gli script
di avvio dei vari runlevel sono a posto o se magari qualche pezzo e'
rimasto in lost+found/


 Ho provato, ma purtroppo tutto il filesystem sembra essere compromesso.
Che kernel hai?


 [2002-02-15 08:26]:

Oh, oh, si, certo.
Un filesystem che cambia in maniera non backward-compatible di revision
in revision (e che ha ancora parecchi bug).


 Queste sono le tue conclusioni, vediamo da cosa derivano:
Non sono mie conclusioni: basta leggere la mailing list per lo sviluppo
del kernel di Linux per averne un'idea.
Quando avrai confrontato il numero di patch che correggono inconsistenze
nel comportamento di ReiserFS con le analoghe per ext3 potrai venire a
farmi la lezione.



No, decisamente no.. ho solo macchine con kernel vanilla, anzi.
Non ti nascondo, perň, che ho ancora macchine con kernel 2.0 installate. 
Sono lě da anni, vanno piů che bene, e come si dice, squadra che vince 
non si cambia. Aggiorno il kernel solo quando effettivamente č 
NECESSARIO, per bug che interessino le features effettivamente 
utilizzate. Altro non mi serve.


 o se magari qualche pezzo e' rimasto in lost+found/
purtroppo oramai ho reinstallato, comunque *parecchia* roba era finita
in lost+found
e comunque non esistevano piu' delle porzioni intere di filesystem (es:
tutta la parte /usr , la /var e la /etc)
probabilmente sarebbe stato meglio per me insistere un po' di piu'
(tanto non avevo nulla da perdere comunque) per imparare qualcosa da
questa esperienza. peccato.
un'idea mi e' balenata: e' possibile che la macchina sia stata hackata e
distrutta a quel modo?
iptables era attivo (su netbios e telnet tra gli altri, no ssh attivo)
non vorrei che abbiano sfruttato qualche buco del wu (strano?) per avere
una shell..
ma non ho piu' nessun log per verificare.
puoi darmi conferma/smentita di questa ipotesi?
PS: a scanso di equivoci il wu non c'e' piu' ... ora c'e' proftpd
Grazie


 Che kernel hai?
avevo sia il 2.4.16 (di 
kernel.org
) che il 2.4.7 (della 7.1)



Che non uso kernel certificati e personalizzati da nessuno. ANZI, uso 
solo kernel vanilla. E' italiano. Al limite un po' di jargon... :-)


 questa esperienza. peccato.
Non ti saprei dire cosi' ad occhio se la tua macchina possa essere stata
hackata ma mi pare strano che qualcuno possa essere entrato nella
macchina e fatto danni per il semplice gusto di volerlo fare.
Beh comunque sia qualcosa l'hai imparata (mi auguro) da questa
esperienza:
1- non usare telnet
2- non usare server FTP buggati


 solo kernel vanilla. E' italiano. Al limite un po' di jargon... :-)
Si si, è italiano...

 di reiserfs.
Allora dovresti conoscere l' "fsx-linux.c" affair.
Generava corruzione con Reiserfs e NFS, ext2/ext3 non affetti.
Per la cronaca, anche FreeBSD ne e' uscito con le ossa rotte..
Corruzione con FFS s-u e NFS.
-- 
Lorenzo

 avevo sia il 2.4.16 (di 
kernel.org
) che il 2.4.7 (della 7.1)
ok, ma al momento del crash quale dei due stavi utilizzando?

 avevo sia il 2.4.16 (di 
kernel.org
) che il 2.4.7 (della 7.1)
Il 2.4.16 ha una versione di ext3 piuttosto recente, e che non ha dato
problemi di corruzione di filesystem. Il 2.4.7, se montava la patch per
ext3, ne aveva una piuttosto vecchiotta che potrebbe averlo causato.
Alle volte, il kernel si incazza e da' la colpa ad ext3, pero` e`
successo ad alcuni che ci fossero casini sul disco attribuiti ad ext3,
mentre in realta` si trattava di problemi hardware o di altri driver.
Hai usato qualche volta il 2.4.15?
Ad ogni modo, tieni sempre la root fs su ext2: almeno hai qualcosa da
montare, se ti va a pallino il sistema.


 tutta la parte /usr , la /var e la /etc)
Una cosi` massiccia corruzione del filesystem non penso sia imputabile
ad un bug di ext3. Con questi risultati, la distruzione della tabella
degli inode deve essere andata avanti parecchio senza che tu te ne
accorgessi, non capita dalla sera alla mattina.
<hack>
Nah, non penso sia colpa di un ``hacker''.


 giocano...
Allora aspetti passivamente che i bug *conosciuti* si presentino?
Che ragionamento e'?
-- 
Lorenzo

 Che ragionamento e'?
Ma lui e` O'Professore, quindi non ha di questi problemi.
Lui deve gestire 120GB di dati, mica robetta, eh...


 ok, ma al momento del crash quale dei due stavi utilizzando?
eh, hai ragione :-)
il 2.4.16
l'altro lo tengo 'di backup'
mi era gia' successo, che il 2.4.16 non partisse piu' ...
dava booting kernel ..........  e poi si piantava.
al momento non ho dato peso alla cosa, ho avviato con il kernel
standard, ho ricompilato il 2.4.16 e tutto si e' sistemato...


 qualcosa da montare, se ti va a pallino il sistema.
si e' un'ottima idea
Ciao e grazie


 pero' la sera andava, la mattina l'ho trovata bloccata...
Puo` darsi che sia un problema con il supporto per i DMA del kernel
2.4.7, che, dopo un po' abbia fatto collassare il sistema (approfittando
del check del disco disabilitato).


 del check del disco disabilitato).
Salve a tutti.
Sperando di essere d'aiuto e di non occupare inutilmente spazio nel NG 
vorrei postare la mia esperienza.
Se Manuel usa dischi IDE (leggo DMA) so che senza ide patch di Andre 
Hedrick i kernel 2.4.16 e 2.4.17
potrebbero produrre file system corrotti,
sono quasi certo che la suddetta patch verra' inserita nel 2.4.18.
Ho una Red Hat su scsi e una su IDE e tutte le part. con reiserfs (lo so 
qui si parla di ext3, ma penso sia un esempio comparabile). Con scsi e 
2.4.16 sempre tutto ok. Con IDE ogni giorno file system corrotto; 
riavviavo con RH scsi e facevo il reiserfsck + rischioso (/rebuildtree). 
Mi e' sempre andata bene... Cercavo nel Changelog dell'ultimo kernel 
patch per reiserfs ma... inutilmente.
Ora uso 2.4.17 con la IDE patch e tutto e' ok.
Saluti

 Ora uso 2.4.17 con la IDE patch e tutto e' ok.
probabilmente puo' essere un motivo per quel che e' successo....
mi sa che x ora mi tengo il dma disabilitato :-)
poi se nel 2.4.18 ci sara' questa famosa patch, vedremo :-P
