Como evitar mensagens "Executar o fsck manualmente", permitindo experimentar as alterações de horário do sistema?

18

Estou trabalhando com um sistema em que queremos permitir que os usuários brinquem com a data e a hora, se quiserem, e onde as reinicializações podem ocorrer arbitrariamente. Isso é bom, exceto por uma coisa: se houver um grande intervalo de tempo para trás, o seguinte erro será exibido na reinicialização:

Checking filesystems
IMAGE2: Superblock last mount time (Tue Mar  1 17:32:48 2011,
        now = Thu Feb 24 17:34:29 2011) is in the future.

IMAGE2: UNEXPECTED INCONSISTENCY; RUN fsck MANUALLY.
        (i.e., without -a or -p options)

*** An error occurred during the file system check.
*** Dropping you to a shell; the system will reboot
*** when you leave the shell.

… E, em seguida, a inicialização é interrompida, aguardando a entrada do console do usuário e, mesmo após o acesso ao console, é necessária uma senha root para continuar.

Isso é decididamente menos que o ideal. Existe alguma maneira de ignorar a verificação ou forçar a verificação a ocorrer automaticamente na reinicialização?

O Google só forneceu ajuda que requer a execução do fsck manualmente se / quando for atingido, o que não é o que estou procurando. Executar o fsck manualmente após definir o horário não funciona, pois o sistema de arquivos ainda está montado nesse ponto e apenas desabilitar o fsck completamente é menos do que o ideal.

Estou usando o RedHat 6.

Atualização : A solução que eu estou usando atualmente é hackear o fstab para desativar a verificação do fsck na reinicialização. Eu tentei editar o último tempo de montagem nos discos usando debugfs, o que funciona bem para unidades ext3, mas parece falhar inconsistentemente no ext4.

boot rhel date fsck eu e
fonte

Respostas:

15

Eu sugeriria hackers e2fsckpara desativar as verificações específicas para um último tempo de montagem ou últimos tempos de gravação no futuro. Eles são definidos em problem.c / problem.he usados ​​em super.c . Mas, ao observar, descobri que o E2fsprogs 1.41.10 adiciona uma nova opção ao /etc/e2fsck.confchamado broken_system_clock . Parece ser exatamente o que você precisa e, como você está usando o Red Hat Enterprise Linux 6, você deve ter o 1.41.12, que inclui esta opção. Na página do manual:

   broken_system_clock
          The e2fsck(8) program has some hueristics that assume  that  the
          system clock is correct.  In addition, many system programs make
          similar assumptions.  For example, the UUID library  depends  on
          time  not going backwards in order for it to be able to make its
          guarantees about issuing universally unique ID’s.  Systems  with
          broken  system clocks, are well, broken.  However, broken system
          clocks, particularly in embedded systems, do exist.  E2fsck will
          attempt  to  use  hueristics to determine if the time can no tbe
          trusted; and to skip time-based checks if this is true.  If this
          boolean  is set to true, then e2fsck will always assume that the
          system clock can not be trusted.

Sim, a página de manual não pode soletrar "heurísticas". Opa Mas, presumivelmente, o código funciona de qualquer maneira. :)

mattdm
fonte
Isso parece fantástico, exceto que a página de manual implica que ela afeta apenas ext2 e ext3, e eu estou usando uma combinação de ext3 e ext4. Ainda assim, vou tentar agora, como se funcionasse, é exatamente o que estou procurando.
me_and
11
Funciona! Incluindo no ext4. Obrigado!
me_and
1

Duvido que haja uma maneira de remover essa verificação especificamente, sem modificar o código-fonte. Ignorar todos os erros do fsck parece perigoso, e se houvesse algum outro problema?

Portanto, sugiro a seguinte solução alternativa: altere os scripts de inicialização para definir a data do sistema em algum momento no futuro (digamos 2038-01-18 em uma máquina de 32 bits) antes de executar o fsck e leia-o novamente no hardware relógio depois ( hwclock --hctosys, com mais opções conforme necessário, dependendo do seu hardware e uso do GMT no relógio do hardware.)

Gilles 'SO- parar de ser mau'
fonte
Isso não significaria na próxima vez que haveria uma janela na qual poderíamos acertar o mesmo bug novamente? ou seja, o tempo da última montagem é 2038-01-18, portanto, se o horário atual também estiver definido, haverá uma condição de corrida em que estamos (no que diz respeito ao sistema) tentando montar novamente antes da última montagem.
me_and
@me_and: Sim, receio que meu kludge não ajude contra usuários mal-intencionados. Se é isso que você está enfrentando, aplicar o patch fsck parece ser a melhor opção.
Gilles 'SO- stop be evil'
0

Parece que deve ser executado em uma máquina virtual, onde você pode ter mais controle (ou apenas reverter para um instantâneo).

jamespo
fonte
Executar em uma VM realmente não é uma opção para nós e, de qualquer forma, apenas reverter para um instantâneo significa que removemos todo o outro estado que o usuário possa ter configurado.
me_and
0

Aqui está uma solução que funcionou muito bem para mim:

Crie /etc/e2fsck.conf:

[problems]

# Superblock last mount time is in the future (PR_0_FUTURE_SB_LAST_MOUNT).
0x000031 = {
preen_ok = true
preen_nomessage = true
}

# Superblock last write time is in the future (PR_0_FUTURE_SB_LAST_WRITE).
0x000032 = {
preen_ok = true
preen_nomessage = true
}

Mais sobre esta correção aqui:

http://stillstup.blogspot.com/2010/02/superblock-last-mount-time-is-in-future.html

GoinOff
fonte