Partições de cartão SD auto-reparáveis
Muitos cartões SD são bastante frágeis. Eu tenho um pi há cerca de 2 anos e as principais falhas foram devido ao cartão sd sendo corrompido por um motivo ou outro.
Gostaria de saber se há algum desenvolvimento feito para "fortalecer" o cartão SD na inicialização. Lembro-me de ter algo assim em um projeto passado, em que o uboot escolheria entre 12 tarballs se algum deles tivesse uma soma de verificação crc32 inválida. Ele copiava novamente o validado para todos os outros que foram modificados após uma inicialização bem-sucedida.
Eu gostaria de usar meu pi na configuração "permanente" e seria ótimo se ele pudesse funcionar sem precisar atualizar novamente o cartão.
Existe algum desenvolvimento já feito dessa maneira? Embora a ideia geral seja bastante trivial, fazer com que o uboot funcione corretamente geralmente é um processo bastante doloroso que eu gostaria de evitar.
Após algumas investigações mais profundas, parece que o que eu estava imaginando talvez não fosse possível, ou possível de uma maneira que desse qualquer vantagem significativa. Aqui, o processo de inicialização é descrito . O código em que trabalhei estava sendo executado no primeiro nível de inicialização, já que minha placa possuía um flash programável para isso. Com o pi, isso é armazenado em uma ROM de fábrica. Todo o resto vem do cartão sd; portanto, se o cartão for danificado, o carregador de inicialização do segundo estágio terá tantas chances de ser destruído quanto qualquer outra partição.
Talvez seja possível abusar do carregador de inicialização da ROM para esse fim, mas é difícil dizer como. O código também parece proprietário.
A explicação real do processo de inicialização está em conflito, dependendo das fontes. Vou tentar ler mais sobre isso
Se você tiver problemas com cartões SD, tente (em ordem):
Use outra fonte de alimentação (maior).
Conecte um hub alimentado entre o Raspberry e qualquer periférico USB que você possa ter.
Use cartões SD de marcas conhecidas.
Use um cartão SD maior (para nivelar o desgaste distribuído).
Defina seus rootfs como somente leitura e, assim, evite gravar no cartão SD.
Use uma distro "ao vivo" que seja totalmente executada a partir da RAM. Meu projeto Nard SDK é um deles (mas também existem outros). Com o Nard, o cartão SD é usado apenas no momento da inicialização. Uma vez que o sistema de arquivos em funcionamento nunca seja usado novamente, você pode até conectar o cartão SD ...
Veja: http://www.arbetsmyra.dyndns.org/nard/
Eu acrescentaria que você também pode executar o sistema operacional a partir de um disco rígido conectado por USB - o mesmo que o item nº 6.
Obrigado pelas sugestões. No entanto, o cartão SD está sujeito a corrupção quando a energia é perdida. Talvez colocar o cartão em somente leitura ajudaria. Concordo que prevenir a corrupção em primeiro lugar é uma solução melhor, mas é difícil impedir totalmente.
Se a corrupção por perda de poder é o problema, uma distribuição ao vivo é o remédio.
Você não deve estar experimentando corrupção dramática frequente, mesmo que o poder seja ocasionalmente perdido.
Se um sistema de arquivos tiver um valor diferente de zero na sexta coluna de /etc/fstab, ele será verificado para ver se é necessário verificar se há erros antes de ser montado. As distribuições pi regulares (deveriam) têm esse conjunto para /dev/mmcblk0p1e a partição do sistema de arquivos raiz (no Raspbian mmcblk0p2). O que isso significa para sistemas de arquivos ext4 (como o root fs) é que isso acontece independentemente de todos os N montados; para o valor de N, consulte "Contagem máxima de montagem" na saída de tune2fs -l /dev/[partition]; você pode ajustar esse valor usando tune2fs -c(consulte man tune2fs).
Também será verificado se o sistema de arquivos não foi desmontado corretamente. Isso é feito com e2fsck. Na maioria dos casos, tudo vai dar certo. Há, no entanto, a chance de você perder dados por corrupção; evidências disso serão deixadas em /lost+found. Se possível (e geralmente é), o sistema de arquivos ainda será deixado em um estado utilizável e não corrompido posteriormente. A questão então é se algum componente crítico foi perdido na correção - mas, novamente, isso seria muito incomum.
A razão pela qual é improvável que isso afete algo crítico é que a maioria dessas coisas, embora tecnicamente não seja somente leitura, não é alterada no curso normal das coisas. O sistema possui várias coisas armazenadas /bine /libcarregadas na memória em um determinado momento, mas não há intenção de alterar sua origem no disco; portanto, não há chance de o disco ficar fora de sincronia com essas alterações inexistentes.
Embora eu não saiba quais são as regras para a primeira partição vfat que contém o kernel e o firmware (já que não é formatado ext), eu assumiria que é possível uma verificação semelhante e, em qualquer caso, a lógica do último parágrafo se aplica - esse material muda apenas para atualizações do sistema. De fato, se você quiser ser realmente paranóico, poderá montá-lo somente leitura, exceto por atualizações (ou nem montá-lo de todo, pois não é necessário quando a inicialização normal for concluída).
Depois de tudo isso, você nunca deve experimentar uma corrupção séria, a menos que realmente jogue os dados cortando o poder (e mesmo assim deve ser pouco frequente). Se você costuma sofrer corrupção, há algo muito errado. Houve pelo menos algumas pessoas aqui relatando problemas de corrupção, mesmo ao usar um sistema de arquivos somente leitura , o que é um pouco desconcertante. Isso implica que a corrupção é arbitrariamente causada por hardware defeituoso ou um bug do software.
E, de fato, acho que houve um bug que pode ter afetado pis arbitrariamente entre 2013 e 2013, no meio do final de 2014 (presumindo que o sistema operacional esteja atualizado). Tenho um palpite de que tivemos menos "Meu cartão SD está corrompido!" posts nos últimos 4-6 meses (mas Nb. Eu não fiz nenhuma contabilidade real para confirmar isso).
Você pode querer usar uma unidade flash USB / disco rígido USB.
Eles são muito mais confiáveis ​​que os cartões SD
Aqui está um tópico que descreve como fazê-lo
— nkizz
A autocorreção é um problema em qualquer distribuição Linux em que o fsck esteja no sistema de arquivos mais propenso a corrupção. Esse é um problema que o raspbian compartilha com praticamente todas as distribuições Linux - hoje em dia eles gostam de colocar tudo [incluindo / boot no caso do Ubuntu !! ??] em uma grande partição ext4.
Uma partição raiz somente leitura faz maravilhas para evitar o problema de inicialização, onde o Linux enfrenta problemas no sistema de arquivos antes de ter a chance de executar o fsck.
Mas mesmo uma raiz de leitura / gravação que raramente é atualizada é um grande avanço.
Raspbian funciona bem em uma raiz somente leitura. É preciso um pouco de esforço para configurar, e é claro que você precisa estar preparado para "montar -o remount, rw /" antes de qualquer alteração no sistema de arquivos raiz.