Disavventure RAID1 software, systemd

8 risposte [Ultimo contenuto]

Mer, 03/02/2016 - 20:35

ntropia

(Collaboratore)

Offline

Iscritto: 18/09/2004

Messaggi: 944

Sfrutto l'occasione di una disavventura hardware & software per togliere un po' di polvere al mio account.

Sulla mia workstation al lavoro (Debian GNU/Linux Jessie 8.3) tempo fa avevo installato un RAID1 software con due dischi da 4Tb interni, e avevo configurato il tutto per mandare avvisi in caso di problemi.

Qualche giorno fa avevo notato qualche messaggio poco rassicurante nei log di sistema a proposito di uno dei dischi, smartctl aveva cominciato a frignare, ma non mostrava niente di veramente preoccupante. Ieri, pero', sono cominciati i problemi.

Il disco ha reso il firmware a $DIVINITA in seguito ad un riavvio (qualcuno ha detto driver Nvidia?), ma in realta' il sistema non e' mai tornato su' completamente, ma si fermava sempre in recovery mode e di accedere al secondo disco (quello buono) non se ne parlava.

Tante bestemmie e pagine di documentazione dopo, mi sono fatto l'idea che la colpa sia di Systemd.
La situazione e' piuttosto scoraggiante, perche' ho scoperto che per mettere un sistema in ginocchio basta un disco USB non connesso (se e' nell'fstab), ma uno si immaginerebbe che almeno il RAID con un disco di meno non sia un problema, no?
E invece no, un degrated disk e il sistema si pianta.
Altri hanno riportato il problema ([1], [2]), ma la questione e' ancora aperta.

Mi e' toccato smontare fisicamente il disco, avviare a mano, disabilitare l'automount, raivviare e finalmente usare mdmadm per riabilitare il RAID con un solo disco, e accedere ai miei dati.

Devo ammettere che ci sono rimasto alquanto maluccio, ma se qualcuno avesse suggerimenti o il sospetto che la colpa sia dell'amministratore e non del software, sarei felice di leggerlo.

eNjoy

Chi ha intendimento conti il numero della Bestia, perché è un numero d'uomo; e il suo numero è... rw-rw-rw-

Gio, 04/02/2016 - 19:06

frank67

(Monster)

Offline

Iscritto: 10/07/2013

Messaggi: 487

ntropia ha scritto:

Qualche giorno fa avevo notato qualche messaggio poco rassicurante nei log di sistema a proposito di uno dei dischi, smartctl aveva cominciato a frignare, ma non mostrava niente di veramente preoccupante. Ieri, pero', sono cominciati i problemi.

Il disco ha reso il firmware a $DIVINITA in seguito ad un riavvio
...
Mi e' toccato smontare fisicamente il disco, avviare a mano, disabilitare l'automount, raivviare e finalmente usare mdmadm per riabilitare il RAID con un solo disco, e accedere ai miei dati.

non vorrei innescare un flame... ma cosa ti aspettavi di dover fare se ti si guasta un disco in un RAID software Linux? Visto che parli di hd da 4TB interni presumo sia un acquisto recente, me la prenderei con il produttore degli hd (forse ancora in garanzia) piuttosto che con il RAID software di Linux che proprio con la necessaria procedura descritta ti ha permesso di recuperare i tuoi dati...

Ciao, Franco

Gio, 04/02/2016 - 19:34

mcortese

(Moderatore)

Offline

Iscritto: 27/02/2009

Messaggi: 2918

So che gettare ombre su systemd è una moda diffusa, ma cosa c'entra in questo caso?

Il problema è un effetto collaterale non previsto di una modifica che il manutentore di mdadm aveva pensato per alleviare le sofferenze di quelli che hanno dischi lenti in cui lo script falliva prima che il RAID avesse tempo di riconoscere tutti i device.

L'errore è stato risolto lo scorso dicembre. La versione di mdadm attualmente in Jessie (la 3.3.2-5+deb8u1) dovrebbe essere corretta, almeno stando al changelog:

Citazione:
mdadm (3.3.2-5+deb8u1) jessie; urgency=medium

* Non-maintainer upload.
* disable-incremental-assembly.patch: incremental assembly prevents booting in degraded mode (Closes: #784070)

-- Yann Soubeyrand Mon, 23 Nov 2015 17:22:27 +0100

Gio, 04/02/2016 - 20:42

frank67

(Monster)

Offline

Iscritto: 10/07/2013

Messaggi: 487

mcortese ha scritto:

L'errore è stato risolto lo scorso dicembre. La versione di mdadm attualmente in Jessie (la 3.3.2-5+deb8u1) dovrebbe essere corretta, almeno stando al changelog

ntropia ha scritto:

Sulla mia workstation al lavoro (Debian GNU/Linux Jessie 8.3) tempo fa avevo installato ...

Jessie 8.3 è stata rilasciata il 23 gennaio scorso, quindi?!? E' questo il bug a cui ntropia faceva riferimento?

Ciao, Franco

Ven, 05/02/2016 - 21:59

ntropia

(Collaboratore)

Offline

Iscritto: 18/09/2004

Messaggi: 944

Il problema e' che il sistema ha fatto esattamente quello che *non* avrebbe dovuto fare, e cioe' gestire come critico un errore che non lo era.

@frank67, abbi pazienza, quello per cui sono amareggiato e' il fatto che il sistema non si sia avviato, non che abbia perso i dati o meno. Il sistema RAID ha fatto il suo dovere egregiamente, non e' quello il punto.

Citazione:
mcortese ha scritto:
So che gettare ombre su systemd è una moda diffusa, ma cosa c'entra in questo caso? Smile

Non mi pare di aver sparato a zero su systemd, la mia e' una affermazione abbastanza circostanziata. Il sistema non si e' avviato perche' una partizione non critica non e' stata montata all'avvio. Posso capirlo se c'e' un problema nel montare /, ma per una partizione dati no. Il sistema monta Jessie 8.3, ma a quanto pare la patch non ha risolto il problema.

Stessa musica per un disco esterno USB, nonostante l'opzione "nofail" in fstab, che evidentemente viene ignorata. Non sono affatto d'accordo sul fatto che il boot si debba arrestare.
La questione a me pare seria perche' se si tratta di un sistema remoto, vuol dire che se un disco fa uno starnuto, al riavvio bisogna andare ad operare con la modalita' rescue a mano, fisicamente seduto alla macchina.

Chi ha intendimento conti il numero della Bestia, perché è un numero d'uomo; e il suo numero è... rw-rw-rw-

Ven, 05/02/2016 - 23:27

frank67

(Monster)

Offline

Iscritto: 10/07/2013

Messaggi: 487

Ho due macchine virtuali una con Wheezy e l'altra con Jessie entrambe con 4 hd in RAID5. Ho messo in fstab il cdrom in automount ma senza un DVD nel lettore per simulare l'errore.
Credo che in questo thread bisogna mettersi d'accordo su quanto è critico il fatto che il mount di un filesystem in fstab che l'amministratore di sistema ha configurato come da montare all'avvio sia critico per il sistema: per systemd lo è e va in "emergency mode" sulla macchina Jessie arrestando la sequenza di boot. Sulla macchina Wheezy con SysV l'errore viene segnalato nei log e il boot procede tirando su il sistema ma ovviamente non è configurato come l'amministratore di sistema lo aveva impostato.
Quale è giusto?
Visto che l'amministratore ha eseguito un reboot allora: Systemd, perché le nuove configurazioni non possono avere effetto! Altrimenti non facevi un reboot. Se vogliamo muovere una critica a systemd per questa circostanza è che ha configurato la NIC ma poi non ha avviato sshd nell'emergency mode, cosa serve configurare la rete (tra l'altro via dhcp) se poi non posso neanche farci un ssh
IMHO
Spero di aver azzeccato il topic stavolta

Ciao, Franco

Sab, 06/02/2016 - 00:06

ntropia

(Collaboratore)

Offline

Iscritto: 18/09/2004

Messaggi: 944

La mia premessa in merito al non voler aizzare forconi contro systemd resta valida, ma il problema generale che vedo e' che l'idea e' quella di di gestire tutte le codizioni possibili, cosa che probabilmente funziona nel 99% dei casi, quando tutto va piu' o meno bene. Potrebbe non essere abbastanza per un sistema critico [come puo' essere anche la mia workstation a due giorni da una scadenza importante].
Ribadisco anche quanto detto nel post iniziale, per cui se e' un problema di configurazione incorretta, saro' felicissimo di correggere e passare oltre.

@frank67: Nel caso che riporti tu, pero', non credo ci sia niente di sbagliato: un servizio parte (DHCP), un altro dovrebbe partire ma si inceppa (fs mount), e quello dopo non viene chiamato (ssh). Non e' che la rete e' usata solo per ssh.

Quanto al tuo commento specifico... close, but no cigar!

Citazione:
Ntropia ha scritto:
Stessa musica per un disco esterno USB, nonostante l'opzione "nofail" in fstab, che evidentemente viene ignorata.

Il problema e' anche se l'amministatore di sistema aveva previsto questo, l'avvio si arresta lo stesso:

Citazione:
(dal manuale di fstab)
nofail do not report errors for this device if it does not exist.

Chi ha intendimento conti il numero della Bestia, perché è un numero d'uomo; e il suo numero è... rw-rw-rw-

Sab, 06/02/2016 - 02:52

mcortese

(Moderatore)

Offline

Iscritto: 27/02/2009

Messaggi: 2918

Scusa ntropia, avevo capito che tu fossi afflitto dal baco #784070. Questo fa sì che, se all'avvio non viene trovato un disco che fa parte di un RAID, il boot si blocca. Visto che la funzione di un RAID è proprio di sopravvivere al guasto di uno dei dischi che lo compongono, va da sé che questo baco è gravissimo e vanifica lo scopo stesso del RAID. Il colpevole è uno script di mdadm richiamato dall'initrd (e non da systemd). Una volta corretto questo script, il baco scompare.

Ecco io pensavo che fosse questo il tuo caso, perché hai parlato di RAID con un disco in meno, e perché tu stesso hai citato il baco #784070.

Invece capisco adesso che il tuo problema è un altro: se un disco indicato come "auto" nel fstab non viene trovato all'avvio, systemd si blocca, anche se tra le opzione compare "nofail". Questo è molto strano: ho sentito molti lamentarsi di un comportamento simile, ma in tutti i casi l'opzione "nofail" non era stata specificata. Systemd, almeno sulla carta, riconosce e obbedisce a tale opzione. Da systemd.mount(5):

Citazione:
nofail, fail
With nofail this mount will be only wanted, not required, by the
local-fs.target. This means that the boot will continue even if
this mount point is not mounted successfully. Option fail has the
opposite meaning and is the default.

Hai qualche dettaglio in più?

Mer, 17/02/2016 - 00:23

ntropia

(Collaboratore)

Offline

Iscritto: 18/09/2004

Messaggi: 944

Matteo,
perdona il lungo silenzio, nel frattempo sono stato impegnato con la scadenza prima della quale il RAID ha tirato le cuoia.
Intanto per completezza, gli errori che ho trovato nei log quando il disco mostrava problemi erano:

[842628.775905] Buffer I/O error on logical device, logical block XXXXXX
[ripetuto]
[842628.775909] ata7.00: status: { DRDY }
[842630.918657] ata7.00: status: { DRDY ERR }

Quanto ai problemi di riavvio, ho trovato che in teoria Systemd dovrebbe ritardare l'avvio ma non bloccarlo, anche se il comportamento e' leggermente controintuitivo (almeno per chi viene dalla vecchia mentalita' Unix).
Non so che cosa dire, la situazione che ho descritto non e' unica, anche se sospetto che nuove installazioni risolvano il problema includendo tutte le opzioni mancanti che Systemd si aspetta.

Probabilmente Systemd restera' in giro per un bel po', per cui sara' il caso di abituarcisi, credo.

Chi ha intendimento conti il numero della Bestia, perché è un numero d'uomo; e il suo numero è... rw-rw-rw-

Disavventure RAID1 software, systemd

Home

About

Network ILDN

Social link