Ciao lista!
Volevo sapere se vi è mai successa una cosa strana che incontro per la prima volta:
sistema operativo debian (squeeze) e raid software fatto con mdadm.
Il sistema operativo non boota più, e si ferma in avvio con una serie di errori curiosi simili a: Doorbell errors come: https://bugzilla.novell.com/show_bug.cgi?id=427554 "mptbase: ioc0: ERROR - Failed to come READY after reset" "Uhhuh. NMI received for unknown reason 31 on CPU 0." "Uhhuh. NMI received for unknown reason 21 on CPU 0."
Un controllo fisico dei dischi non ha trovato errori, una serie di memtest+ non hanno trovato errori.
Nel momento in cui faccio il boot con un rescue system, entrambe le partizioni che compongono l'array risultano corrette ed attive (output di mdadm --examine), ma se faccio assemblare il raid il sistema (quello rescue, che per inciso è un'altra versione di debian (wheezy) ) comincia ad impazzire dando gli stessi errori di cui sopra.
Qualcuno ha mai incontrato situazioni tipo questa? Consigli? (a parte l'ultima spiaggia di zappare il raid e ripartire :-)
Ciao, Daniele
--
On 06/27/2013 04:00 PM, Daniele Gobbetti wrote:
Ciao lista!
Volevo sapere se vi è mai successa una cosa strana che incontro per la prima volta:
sistema operativo debian (squeeze) e raid software fatto con mdadm.
Il sistema operativo non boota più, e si ferma in avvio con una serie di errori curiosi simili a: Doorbell errors come: https://bugzilla.novell.com/show_bug.cgi?id=427554 "mptbase: ioc0: ERROR - Failed to come READY after reset" "Uhhuh. NMI received for unknown reason 31 on CPU 0." "Uhhuh. NMI received for unknown reason 21 on CPU 0."
Un controllo fisico dei dischi non ha trovato errori, una serie di memtest+ non hanno trovato errori.
Nel momento in cui faccio il boot con un rescue system, entrambe le partizioni che compongono l'array risultano corrette ed attive (output di mdadm --examine), ma se faccio assemblare il raid il sistema (quello rescue, che per inciso è un'altra versione di debian (wheezy) ) comincia ad impazzire dando gli stessi errori di cui sopra.
Qualcuno ha mai incontrato situazioni tipo questa? Consigli? (a parte l'ultima spiaggia di zappare il raid e ripartire :-)
Ciao, Daniele
-- _______________________________________________ http://lists.lugbz.org/cgi-bin/mailman/listinfo/lugbz-list
Ciao Daniele,
riesci a partire con un disco solo?
Peter
Ciao lista!
Volevo sapere se vi è mai successa una cosa strana che incontro per la prima volta:
sistema operativo debian (squeeze) e raid software fatto con mdadm.
Il sistema operativo non boota più, e si ferma in avvio con una serie di errori curiosi simili a: Doorbell errors come: https://bugzilla.novell.com/show_bug.cgi?id=427554 "mptbase: ioc0: ERROR - Failed to come READY after reset" "Uhhuh. NMI received for unknown reason 31 on CPU 0." "Uhhuh. NMI received for unknown reason 21 on CPU 0."
Un controllo fisico dei dischi non ha trovato errori, una serie di memtest+ non hanno trovato errori.
Nel momento in cui faccio il boot con un rescue system, entrambe le partizioni che compongono l'array risultano corrette ed attive (output di mdadm --examine), ma se faccio assemblare il raid il sistema (quello rescue, che per inciso è un'altra versione di debian (wheezy) ) comincia ad impazzire dando gli stessi errori di cui sopra.
Qualcuno ha mai incontrato situazioni tipo questa? Consigli? (a parte l'ultima spiaggia di zappare il raid e ripartire :-)
Ciao, Daniele
Se il host e` ok (memtest) e i dischi sono ok (smartctl?) e` o un baco di md o un problema hardware a livello del controller. IMHO piu` likely il secondo e - quello non te lo becca ne memtest ne smartctl.
Io booterei nel rescue e farei un dd if=/dev/partizione of=/dev/null per ogni componente del raid per vedere se gli errori ricompaiono.
Se si: il controller e` andato. Se no: in qualche modo md ha incasinato il raid...
Bye, Chris.
Il 2013-06-27 16:47 Chris Mair ha scritto:
Se il host e` ok (memtest) e i dischi sono ok (smartctl?) e` o un baco di md o un problema hardware a livello del controller. IMHO piu` likely il secondo e - quello non te lo becca ne memtest ne smartctl.
I dischi sono ok così come il controller (credo) perchè ho fatto il check dei dischi dall'utility di configurazione del server stesso.
Io booterei nel rescue e farei un dd if=/dev/partizione of=/dev/null per ogni componente del raid per vedere se gli errori ricompaiono.
La cosa curiosa è che i dischi singolarmente si montano, ora sto provando a fare fsck di uno dei due da cui vorrei ripartire forzando la modalità degradata.
sull'altro in effetti fare un dd è molto interessante come idea, ma lascio prima finire questo per evitare di contaminare i log :)
Se si: il controller e` andato. Se no: in qualche modo md ha incasinato il raid...
Io credo che sia la seconda, ma vediamo.
@Peter ti ho risposto privatamente per errore! Ignora pure quella mail e continuiamo qui :) Grazie mille!
Bye, Chris.
Ciao, Daniele
--
On Thu, Jun 27, 2013 at 04:00:09PM +0200, Daniele Gobbetti wrote:
Ciao lista!
Volevo sapere se vi è mai successa una cosa strana che incontro per la prima volta:
sistema operativo debian (squeeze) e raid software fatto con mdadm.
Il sistema operativo non boota più, e si ferma in avvio con una serie di errori curiosi simili a: Doorbell errors come: https://bugzilla.novell.com/show_bug.cgi?id=427554 "mptbase: ioc0: ERROR - Failed to come READY after reset" "Uhhuh. NMI received for unknown reason 31 on CPU 0." "Uhhuh. NMI received for unknown reason 21 on CPU 0."
Un controllo fisico dei dischi non ha trovato errori, una serie di memtest+ non hanno trovato errori.
Nel momento in cui faccio il boot con un rescue system, entrambe le partizioni che compongono l'array risultano corrette ed attive (output di mdadm --examine), ma se faccio assemblare il raid il sistema (quello rescue, che per inciso è un'altra versione di debian (wheezy) ) comincia ad impazzire dando gli stessi errori di cui sopra.
Qualcuno ha mai incontrato situazioni tipo questa? Consigli? (a parte l'ultima spiaggia di zappare il raid e ripartire :-)
Io non ho _mai_ avuto problemi con raid sw e ne ho usati molti (>20) per almeno 10 anni a 'sta parte. Escludo vivamente un problema sw. Secondo me ti sta andando il controller. Monta i dischi su un _altro_ PC con il rescue.
PS: se hai montato i due dischi singolarmente poi non puoi più metterli in un raid, pena errori casuali e imprevedibili.
PPS: mptbase è un controller ultrascsi, è una macchina vecchia?
Marco Ciampa ciampix@libero.it ha scritto:
On Thu, Jun 27, 2013 at 04:00:09PM +0200, Daniele Gobbetti wrote:
Ciao lista!
Volevo sapere se vi è mai successa una cosa strana che incontro per la prima volta:
sistema operativo debian (squeeze) e raid software fatto con mdadm.
Il sistema operativo non boota più, e si ferma in avvio con una serie di errori curiosi simili a: Doorbell errors come: https://bugzilla.novell.com/show_bug.cgi?id=427554 "mptbase: ioc0: ERROR - Failed to come READY after reset" "Uhhuh. NMI received for unknown reason 31 on CPU 0." "Uhhuh. NMI received for unknown reason 21 on CPU 0."
Un controllo fisico dei dischi non ha trovato errori, una serie di memtest+ non hanno trovato errori.
Nel momento in cui faccio il boot con un rescue system, entrambe le partizioni che compongono l'array risultano corrette ed attive (output di mdadm --examine), ma se faccio assemblare il raid il sistema (quello rescue, che per inciso è un'altra versione di debian (wheezy) ) comincia ad impazzire dando gli stessi errori di cui sopra.
Qualcuno ha mai incontrato situazioni tipo questa? Consigli? (a parte l'ultima spiaggia di zappare il raid e ripartire :-)
Io non ho _mai_ avuto problemi con raid sw e ne ho usati molti (>20) per almeno 10 anni a 'sta parte. Escludo vivamente un problema sw. Secondo me ti sta andando il controller. Monta i dischi su un _altro_ PC con il rescue.
PS: se hai montato i due dischi singolarmente poi non puoi più metterli in un raid, pena errori casuali e imprevedibili.
PPS: mptbase è un controller ultrascsi, è una macchina vecchia?
Ciao,
Si è una macchina vecchia, e usare i dischi su un'altra macchina non è un opzione purtroppo.
Il check del disco "uno" è andato a buon fine, ho forzato il raid a ignorare il secondo disco e il sistema ha completato il boot e tutto _sembra_ a posto.
In teoria, siccome sto lavorando con il raid degradato, credo proprio di poter eliminare i metadati dal secondo disco per poi riestendervi sopra il raid. Ovviamente dovrà ricostruire tutto ma può essere un'opzione...
Per il momento sono contento così, vi tengo informati :)
Grazie di nuovo a tutti. Daniele
-- Inviato con un client di posta free ed open source.
On Thu, Jun 27, 2013 at 08:08:14PM +0200, Daniele Gobbetti wrote:
Marco Ciampa ciampix@libero.it ha scritto:
PPS: mptbase è un controller ultrascsi, è una macchina vecchia?
Si è una macchina vecchia, e usare i dischi su un'altra macchina non è un opzione purtroppo.
Il check del disco "uno" è andato a buon fine, ho forzato il raid a ignorare il secondo disco e il sistema ha completato il boot e tutto _sembra_ a posto.
Ok è partito il disco.
Azzera il disco facendo cat /dev/zero >>/dev/dispositivo_del_disco per fargli rimappare gli eventuali settori rovinati. Se è smart abbastanza e si riprende, ok Se gli errori tornano fuori, consiglio: butta tutto.
Considera che quei dischi probabilmente sono grossomodo equivalenti ad dei sata 2 di oggi...
In teoria, siccome sto lavorando con il raid degradato, credo proprio di poter eliminare i metadati dal secondo disco per poi riestendervi sopra il raid.
ok.
Ovviamente dovrà ricostruire tutto ma può essere un'opzione...
Per il momento sono contento così, vi tengo informati :)
Grazie di nuovo a tutti. Daniele
Occhio che se è partito uno, l'altro lo segue a breve...
Marco Ciampa ciampix@libero.it ha scritto:
On Thu, Jun 27, 2013 at 08:08:14PM +0200, Daniele Gobbetti wrote:
Marco Ciampa ciampix@libero.it ha scritto:
PPS: mptbase è un controller ultrascsi, è una macchina vecchia?
Si è una macchina vecchia, e usare i dischi su un'altra macchina non è un opzione purtroppo.
Il check del disco "uno" è andato a buon fine, ho forzato il raid a ignorare il secondo disco e il sistema ha completato il boot e tutto _sembra_ a posto.
Ok è partito il disco.
Azzera il disco facendo cat /dev/zero >>/dev/dispositivo_del_disco per fargli rimappare gli eventuali settori rovinati. Se è smart abbastanza e si riprende, ok Se gli errori tornano fuori, consiglio: butta tutto.
La cosa che mi preme è riuscire a far fallire il disco e basta. Prima per (probabile) colpa del disco il kernel impazziva con errori che google mi diceva essere probabilmente colpa della RAM. Quello sembra escluso e la cosa mi fa piacere :)
Considera che quei dischi probabilmente sono grossomodo equivalenti ad dei sata 2 di oggi...
In teoria, siccome sto lavorando con il raid degradato, credo proprio di poter eliminare i metadati dal secondo disco per poi riestendervi sopra il raid.
ok.
Ovviamente dovrà ricostruire tutto ma può essere un'opzione...
Per il momento sono contento così, vi tengo informati :)
Grazie di nuovo a tutti. Daniele
Occhio che se è partito uno, l'altro lo segue a breve...
Per questo motivo non sono affatto certo che farò la ricostruzione, potrebbe essere troppo rischioso (sono dischi grandi). Ma voglio valutare prima bene la situazione.
Daniele
-- Inviato con un client di posta free ed open source.
-
Chris Mair -
Daniele Gobbetti -
Marco Ciampa -
Peter Hopfgartner