![fsck na partição raiz na placa personalizada baseada em BBB](https://rvso.com/image/1510185/fsck%20na%20parti%C3%A7%C3%A3o%20raiz%20na%20placa%20personalizada%20baseada%20em%20BBB.png)
Temos placa Linux embarcada personalizada baseada em BeagleBone Black. Possui Linux-3.12, 256 MB de RAM e 4 GB eMMC com ext4
sistema de arquivos.
Às vezes nos deparamos com erros no sistema de arquivos (raros, mas não impossíveis). Portanto, queremos verificar os erros do sistema de arquivos e corrigi-los na inicialização.
Obviamente não queremos que o fsck ou qualquer outro utilitário destrua quaisquer dados no sistema de arquivos.
Temos o busybox baseado, SysVinit
então /forcefsck
não funciona :( Então usei /etc/fstab
(definindo o 5º campo como 1) e depois executei fsck -p
a partir do rcS
script.
Esta combinação funciona para partições diferentes da rootfs
partição. Eu tenho algumas perguntas sobre isso.
- Existe alguma maneira de executar
fsck
narootfs
partição? - Pode
fsck -p
destruir dados na partição? - Existe alguma maneira melhor de lidar com essa situação, quero dizer, qualquer serviço que verifique e corrija erros do sistema de arquivos?
Responder1
A maneira normal para distribuições Linux de desktop baseadas em SysVinit é solicitar uma senha de root durante a inicialização quando detecta erros no sistema de arquivos raiz. Você pode então usar isso para executar fsck
no root fs. Não sei se a sua distribuição incorporada faz isso, mas é definitivamente possível configurá-la dessa forma.
Se não houver erros detectados durante a inicialização, outra opção é fazer o login como root, parar tudo o que não é realmente necessário, remontar o sistema de arquivos raiz somente leitura e então executar o fsck nele.
Trata-se do sistema de arquivos raiz do seu armazenamento em bloco, nãorootfs. Rootfs é um sistema de arquivos mínimo baseado em RAM usado durante a inicialização e não pode estar corrompido (a menos que a imagem do kernel de inicialização esteja corrompida ou a RAM esteja ruim).
Em princípio, fsck -p
o objetivo é fazer apenas reparos "seguros", mas se você realmente quiser ter certeza de que nada de ruim acontecerá, execute-o manualmente para ser avisado sobre cada ação. Se por algum motivo houver dados valiosos no sistema de arquivos raiz (não deveria acontecer, mas talvez aconteça), faça um backup usando dd
primeiro.