Newsgroup: it.comp.os.linux.sys
Titolo: Ultimo kernel 2.6.24.2

Salute a tutti. Qualcuno ha notato che i sorgenti dell'ultimo kernel
prelevati da 
kernel.org
 danno una serie di errori nella fase di
decompressione?
Ho provato a prelevarlo tre volte, ma rimangono questi messaggi che
indicano che ne mancano dei pezzi...
Ciao
Antonio
-- 
  /Ż\  |Ż \/ Ż|(*** !!! attenzione:  campo From alterato !!! ***)
 /Ż_Ż\ |Ż|\/|Ż| )-+-+-+-+-+-+-+-+-+---+---+-+-+-+-+---+-+---+-+(
/_/ \_\|_|  |_|(  |a|m|a|d|e|s|a|n|i(a|t)l|i|b|e|r|o(d|o|t)i|t| )
----------------)-+-+-+-+-+-+-+-+-+---+---+-+-+-+-+---+-+---+-+(

   
Che tipo di errori?
Scaricato ieri nessun problema di nessun genere.
Controlla l'hash del pacchetto...

 Controlla l'hash del pacchetto...
Ciao, mi sta succedendo una cosa strana. Dopo aver scaricato, provo a
decompattarlo (procedura che seguo abitualmente) e una serie di file mi
dice che non puň decompattarli perché non li trova. Ho provato a compiere
la stessa operazione in un'altra dir (dove tengo i kernel di riserva) e
tutto ha funzionato. A questo punto ho provato a trasferire la directory
appena creata ed ancora mi ha dato errore. Ora sto compilando in un'altra
directory e guardo come va a finire. Non riesco proprio a capire. Comunque
non č un problema di sorgente difettoso, č un problema mio, anche se non so
a cosa attribuire il problema.


 a cosa attribuire il problema.
magari si e' corrotto il file della directory.
Cancellala, ricreala e poi riprova.
Ciao Jack

 Ciao, mi sta succedendo una cosa strana. 
Non ti si puo' rispondere perche' possono essere troppe cose: dal file 
danneggiato ad un problema sul tuo filesystem.
ti e' stato detto "controlla l'hash". Quindi Devi controllare l'md5.
Lo hai fatto almeno questo?
-- 
echo onailimissaM | awk 'BEGIN { FS = "" }
{ for (i = NF; i >= 1; i-- )
  printf $i }'; echo

 decompressione?
Scherzi ?? ... A me ha salvato la vita... giuro.. :-)


Ciao. Ricapitolo. Scaricato, mi dava dei problemi a decompattarlo. Provato
in un'altra partizione tutto OK. A questo punto deve esserci un problema
nella partizione:
č l'ultima di una HD da 73 G con reiserfs com fs.
Ho spostato la partizione, liberandola ed ho trasferito /usr da un'altra
parte.
Cosa mi consigliate di far girare sulla partizione per verificare problemi
all'hardware?
Io non ho mai avuto problemi con reiserfs (debian/lenny), ma potrebbe
essere:
l'HD mostra dei problemi da quelle parti;
il fs corrotto da quelle parti;
reiserfs ha problemi con HD ampi (73 G non č ampio, ma non si sa mai).
accetto suggerimenti e prove.
Ciao
Antonio
p.s. in ogni caso con Debian/etch su una ultra60 la compilazione
dell'ultimo kernel non termina. Per ora non sono in grado di fornire info,
ma ho l'impressione che vi sia qualche problemino specifico
macchina/kernel/compilatori. Terrň d'occhio l situazioe e proverň con calma
segnandomi gli errori che ne escono.


 macchina/kernel/compilatori.
Se stai parlando della stessa macchina, allora potresti avere una causa
comune nella temperatura troppo alta. Cerca di monitorare la temperatura del
processore, quando poi si blocca la compilazione aspetta un paio di minuti,
lasciando il sistema scarico, e rilancia il make che si e' bloccato, se 
continua allora e' surriscaldamento.
-- 
Per rispondermi, sostituisci a nomecognome il mio nome e cognome
To reply me, substitute nomecognome with my real name and surname
http://bitsandchaos.wordpress.com


Completo le informazioni e concludo. L'ipotesi giusta era quella del fs
corrotto. La sfiga ha voluto che capitasse quasi contemporaneamente su due
macchine diverse mentre facevo la stessa cosa (vedi p.s. precedente).
Ho fatto girere:
fsck -s -t reiserfs /dev/partizione
dopo averla smontata e poi (dietro consiglio) ho lanciato:
/sbin/reiserfsck --rebuild-tree /dev/partizione (su unamacchina)
e
reiserfsck --fix-fixable /dev/partizione (sull'altra)
Ora sembrerebbe tutto tornato a posto.
Grazie per l'attenzione
Antonio


 Se e' vuota, usa badblocks, in ogni caso smartctl se e' un disco SATA.
??
Perche' parli solo di SATA ?
Da man smartctl:
LINUX:
Use the forms "/dev/hd[a-t]" for IDE/ATA devices, and "/dev/sd[a-z]" for 
SCSI devices. For SCSI Tape Drives and Changers with TapeAlert support 
use the devices "/dev/nst*"  and  "/dev/sg*".   For  SATA  disks 
accessed with libata, use "/dev/sd[a-z]" and append "-d ata". For disks 
behind 3ware controllers you may need "/dev/sd[a-z]" or "/dev/twe[0-9]" 
or "/dev/twa[0-9]": see details below.  More general paths (such as 
devfs ones) may also be specified
Tornando in topic io nei miei ho messo in avvio smartd e vado di grep 
nei report giornalieri (eventualmente potresti lavore di facility per 
loggare in console gli errori piu' gravi... in caso tu lavori spesso in 
console)
Rizio


Utilizzo esclusivamente dischi scsi (macchine SUN e prossimamente sgi),
studierň la tua proposta, non conosco smartd.
Ciao
Antonio


 Perche' parli solo di SATA ?
Errore di sbaglio.


 Grazie per l'attenzione
Giusto per completare le informazioni: in casodi problemi del disco, ti
saresti ritrovato un fottio di righe in syslog, in cui veniva messo in
evidenza un problema nella lettura del disco
Enrico

 studierò la tua proposta, non conosco smartd. Ciao
ma parli di sparc o degli opteron?
Ascolta:
in caso di opteron devi leggere l'ILOM! Tutti i possessori di queste 
macchine dovrebbero saperlo.
Nel caso di sparc devi usare anche il porting dei tool di solaris sparc 
(adesso mi sfugge il nome, ma servono a leggere la eprom e altre cose).



Sparc, in particolare i III. Non sono a conoscenza dei tool di cui parli.
Se ti capita sottomano qualche link ... te ne sarň grato.
