Сервер CentOS загружается, но не разрешает вход (ext3_abort_called, remounts только для чтения)
У меня есть сервер CentOS 5.5 (HP ProLiant с двухдисковым RAID-массивом), который работал нормально до сбоя питания на прошлой неделе. (Длинная история, но ИБП не был должным образом сконфигурирован в то время.) После сбоя питания сервер вернулся в рабочее состояние и работал в течение дня или двух, но становился все медленнее при веб-обращениях, а затем я не мог войти через SSH. Пользователь на консоли (сервер находится на расстоянии более 4000 миль от моего нынешнего местоположения) также не может войти в систему. Меня беспокоили проблемы с аппаратным обеспечением, поэтому мне помогли загрузить его с компакт-диска восстановления системы.
e2fsck нужно было сделать восстановление журнала, но в остальном все сначала было проверено. Сделал правильную перезагрузку, и система вышла без каких-либо серьезных красных флажков. (К сожалению, парень, которого я нашел в консоли, не очень хорошо замечает то, что может быть ненормальным, но ничего не появляется как предупреждение или ошибка.) Когда он пытается войти в систему с консоли, он принимает имя пользователя, но как только когда он начинает вводить пароль, он получает "аудит =1100 (1291752714.120:13)", за которым следует то, что он называет ерундой (я знаю, я знаю, что, вероятно, мне нужен он, чтобы дать мне его дословно), оканчиваясь на "ext3_abort называется "и" Перемонтирование файловой системы только для чтения ".
Я думаю, хорошо, может быть, есть что-то, чего не нашел первоначальный fsck, так что давайте сделаем сканирование плохих блоков. Перезагрузился, чтобы спасти CD, и выполнил e2fsck -c на всех разделах прошлой ночью, и о плохих блоках не сообщалось. Сейчас я выполняю неразрушающую проверку чтения-записи, но из-за размеров раздела я не думаю, что это будет очень эффективное использование времени. Когда я проверяю логи с загрузки с жесткого диска, на котором вход в систему был невозможен, это вообще не касается проблем с диском, что меня озадачивает.
Журналы до начала проблем на прошлой неделе показывают, что были какие-то проверки на сервере, поэтому какой-то компромисс у меня на уме. Я играю за удаленную чистую установку, но я подумала, что у кого-нибудь возникнут идеи, почему загрузка с жесткого диска может привести к проблемам с диском, а fscking с аварийного компакт-диска не предлагает никаких проблем. Кто-нибудь видел такое поведение раньше? Что еще нужно сделать, чтобы проверить аппаратные проблемы, прежде чем тратить время на переустановку?
Благодарю.
2 ответа
e2fsck просто не решает все проблемы. У меня есть виртуальная машина Linux, которая имеет ошибку файловой системы, где она показывает некоторые файлы, но не позволяет мне удалить их. Если я e2fsck, накопитель e2fsck заходит в бесконечный цикл и никогда не заканчивается. Иногда самый простой способ - просто скопировать данные, повторно выполнить mke2fs и начать заново...
Может быть интересно бежать rpm -Va
сравнить контрольные суммы ваших установленных пакетов. (С диска восстановления используйте --root
как необходимо.)