fsck não irá fsck (incapaz de definir sinalizadores de superblocos)

6

Após um desligamento impuro em um dispositivo com cartão SD, levei o cartão SD para fsck do sistema de arquivos raiz. Isso levou a variações sobre o 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á sequência de sim / não que não conduza imediatamente ao mesmo resultado.

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

Eu dd 'd a partição (8 GB) para um arquivo e tentei fsck sobre isso. 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)

Um fsck subsequente passou limpo, a imagem pode ser montada e fsck -f depois disso também passa.

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

Sempre que o original é montado em outra máquina, as notas do syslog:

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

Desde que eu tenha tudo copiado, estou aberto para tentar qualquer coisa aqui. Eu poderia simplesmente esquecer isso e refazer a partição da imagem aparentemente fixa, mas isso não parece ser uma solução muito satisfatória, já que significa supor que fsck falhou enigmaticamente em resolver um problema menor.

Eu suspeito que isso vai se transformar em uma pergunta "pedido de documentação oficial" sobre coisas como precisa de recovery_flag (ou simplesmente "o que isso significa?"), então qualquer sugestão ao longo desses linhas são apreciadas.

    
por goldilocks 03.12.2016 / 23:57

2 respostas

1

Acabei de me deparar com o mesmo problema. Depois de depurar o problema com o mantenedor e2fsck , percebemos que o cartão SD estava quebrado. Ele estava aceitando as gravações sem erro, mas na verdade não estava gravando os dados no cartão. O cartão SD foi efetivamente lido apenas.

Parece que a placa entrou em algum tipo de modo à prova de falhas, onde os dados ainda podiam ser lidos, mas nada escrito.

A e2fsck message unable to set superblock flags significa que tentou gravar no superbloco para marcar o diário como processado, o que aconteceu sem erro, mas quando foi ler o superblock novamente ele ainda indicou que o diário precisava ser replayed. Em outras palavras, as alterações gravadas no superbloco não foram salvas no meio de armazenamento.

O cartão que estou usando e que tem esse problema é um microSD Samsung Evo de 16GB, que eu mencionei apenas no caso de ser um problema comum com esses cartões.

Eu pude testar isso usando dd para escrever 4096 bytes de /dev/zero no cartão no bloco 0, então eu li de volta do cartão e em vez de obter todos os zeros como deveria, eu ainda tenho o superbloco ext4 inalterado original.

Agora estou no processo de mover os dados para um novo cartão e, em seguida, ver se posso obter 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 na mesma série Evo, então acho que não posso reclamar muito!

    
por 18.08.2017 / 11:01
1

Eu sei que este é um tópico antigo, mas achei que poderia oferecer algumas dicas.

Esta parece ser a maneira como 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 estiver esgotado, o cartão entrará no modo somente leitura, mas não o informará sobre isso. Muitas coisas vão pensar que eles estão escrevendo para o cartão graças ao cache do sistema operacional, etc., mas nada acontece.

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

    
por 13.07.2018 / 20:30