Сервер Linux работает нормально, обновления в последнее время не устанавливались, но сегодня утром совершенно неожиданно сервер перестал отвечать. Я пошел проверить его, и он сказал, что есть проблема с файловой системой, и сказал: «Вам следует запустить fsck вручную».
Я запустил fsck на соответствующем разделе и исправил все предложенные проблемы с индексами. После перезапуска я теперь вижу следующие сообщения:
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
Кто-нибудь знает, как я могу это решить? Я не особенно знаком с Linux, поэтому, пожалуйста, будьте подробны, когда предлагаете решения.
Я не хочу переустанавливать Linux, если я могу этого избежать, поскольку на сервере хранятся ценные данные за 5 лет. Любая помощь приветствуется!
Как отметил @Blender в своем комментарии, это звучит как сбой жесткого диска. Поскольку вы не очень хорошо знакомы с Linux, я бы посоветовал вам первым делом найти кого-то, кто сделает это, так как решение такого рода проблемы (или даже полное понимание) может быть затруднено, если вы не знаете некоторых тонкостей. Linux.
Сначала используйте Live CD или Live USB-накопитель (см. Knoppix в качестве примера или Ubuntu), чтобы загрузить машину и посмотреть, сможет ли она смонтировать диск (ы). Если это возможно, скопируйте важные данные (вы все равно должны создать резервную копию этого материала, но это отдельная проблема), а затем попытайтесь отследить, какое оборудование вышло из строя. Если это жесткий диск, замените его.
Вы также можете посмотреть журналы, чтобы попытаться выяснить, в чем проблема заключалась в первую очередь. Для оборудования я бы проверил /var/log/dmesg. В зависимости от типа диска (и версии ядра и т. Д.) Вы увидите разные сообщения. Когда диск подключен к контроллеру SCSI / Raid, вы можете увидеть сообщения, относящиеся к командам SCSI, которые повреждены или на которые не отвечают. Вы также можете увидеть сообщения о том, что время записи истекло (в качестве другого примера). Трудно сказать, что вы увидите, поскольку это зависит от аппаратного обеспечения и версий ядра.
Ты можешь использовать smartctl --all /dev/<hard disk> чтобы проверить УМНАЯ Информация. Он встроен в жесткий диск, и с его помощью диск может сказать вам, насколько он звук.
Вы видите ошибку JBD, потому что журнал EXT3 искажен. Если дистрибутив Live USB / CD не может смонтировать раздел из-за этого, вы можете смонтировать разделы ext3 как ext2 (который игнорирует журнал), чтобы отключить данные. Но опять же, это то, что вам может потребоваться немного больше опыта в использовании Unix, чтобы иметь возможность справиться с этим. Однако вы можете выполнить эту процедуру в Google и посмотреть, сможете ли вы выполнить ее при загрузке с Live USB / CD, чтобы можно было смонтировать раздел.
Как предложил Jure1873, возьмите загрузочный диск и проверьте привод.
Но пока вы это делаете, смонтируйте диск и посмотрите, сможете ли вы прочитать записанные журналы. Ищите информацию, ведущую к отказу диска. Посмотрим, есть ли на загрузочном диске признаки ошибок в журналах при чтении с привода.
Я бы также попытался скопировать данные с диска на другой диск, используя что-то вроде dd-rescue, если данные вам дороги.
Загрузитесь с аварийного компакт-диска и проверьте диски.
Я не уверен в Red Hat Enterprise Linux 6, но в RHEL 5 это происходит, когда один RPM с именем «SysVinit» удаляется. Чтобы решить эту проблему, загрузитесь из режима восстановления и установите этот RPM.