Newsgroup: it.comp.os.linux.sys
Titolo: errore fsck con uuid

Uso Ubuntu maverick 64 bit,
ogni tanto (1 volta ogni 4-5) mi resta bloccato sulla schermata viola 
con "serious errors checking..."
la prima volta ho forzato un fsck di tutto e non ha rilevato problemi... 
La seconda volta ho solo fatto "Ignore" due volte e tutto sembra 
funzionare normalmente...
Lo fa per due partizioni sul disco sdb, rispettivamente montate in /home 
e in /tmp, sullo stesso disco.
c'č un altro disco, sdc, con una sola partizione sdc1, finora non viene 
chiamato in causa...
Mi viene il dubbio sia legato agli uuid, pensavo di rimettere in fstab i 
soliti vecchi /dev/sdb1 al posto degli uuid, ma non so se il problema č 
quello... gnome disk utility vede ok i dati smart del disco; inoltre se 
davvero fosse un problema di superblock corrotto, dovrei imho vederlo 
sempre, e non dovrebbe bastare fare ignore e proseguire...
Molti post che ho trovato googlando si riferiscono a uuid errati, ma se 
fosse cosě dovrebbero essere sempre errati, e non solo una volta ogni 
tanto...
Help me :-)
Questo č quanto trovo in boot.log:
fsck from util-linux-ng 2.17.2
fsck from util-linux-ng 2.17.2
fsck from util-linux-ng 2.17.2
fsck from util-linux-ng 2.17.2
fsck.ext4: No such file or directory while trying to open 
/dev/disk/by-uuid/a4847887-be06-4200-b114-a290bc210e18
/dev/disk/by-uuid/a4847887-be06-4200-b114-a290bc210e18:
The superblock could not be read or does not describe a correct ext2
filesystem.  If the device is valid and it really contains an ext2
filesystem (and not swap or ufs or something else), then the superblock
is corrupt, and you might try running e2fsck with an alternate superblock:
     e2fsck -b 8193 <device>
mountall: fsck /home [483] terminated with status 8
mountall: Unrecoverable fsck error: /home
/dev/sda1: clean, 185950/1954064 files, 1090589/7816192 blocks
fsck.ext4: No such file or directory while trying to open 
/dev/disk/by-uuid/6da80f11-7514-468d-8783-455713b0da8e
/dev/disk/by-uuid/6da80f11-7514-468d-8783-455713b0da8e:
The superblock could not be read or does not describe a correct ext2
filesystem.  If the device is valid and it really contains an ext2
filesystem (and not swap or ufs or something else), then the superblock
is corrupt, and you might try running e2fsck with an alternate superblock:
     e2fsck -b 8193 <device>
mountall: fsck /tmp [482] terminated with status 8
mountall: Unrecoverable fsck error: /tmp
/dev/sdc1: clean, 32350/30531584 files, 20442678/122096000 blocks
init: ureadahead-other main process (965) terminated with status 4
Ignoring errors with /home at user request
init: ureadahead-other main process (1129) terminated with status 4
Ignoring errors with /tmp at user request

 e in /tmp, sullo stesso disco.
Ma quando funziona, funziona normalmente o sembra solo?
Cioè: ti monta poi davvero le due partizioni su /tmp e /home, o usa
le semplici directory nella partizione di root?
Posta il risultato di:
$ mount
 
Poi posta anche il risultato di:
$ cat /etc/fstab
di:
$ sudo fdisk -l
e di:
$ ls -l /dev/disk/by-uuid
Così magari si capisce pure se hai qualche device virtuale, raid
o lvm o crypt, che la cosa pare simile a questa:
http://www.mail-archive.com/debian-b...@lists.debian.org/msg758835.html
-- 
Bye, Lem
Ceterum censeo ISLAM esse delendum
_____________________________________________________________________
Non sprecare i cicli idle della tua CPU. Usali per qualcosa di utile.
http://orbit.psi.edu/
 
http://www.worldcommunitygrid.org/index.jsp
 
http://boinc.berkeley.edu/projects.php

 
http://www.mail-archive.com/debian-b...@lists.debian.org/msg758835.html
Esatto, i miei errori sono gli stessi, ma non ho niente del genere.
Solo normalissime partizioni. Mi viene però il dubbio che la causa sia 
simile, cioè "qualcosa che non è ancora avvenuto" quando parte fsck...
Onestamente però non so a cosa pensare...

 simile, cioè "qualcosa che non è ancora avvenuto" quando parte fsck...
Il fatto è che certe volte evidentemente in /dev/disk/by-uuid non
vengono creati in tempo i link a /dev/sdb[123].
Se non hai device virtuali, non vedo come ci possano essere problemi
di tempistica causati dall'OS: ci fosse stato un bug del genere,
credo sarebbe venuto giù il mondo! 
Quindi perché questo ritardo? Forse qualcosa non va
*fisicamente* nell'hardware: disco che sta tirando le cuoia, troppo
lento a rispondere, cavi mal collegati o rovinati...
Questo puoi provare a diagnosticarlo dando dalla console di
ripristrino, quando riscontri il problema:
dmesg | grep sdb
In quei casi immagni che neppure lo swap (che sta sullo stesso disco)
venga attivato. Per controllare:
cat /proc/swaps
Se il problema è fisico, sostituire in /etc/fstab i vari uuid=...
con /dev/sdb[123] non apporterà vantaggi. Se il problema non fosse
fisico, se quindi le partizioni fossero già lì belle e pronte e
mancassero solo i link, ovviamente colla sostituzione dovresti
invece risolvere.
Quando parte bene, poi non hai mai problemi successivi?
Per curiosità, /dev/sdb che disco è?


 invece risolvere.
Ti ringrazio dei consigli...
Magari appena ho un attimo vedo di testare un po' l'hardware che non si 
sa mai... Anche se mi stupisce che il problema si verifichi solo da poco 
tempo a questa parte, e solo qualche volta.
Però, se posso chiedertelo, mi è di recente successa un'altra cosa strana:
un bel po' di errori (vedi log sotto) nel fare un backup su hd esterno 
usb 2,5" , e un Oops del kernel relativo... La stranezza è che in quel 
caso avevo già dato per sicuro il danno hardware al disco, ma poi questo 
su un altro pc era perfettamente leggibile, e in seguito anche sul mio 
pc ho fatto un backup completo senza problemi...
Non avevo trovato legami fra le due cose, ma visto che ne stiamo 
parlando, mi torna il dubbio...
Grazie mille comunque dell'aiuto!!!
----------
kernel: [ 6404.596011] sd 11:0:0:0: [sdh] Unhandled error code
kernel: [ 6404.596020] sd 11:0:0:0: [sdh] Result: 
hostbyte=DID_NO_CONNECT driverbyte=DRIVER_OK
kernel: [ 6404.596027] sd 11:0:0:0: [sdh] CDB: Write(10): 2a 00 02 b0 d7 
af 00 00 f0 00
kernel: [ 6404.596062] lost page write due to I/O error on sdh1
kernel: [ 6404.600822] sd 11:0:0:0: [sdh] CDB: Write(10): 2a 00 02 b0 d8 
9f 00 00 f0 00
kernel: [ 6405.971735] JBD2: Detected IO errors while flushing file data 
on sdh1-8
kernel: [ 6477.143460] sd 27:0:0:0: [sdh] 625142448 512-byte logical 
blocks: (320 GB/298 GiB)
kernel: [ 6477.145384] sd 27:0:0:0: [sdh] Write Protect is off
kernel: [ 6477.405625] sd 27:0:0:0: [sdh] Unhandled error code
kernel: [ 6477.405630] sd 27:0:0:0: [sdh] Result: 
hostbyte=DID_NO_CONNECT driverbyte=DRIVER_OK
kernel: [ 6477.405638] sd 27:0:0:0: [sdh] CDB: Read(10): 28 00 00 00 00 
00 00 00 08 00
kernel: [ 6477.405834] Dev sdh: unable to read RDB block 0
kernel: [ 6477.406145] sd 27:0:0:0: [sdh] READ CAPACITY failed
kernel: [ 6477.406150] sd 27:0:0:0: [sdh] Result: 
hostbyte=DID_NO_CONNECT driverbyte=DRIVER_OK
kernel: [ 6477.406156] sd 27:0:0:0: [sdh] Sense not available.
...
kernel: [ 6480.716809]  sdh:
kernel: [ 6480.974486] sd 28:0:0:0: [sdh] Unhandled error code
kernel: [ 6480.974492] sd 28:0:0:0: [sdh] Result: hostbyte=DID_ERROR 
driverbyte=DRIVER_OK
...
kernel: [ 6480.976990] sd 28:0:0:0: [sdh] CDB: Read(10): 28 00 00 00 00 
00 00 00 08 00
kernel: [ 6480.979473] sd 28:0:0:0: [sdh] READ CAPACITY failed
kernel: [ 6480.979480] sd 28:0:0:0: [sdh] Result: hostbyte=DID_ERROR 
driverbyte=DRIVER_OK
kernel: [ 6480.979486] sd 28:0:0:0: [sdh] Sense not available.
-----------

 parlando, mi torna il dubbio...
Uhmmmm... Mi sembra prematuro ipotizzare collegamenti. 


 In tal caso, congratulazioni! <veg>
Gli auguro di no... io ormai di dischi 'certified repaired by seagate' ne ho
piene le scatole... in tutti i sensi!
-- 
ValeRyo
XT600 "Katoki Pajama" - 
http://www.slimmit.com/go.asp?7Y9
GamerTag: 
http://card.mygamercard.net/IT/nxe/ValeRyo76.png
 

 i modelli come il tuo.
In teoria quel bug era solo su un certo firmware della vecchia serie, 
almeno spero...
Comunque quello che mi stupisce è che con Lucid non ho mai avuto questo 
problema, neanche una volta in 6-7 mesi...

 problema, neanche una volta in 6-7 mesi...
Ho effettuato un Full Test del disco in questione con Sea Tools, ed è 
risultato passed. Quindi almeno secondo l'utility diagnostica Seagate, 
non ha problemi hardware...

 cat /proc/swaps
C'era sdb3 correttamente, e in mount c'era anche /tmp montato...
Fatto ctrl-d si è avviato e tutto sembra regolare...

 Fatto ctrl-d si è avviato e tutto sembra regolare...
Continuo a postare solo per chi eventualmente trovasse il thread googlando:
Ho rimesso i /dev/ al posto degli uuid in /etc/fstab...
questo boot è comparsa correttamente la schermata a sfondo viola del 
"checking for errors" , e non l'errore delle altre volte.
Non chiedetemi se e quale sia la causa, ma sembra legata agli uuid (o 
almeno spero non ci siano altre cause più problematiche..)

 almeno spero non ci siano altre cause più problematiche..)
Ora che mi viene in mente: tu non avevi pacioccato col parametro
concurrency del file /etc/init.d/rc, vero?


 concurrency del file /etc/init.d/rc, vero?
Assolutamente no ...