Linux: Força o fsck de um sistema de arquivos montado somente para leitura?

Question

Estou desenvolvendo um appliance embarcado, executando o CentOS 6.2. O usuário pode conectar um teclado, mas não um monitor, e um console serial exigiria a abertura do gabinete, algo que não queremos que o usuário tenha que fazer. Isso praticamente elimina a possibilidade de usar uma unidade USB de recuperação para inicializar, a menos que tudo o que faça seja refazer a imagem cegamente do disco rígido. Eu gostaria de fornecer alguns recursos de recuperação, e eu escrevi uma ferramenta que aparece em / dev / tty1 no lugar do getty para fornecer essas funções.

Uma dessas funções é o fsck. Eu descobri como remontar a raiz e outros sistemas de arquivos somente leitura. Agora que eles são somente leitura, deve ser seguro executá-los e reinicializá-los. Infelizmente, o fsck me queixa que os sistemas de arquivos estão montados e se recusam a fazer qualquer coisa.

Como posso forçar o fsck a ser executado em uma partição montada somente leitura?

Baseado em minha pesquisa, isso terá que ser algo obscuro. "-f" significa apenas forçar o reparo de uma partição limpa (mas não montada). Eu preciso reparar uma partição montada limpa ou não limpa. Pelo que li, isso é algo que "apenas especialistas" deveriam fazer, mas ninguém se incomodou em explicar como os especialistas fazem isso. Espero que alguém possa revelar isso para mim.

BTW, eu notei que o e2fsck 1.42.4 no Gentoo permite que você crie uma partição montada, mesmo montando leitura-gravação, mas isso só acontece se o fsck for executado a partir de um terminal, então ele pode perguntar ao fsck usuário, se tiver certeza de que deseja fazer algo tão perigoso. Eu não tenho certeza se a versão do CentOS faz a mesma coisa, mas parece que o fsck pode reparar uma partição montada, mas recusa-se a quando não é executado a partir de um terminal.

Uma opção de último recurso é para mim compilar meu próprio fsck hackeado. Mas estou com medo de estragar de alguma forma inesperada.

Obrigado!

Nota: Originalmente publicado aqui .

Atualização: não achei que importaria na época em que escrevi isso, mas para remontar o fs somente leitura, tive que fazer isso:

echo s > /proc/sysrq-trigger
echo s > /proc/sysrq-trigger
echo u > /proc/sysrq-trigger

Essa foi a única maneira que eu poderia encontrar para fazer isso. Todo o resto reclamou do sistema de arquivos estar ocupado. Até onde eu sei, isso é 'seguro', mas provavelmente remonta um pouco diferente da abordagem usual. E isso pode ser uma razão pela qual o fsck não quer repará-lo. Ainda acha que montou a leitura e gravação.

    

Answer 1

Você pode fsck de um sistema de arquivos somente leitura, porque a montagem somente leitura não o marca como "sujo" do jeito que a montagem de leitura-gravação faz. Não há alterações em um cache de gravação que pode ser apenas parcialmente liberado para o disco, portanto, todas as estruturas em disco são consistentes e seguras para que fsck modifique.

No entanto, se fsck fizer alguma alteração, o driver do sistema de arquivos do kernel pode ficar confuso, porque as coisas que ele esperava permanecer constantes mudaram de lugar. Isso não afetará a integridade do próprio sistema de arquivos (já que o driver não está gravando nele), mas pode tornar o sistema em execução instável. Para evitar isso, você deve reinicializar se fsck fez quaisquer alterações em seu sistema de arquivos.

    

Answer 2

Tendo estado em um projeto do tipo "appliance" no passado, fiz algumas coisas que funcionam parcialmente em torno desse tipo de problema.

Um dispositivo tinha memória suficiente, então o sistema de arquivos raiz foi executado diretamente do initrd. O initrd tinha o suficiente para fsck (forçar), então monte "/ mounts / persistent" e "/ mount / static"; quase todos os arquivos necessários depois disso estavam em um desses dois sistemas de arquivos.

Isso teve a vantagem de o sistema de arquivos raiz nunca precisar de "conserto" - se algo desse errado, ele reiniciaria e o initrd ficaria limpo (já que o que estava sendo usado não era o do disco). Quaisquer atualizações para o initrd foram postas em prática (com as anteriores disponíveis para inicialização); quaisquer arquivos que não estejam na "estática" original necessária depois que uma "atualização de firmware" (= nova initrd) for executada no initrd a partir de então. O sistema de arquivos "estático" era somente leitura em qualquer caso. Apenas o sistema de arquivos persistente precisou de um backup, e a "versão atual do firmware". Eu tinha cópias de todos os firmwares antes de serem enviados.

    

Answer 3

Já experimentou com -p ou -y opções? Eu sempre faço isso em uma máquina sem cabeçalho Debian e funciona.

Na página de manual fsck.ext2 :

   -p     Automatically repair ("preen") the  file  system.   This  option
          will  cause  e2fsck to automatically fix any filesystem problems
          that can be safely fixed without human intervention.  If  e2fsck
          discovers  a  problem which may require the system administrator
          to take  additional  corrective  action,  e2fsck  will  print  a
          description  of the problem and then exit with the value 4 logi-
          cally or'ed into the exit code.  (See the  EXIT  CODE  section.)
          This  option  is normally used by the system's boot scripts.  It
          may not be specified at the same time as the -n or -y options.

   -y     Assume  an answer of 'yes' to all questions; allows e2fsck to be
          used non-interactively.  This option may not be specified at the
          same time as the -n or -p options.

Lembre-se de que você precisa reinicializar antes de remontar a leitura e gravação!