Inicialize com um CD de recuperação e verifique os discos.
O servidor Linux está funcionando bem, sem atualizações instaladas recentemente, mas, inesperadamente, esta manhã, o servidor parou de responder. Eu fui verificá-lo e ele estava dizendo que há um problema com o sistema de arquivos e afirmou 'você deve executar o fsck manualmente'.
Eu executei fsck na partição relevante e corrijo todos os problemas de inode sugeridos. Depois de reiniciar, agora são mostradas as seguintes mensagens:
JBD: no valid journal superblock found
EXT3-fs: error loading journal
mount: error 22 mounting ext3
Switching to new root
ERROR opening /dev/console!!!!:2
Kernel panic - no syncing: Attempting to kill init
Alguém tem alguma ideia de como posso resolver isso? Eu não estou particularmente familiarizado com o Linux, por isso, seja detalhado quando sugestões de soluções.
Eu não quero reinstalar o Linux se puder evitá-lo, pois o servidor tem cerca de 5 anos de dados valiosos lá. Qualquer ajuda apreciada!
Inicialize com um CD de recuperação e verifique os discos.
Como Jure1873 sugeriu, pegue um disco de inicialização e fsck a unidade.
Mas enquanto você está nisso, monte o disco e veja se consegue ler os registros que estão gravados. Procure informações que levem à falha do disco. Heck, veja se o disco de boot também mostra sinais nos logs de erros enquanto eles lêem a unidade.
Eu também tentaria copiar os dados do disco para outro disco, usando algo como dd-rescue, se os dados forem valiosos para você.
Como o @Blender mencionou em seu comentário, isso soa como uma falha no disco rígido. Como você não conhece muito bem o Linux, eu sugeriria que seu primeiro ponto de escala seria encontrar alguém que consiga corrigir esse tipo de problema (ou até mesmo entender completamente), pode ser difícil se você não conhece algumas das complexidades. do Linux.
Primeiro, use um Live CD ou Live USB stick (veja Knoppix como um exemplo ou Ubuntu ) para inicializar a máquina e ver se ela pode montar o (s) disco (s). Se puder, copie os dados importantes para fora (você deve estar fazendo o backup desse material de qualquer maneira, mas isso é um problema separado) e tente rastrear o hardware que falhou. Se for um disco rígido, substitua-o.
Você também pode ver os registros para tentar descobrir qual era o problema. Para hardware, verifiquei /var/log/dmesg . Dependendo do tipo de unidade (e versão do kernel, etc.), você verá mensagens diferentes. Quando a unidade está conectada a um controlador SCSI / Raid, você pode ver que as mensagens relacionadas aos comandos SCSI estão corrompidas ou não estão sendo respondidas. Você também pode ver mensagens dizendo que as gravações expiraram (como outro exemplo). É difícil dizer o que você pode ver, pois depende das versões do hardware e do kernel.
Você pode usar smartctl --all /dev/<hard disk> para verificar as informações SMART . Isso é embutido no disco rígido e é a maneira que o disco pode dizer como é o som.
O erro do JBD que você vê é porque o diário EXT3 está corrompido. Se a distro Live USB / CD não puder montar a partição por causa disso, você pode montar partições ext3 como ext2 (que ignora o diário) para obter os dados desativados. Mas, novamente, isso é algo que você pode precisar ser um pouco mais experiente em usar o Unix para conseguir fazer isso. No entanto, você pode fazer um Google para este procedimento e ver se você pode executá-lo enquanto inicializado a partir do Live USB / CD para permitir que você monte a partição.
Não tenho certeza sobre o Red Hat Enterprise Linux 6, mas no RHEL 5 ele ocorre quando um RPM chamado 'SysVinit' é removido. Para resolver isso, inicialize a partir do modo de recuperação e instale esse RPM.
Tags linux redhat linux-kernel