fsck não fsck (não é possível definir sinalizadores de superbloco)

Após um desligamento imundo em um dispositivo baseado em cartão SD, levei o cartão SD para fscko sistema de arquivos raiz. Isso levou a variações no seguinte:

e2fsck 1.43.1 (08-Jun-2016)
/dev/sdc2: recovering journal
Superblock needs_recovery flag is clear, but journal has data.
Run journal anyway<y>? no
Clear journal<y>? no
e2fsck: unable to set superblock flags on /dev/sdc2

Aqui eu respondi "não" nas duas vezes, mas não há uma sequência de sim / não que não leve imediatamente ao mesmo resultado.

O sistema de arquivos pode ser montado e, sob inspeção casual, parece bom; Ele também funciona bem no dispositivo, e esse é o sistema de arquivos raiz (na verdade, não foi muito bom, veja os comentários; tente alguns diretórios corrompidos irremediavelmente).

Eu tinha dda partição (8 GB) em um arquivo e tentei fsck nisso. Curiosamente:

e2fsck 1.43.1 (08-Jun-2016)
plush.rootfs: recovering journal
Clearing orphaned inode 18290 (uid=0, gid=0, mode=0100644, size=34096)
Clearing orphaned inode 18270 (uid=0, gid=0, mode=0100644, size=38916)
Clearing orphaned inode 18250 (uid=0, gid=0, mode=0100644, size=1128076)
Clearing orphaned inode 11411 (uid=0, gid=0, mode=0100644, size=293108)
Setting free inodes count to 406127 (was 408580)
Setting free blocks count to 1305622 (was 1347486)
plush.rootfs: clean, 60209/466336 files, 604906/1910528 blocks (check after next mount)

Uma fscklimpeza subsequente passada, a imagem pode ser montada e, fsck -fdepois disso, também passa.

Mas o sistema de arquivos no cartão a partir do qual a imagem de cópia em bloco não processada foi criada ainda tem o mesmo problema - exceto que o systemd-fsckque ocorre durante a inicialização registra o sistema de arquivos como "limpo". Posteriormente, porém, um desligamento adequado, retirando o cartão e tentando fscknovamente de outra caixa apresenta o mesmo erro.

Sempre que o original é montado em outra máquina, o syslog observa:

kernel: EXT4-fs (sdc2): 4 orphan inodes deleted
kernel: EXT4-fs (sdc2): recovery complete

Como tenho tudo feito em backup, estou aberto a tentar qualquer coisa aqui. Eu poderia simplesmente esquecer isso e recuperar a partição da imagem aparentemente fixa, mas isso não parece uma solução muito satisfatória, pois significa assumir que o fsck falhou criptograficamente na solução de um pequeno problema de aparência.

Eu suspeito que isso vai se transformar em uma pergunta de "solicitação de documentação oficial" sobre coisas como precisa de recovery_flag (ou apenas a pergunta "O que isso significa?"), Para que quaisquer sugestões nesse sentido sejam apreciadas.

Acabei de encontrar este mesmo problema. Depois de depurar o problema com o e2fsckmantenedor, percebemos que o cartão SD estava quebrado. Aceitava gravações sem erro, mas na verdade não estava gravando os dados no cartão. O cartão SD foi efetivamente somente leitura.

Parece que o cartão entrou em algum tipo de modo à prova de falhas, onde os dados ainda podiam ser lidos, mas nada gravado.

A e2fsckmensagem unable to set superblock flagssignifica que tentou gravar no superbloco para marcar o diário como processado, o que aconteceu sem erros, mas quando foi ler o superbloco novamente, ainda indicava que o diário precisava ser reproduzido novamente. Em outras palavras, as alterações gravadas no superbloco não foram salvas na mídia de armazenamento.

O cartão que estou usando que tem esse problema é um microSD Samsung Evo de 16GB, que menciono para o caso de ser um problema comum com esses cartões.

Consegui testar isso usando ddpara escrever 4096 bytes /dev/zerono cartão no bloco 0, depois li novamente no cartão e, em vez de obter todos os zeros como deveria, ainda obtive o superbloco ext4 original inalterado.

Agora, estou no processo de mover os dados para um novo cartão e ver se consigo uma substituição da Samsung, que parece oferecer uma garantia de 10 anos em cartões SD.

ATUALIZAÇÃO: A Samsung substituiu o cartão de 16GB por um de 32GB da mesma série Evo, então acho que não posso reclamar muito!

Sei que esse é um tópico antigo, mas achei que ofereceria algumas dicas.

Parece que é assim que os cartões SD morrem naturalmente. O número de ciclos de leitura / gravação que os cartões SD podem suportar é substancialmente menor do que a maioria dos outros meios considerados 'leitura / gravação'. Quando isso acabar, o cartão entrará no modo somente leitura, mas não o informará. Muitas coisas pensam que estão gravando no cartão graças ao cache do sistema operacional etc., mas nada fica.

Uma ótima maneira de matar um cartão SD é montá-lo como uma partição swap ou algo que exige muita leitura / gravação. Você ficaria surpreso com a rapidez com que você pode matar um cartão dessa maneira. Descobri que a execução do knoppix em um cartão SD ou pen drive USB durará apenas um mês ou dois, dependendo da qualidade do cartão e da intensidade do uso do knoppix. (Desde então, mudei para rodar o knoppix em uma unidade USB SSD que já dura alguns anos).