Назад | Перейти на главную страницу

Сервер CentOS загружается, но не разрешает вход в систему (ext3_abort_called, перемонтирует только для чтения)

У меня есть сервер CentOS 5.5 (HP ProLiant с двухдисковым RAID-массивом), который работал нормально до отключения электроэнергии на прошлой неделе. (Долгая история, но в то время ИБП не был настроен должным образом.) После сбоя питания сервер вернулся в онлайн и проработал день или два, но становился все медленнее при посещении веб-сайтов, и затем я не мог войти в систему через SSH. Пользователь консоли (сервер находится в 4000+ миль от моего текущего местоположения) тоже не смог войти в систему. Меня беспокоят проблемы с оборудованием, поэтому у меня есть местная помощь, чтобы загрузить его с аварийного компакт-диска.

e2fsck нужно было восстановить журнал, но в остальном все сначала проверилось. Произошла правильная перезагрузка, и система работала без серьезных красных флажков. (К сожалению, парень, который у меня есть за консолью, не очень хорош в обнаружении того, что может быть ненормальным, но ничего не вышло как предупреждение или ошибка.) Когда он пытается войти в консоль, он берет имя пользователя, но как только когда он начинает вводить пароль, он получает «type = 1100 audit (1291752714.120: 13)», за которым следует то, что он называет бессмыслицей (я знаю, я знаю, мне, вероятно, нужно, чтобы он дал мне его дословно), заканчивающееся словами « ext3_abort называется "Перемонтирование файловой системы только для чтения".

Я полагаю, хорошо, может быть, есть что-то, чего не нашел исходный fsck, поэтому давайте проведем сканирование плохих блоков. Перезагрузился на аварийный компакт-диск и вчера вечером выполнил e2fsck -c на всех разделах, и не было зарегистрировано ни одного плохого блока. Сейчас я запускаю неразрушающую проверку чтения-записи, но из-за размеров разделов я не думаю, что это будет очень эффективное использование времени. Когда я проверяю журналы загрузки с жесткого диска, где вход в систему невозможен, я не вижу никаких проблем с диском, что меня смущает.

Журналы, полученные до появления проблем на прошлой неделе, показывают, что на сервере было проведено несколько проверок, поэтому я думаю о каком-то компромиссе. Я играю за чистую установку удаленно, но я подумал, что посмотрю, есть ли у кого-нибудь идеи, почему загрузка с жесткого диска может указывать на проблемы с диском, но поиск с аварийного компакт-диска не предлагает никаких проблем. Кто-нибудь видел такое поведение раньше? Что еще мне нужно сделать, чтобы проверить наличие проблем с оборудованием, прежде чем тратить время на повторную установку?

Спасибо.

e2fsck просто не решает всех проблем. У меня есть виртуальная машина linux с ошибкой файловой системы, где отображаются некоторые файлы, но не позволяет мне их удалить. Если я e2fsck, диск e2fsck зацикливается и никогда не завершается. Иногда самый простой способ - просто скопировать данные, повторно запустить mke2fs и начать заново ...

Может быть интересно запустить rpm -Va для сравнения контрольных сумм установленных пакетов. (С аварийного диска используйте --root как надо.)