Настоятельно просим вас при общении соблюдать Правила форума и законы РФ. Наша тематика вне политики, поэтому воздержитесь от обсуждения ситуации на Украине и связанных с ней событий, независимо от того, какую сторону вы поддерживаете.
Также напоминаем, что наш форум находится в доменной зоне .ru, физически расположен на российских серверах и мы соблюдаем действующее законодательство России. Любые сообщения о политике будут удаляться.
Linux Forum → Red Hat Linux, Fedora, CentOS → Ошибка: "e2fsck: Cannot continue, aborting"
Страницы 1
Чтобы отправить ответ, вы должны войти или зарегистрироваться
Добрый день,
у меня перестал загружатся сервер.
При загрузке пишет e2fsck: Cannot continue, aborting
и требует чтобы я ввел пароль рута.
Это произошло после как я убрал один жесткий диск с файловой системой NTFS. Он не использовался, тупо стоял в сервере. Было 4-ре жестких диска, стало 3.
Теперь вот на ровном месте сервер не загружается, когда ввожу пароль рута, ФС переходит в режим ReadOnly.
А если в /etc/fstab закомментировать соответствующую строку?
В /etc/fstab не прописывал доступ к NTFS диску.
Но там есть строчка монтирования массива из двух жестких дисков Ext4.
В общем в сервере 4 диска:
1. Seagate 80 Гб Ext4
2. Samsung 1 Тб Ext4
3. Samsung 1 Тб Ext4
4. Seagate 2 Тб NTFS
Я убрал 4 диск.
Надо убрать массив из автозагрузки?
Может это произошло потому что имена дисков поменялись?
------------------------------
Убрал массив, все заработало.
Теперь надо разобраться почему так произошло.
Проблема решена следующим образом:
1. Система грузилась с ФС в режиме ReadOnly, пришлось переводить ФС в режим записи/чтения командой
mount -o remount,rw /2. Закоментировал в /etc/fstab строчку монтирования массива
3. Reboot
4. Переименовал старый конфиг файл массива /etc/mdadm.conf в /etc/mdadm.conf.old
5. Сгенерировал новый конфиг файл массива /etc/mdadm.conf
mdadm --detail --scan --verbose > /etc/mdadm.conf6. Раскоментировал в /etc/fstab строчку монтирования массива
7. reboot
8. Профит!
Но конечно страшко когда сервак перестает грузится.
Переходи на именование разделов не по /dev/sdX, а по их UUID, тогда никакой путаницы с именами не будет.
Переходи на именование разделов не по /dev/sdX, а по их UUID, тогда никакой путаницы с именами не будет.
Ога, и будет ТС смотреть на эти UUID'ы как на карту Марса - вроде все понятно, но ничего похожего на карту Земли. Знаем, плавали. Зачем с боьной головы на здоровую перекладывать, мне непонятно.
А чего там непонятного?
ls -l /dev/disk/by-uuid/
показывает те же /dev/sdX
Да и команда blkid тоже.
Лучше уж использовать UUID и вообще не задумываться об этих именах, чем сталкиваться с такими проблемами и постоянно путаться в именах разделов.
А чего там непонятного?
Лишний уровень абстракции, читабельность конфигов снижается. Не думаю, что на сервере нужно постоянно перенастривать дисковую подсистему.
Думаю на сервере всё может быть. Как мы видим, топикстартер столкнулся именно с этим.
Vascom, ТС делает это постоянно? А на практике от UUID'ов только головной боли больше.
Откуда головная боль от UUID? Настроил один раз и забыл.
Гладко бывает только на бумаге, а эта система работает пока все хорошо. В данном случае что так, что этак, разницы нет, ТС все равно бы получил проблему, т.к. он один диск убрал, а запись для него в fstab осталась. Только в случае с UUID ему бы пришлось тратить время на разборки - какой UUID какому диску принадлежит.
Лучше уж использовать UUID и вообще не задумываться об этих именах, чем сталкиваться с такими проблемами и постоянно путаться в именах разделов.
Что то мне подсказывает, что вместо UUID можно использовать и метку диска, то есть LABEL. А метки можно вполне осмысленными делать.
Подведем итоги, на сервере массив можно собирать из:
1. Дисковых имен типа sda, sdb, sdc и т.д.
2. Из идентификаторов дисков UUID
3. По меткам которые задает пользователь
Век живи - Век учись!
RH - рулит!
Страницы 1
Чтобы отправить ответ, вы должны войти или зарегистрироваться
Linux Forum → Red Hat Linux, Fedora, CentOS → Ошибка: "e2fsck: Cannot continue, aborting"
Форум работает на PunBB, при поддержке Informer Technologies, Inc
