Partizioni SD card autorigeneranti

Molte schede SD sono piuttosto fragili. Ho avuto un pi per circa 2 anni ormai e i principali guasti erano dovuti alla corruzione della scheda SD per un motivo o un altro.

Mi chiedo se sia stato fatto qualche sviluppo per "rafforzare" la scheda SD all'avvio. Ricordo di aver avuto qualcosa del genere in un progetto passato, in cui uboot avrebbe scelto tra 12 tarball se qualcuno di loro avesse un checksum crc32 non valido. Quindi ricopia quello convalidato a tutti gli altri che sono stati modificati dopo un avvio riuscito.

Mi piacerebbe usare il mio pi in una configurazione "permanente" e sarebbe bello se potesse funzionare senza mai rifare la scheda.

C'è qualche sviluppo già fatto in questo modo? Mentre l'idea generale è piuttosto banale, far funzionare correttamente Uboot è di solito un processo piuttosto doloroso che vorrei evitare.

MODIFICARE :

Dopo qualche approfondimento, sembra che ciò che stavo immaginando potrebbe non essere possibile o possibile in un modo che darebbe un vantaggio significativo. Qui è descritto il processo di avvio . Il codice su cui ho lavorato era in esecuzione al primo livello di avvio poiché la mia scheda aveva un flash programmabile per questo. Con il pi, questo è memorizzato in una ROM dalla fabbrica. Tutto il resto viene dalla scheda SD, quindi se la scheda viene danneggiata, il bootloader del secondo stadio ha tante possibilità di essere distrutto come qualsiasi altra partizione.

Forse è possibile abusare del boot loader ROM per questo scopo, ma è difficile dire come. Anche il codice sembra proprietario.

Modifica 2:

La spiegazione del processo di avvio effettivo è in conflitto a seconda delle fonti. Proverò a leggere di più al riguardo

Se hai problemi con le schede SD, dovresti provare (in ordine):

1. Utilizzare un altro (più grande) alimentatore.
2. Collega un hub alimentato tra Raspberry e qualsiasi periferica USB che potresti avere.
3. Utilizzare schede SD di marchi noti.
4. Utilizzare una scheda SD più grande (per il livellamento dell'usura distribuito).
5. Imposta i tuoi rootfs in sola lettura e quindi evita di scrivere sulla scheda SD.
6. Usa una distro "live" che gira interamente dalla RAM. Il mio progetto Nard SDK è uno di questi (ma ce ne sono anche altri). Con Nard la scheda SD viene utilizzata solo all'avvio. Una volta che il filesystem è attivo e funzionante, non viene mai più utilizzato, è anche possibile collegare a caldo la scheda SD ...

Vedi: http://www.arbetsmyra.dyndns.org/nard/

Non dovresti sperimentare una corruzione drammatica frequente, anche se il potere viene occasionalmente perso.

Se un filesystem ha un valore diverso da zero nella sesta colonna di /etc/fstab, verrà controllato per vedere se è necessario scansionarlo per errori prima che venga montato. Le distribuzioni pi regolari (dovrebbero) hanno questo set per /dev/mmcblk0p1e la partizione del filesystem di root (su Raspbian, mmcblk0p2). Ciò che ciò significa per i filesystem ext4 (come il root fs) è che ciò accade indipendentemente da ogni N mount; per il valore di N, vedere "Numero massimo di montaggi" nell'output di tune2fs -l /dev/[partition]; puoi regolare questo valore usando tune2fs -c(vedi man tune2fs).

Sarà anche scansionato se il filesystem non è stato correttamente smontato. Questo è fatto con e2fsck. Nella maggior parte dei casi, tutto funzionerà bene. Vi è, tuttavia, la possibilità che tu possa perdere i dati a causa della corruzione; la prova di ciò sarà lasciata dentro /lost+found. Se possibile (e di solito lo è), il filesystem verrà comunque lasciato in uno stato utilizzabile e non danneggiato in seguito. La domanda allora è se qualche componente critico è stato perso nella correzione, ma di nuovo, questo sarebbe molto insolito.

Il motivo per cui è improbabile che influisca su qualcosa di critico è che la maggior parte di quella roba, sebbene tecnicamente non di sola lettura, non è cambiata nel normale corso delle cose. Il sistema ha tonnellate di roba da /bine /libcaricate in memoria in un dato punto, ma non c'è alcuna intenzione di alterare la loro fonte su disco, quindi nessuna possibilità che il disco non si sincronizzi con quei cambiamenti inesistenti.

Anche se non so quali siano le regole per la prima partizione vfat contenente il kernel e il firmware (dato che non è formattato ext), suppongo che sia possibile un controllo simile e, in ogni caso, la logica dell'ultimo paragrafo si applica - quella roba cambia solo per gli aggiornamenti di sistema. In effetti, se vuoi essere davvero paranoico, potresti averlo montato in sola lettura tranne che per gli aggiornamenti (o non montato affatto, poiché non è necessario una volta completato il normale avvio).

Dopo tutto ciò, non dovresti praticamente mai sperimentare una grave corruzione a meno che non tiri i dadi frequentemente tagliando il potere (e anche allora dovrebbe essere poco frequente). Se si verifica spesso la corruzione, c'è qualcosa di molto gravemente sbagliato. Ci sono state almeno alcune persone qui che hanno segnalato problemi di corruzione anche quando si utilizza un filesystem di sola lettura , il che è un po 'sconcertante. Implica che la corruzione sia arbitrariamente causata da hardware difettoso o da un bug del software.

E in effetti, penso che ci sia stato un tale bug che potrebbe aver influenzato arbitrariamente il pis da qualche volta nel 2013 a metà della fine del 2014 (presumendo che il sistema operativo sia aggiornato). Ho il sospetto che ne abbiamo meno "La mia scheda SD è corrotta!" post negli ultimi 4-6 mesi (ma Nb. Non ho fatto alcuna contabilità reale per confermarlo).

Si consiglia di utilizzare un'unità flash USB / disco rigido USB.

Sono utilmente più affidabili delle schede SD

Ecco un thread che descrive come farlo

L'auto-guarigione è un problema con qualsiasi distribuzione Linux in cui fsck è nel file system più soggetto alla corruzione. Questo è un problema che raspbian condivide praticamente con tutte le distribuzioni Linux - oggigiorno a loro piace mettere tutto [incluso / boot nel caso di Ubuntu !! ??] su una grande partizione ext4.

Una partizione di root di sola lettura fa miracoli per evitare il problema di avvio del boot in cui Linux si imbatte in problemi di file system prima che abbia avuto la possibilità di eseguire fsck.

Ma anche un root di lettura / scrittura che viene raramente aggiornato è un enorme passo avanti.

Raspbian funziona bene su una radice di sola lettura. Ci vuole un po 'di sforzo per configurare, e ovviamente devi essere pronto a "montare -o remount, rw /" prima di qualsiasi modifica al filesystem di root.