Вопрос или проблема
У меня есть виртуальная машина, к которой подключено устройство с RAID, с записью в fstab:
/dev/md127 /mnt/blah ext4 nofail 0 2
Диски в RAID повреждены, и во время загрузки система вошла в режим экстренной/технической поддержки, что означает, что только локальный пользователь может выйти из этого режима и запуститься нормально. Во время нормальной загрузки в syslog произошло следующее:
systemd-fsck[1272]: /dev/md127 содержит файловую систему с ошибками, проверка принудительна.
systemd-fsck[1272]: /dev/md127: найдены иноды, которые были частью поврежденного списка зависших.
systemd-fsck[1272]: /dev/md127: НЕОЖИДАЕМАЯ НЕСООТВЕТСТВИЕ; ЗАПУСТИТЕ fsck ВРУЧНУЮ.
systemd-fsck[1272]: #011(т.е. без опций -a или -p)
systemd-fsck[1272]: fsck завершился с кодом выхода 4.
systemd-fsck[1272]: Запуск запроса emergency.target/start/replace
systemd[1]: [email protected]: основной процесс завершился, код=выход, статус=1/ОШИБКА
systemd[1]: [email protected]: завершился с результатом 'код выхода'.
systemd[1]: Не удалось запустить проверку файловой системы на /dev/md127.
systemd[1]: Ошибка зависимости для /mnt/blah.
systemd[1]: Ошибка зависимости для демона Provisioner client.
Мое предположение заключается в том, что ОС переходит в режим экстренной/технической поддержки из-за поврежденных дисков RAID:
systemctl --state=failed
UNIT LOAD ACTIVE SUB DESCRIPTION
● [email protected] загружен, ошибка, ошибка Проверка файловой системы на /dev/md127
Что я хочу – так это чтобы виртуальная машина запускалась, независимо от того, повреждены диски RAID или нет, поэтому она не должна переходить в режим экстренной/технической поддержки. Я следовал этим постам, чтобы попытаться отключить режим экстренной/технической поддержки:
- Как отключить агрессивное поведение экстренной оболочки systemd?
- Как точно определить, почему systemd переходит в режим экстренной поддержки
- Экстренный режим и локальный диск
Сначала мне нужно было создать каталог local-fs.target.d в /etc/systemd/system/, что показалось неправильным. Затем я создал файл nofail.conf в /etc/systemd/system/local-fs.target.d/nofail.conf, содержащий:
[Unit]
OnFailure=
После загрузки этого файла я смог подтвердить, что этот файл был найден local-fs.target:
sudo systemctl status local-fs.target
● local-fs.target - Локальные файловые системы
Загружен: загружен (/lib/systemd/system/local-fs.target; статичный; предустановленный поставщиком: включен)
Drop-In: /etc/systemd/system/local-fs.target.d
└─nofail.conf
Активен: активен с Вт 2019-01-08 12:36:41 UTC; 3ч 55мин назад
Документы: man:systemd.special(7)
НО, после перезагрузки виртуальная машина все еще закончила в режиме экстренной/технической поддержки. Я что-то упустил? Решение с nofail.conf не работает с RAID-дисками?
ИЗМ. Я смог получить распечатку логов, когда система загрузилась в режим экстренной поддержки (извините, это скриншот, так как у меня нет доступа к хосту, и мне пришлось попросить владельца об этом):
Вот вывод из systemctl для systemd-fsck@dev-md127:
sudo systemctl status --no-pager --full systemd-fsck@dev-md127
● [email protected] - Проверка файловой системы на /dev/md127
Загружен: загружен (/lib/systemd/system/[email protected]; статичная; предустановленная поставщиком: включена)
Активен: завершился с ошибкой (Результат: код выхода) с Чт 2019-01-10 12:05:44 UTC; 2ч 57мин назад
Документы: man:[email protected](8)
Процесс: 1025 ExecStart=/lib/systemd/systemd-fsck /dev/md127 (код=выход, статус=1/ОШИБКА)
Основной PID: 1025 (код=выход, статус=1/ОШИБКА)
systemd[1]: Начало проверки файловой системы на /dev/md127...
systemd-fsck[1025]: /dev/md127 содержит файловую систему с ошибками, проверка принудительна.
systemd-fsck[1025]: /dev/md127: найдены иноды, которые были частью поврежденного списка зависших.
systemd-fsck[1025]: /dev/md127: НЕОЖИДАЕМАЯ НЕСООТВЕТСТВИЕ; ЗАПУСТИТЕ fsck ВРУЧНУЮ.
systemd-fsck[1025]: (т.е. без опций -a или -p)
systemd-fsck[1025]: fsck завершился с кодом выхода 4.
systemd-fsck[1025]: Запуск запроса emergency.target/start/replace
systemd[1]: [email protected]: основной процесс завершился, код=выход, статус=1/ОШИБКА
systemd[1]: [email protected]: завершился с результатом 'код выхода'.
systemd[1]: Не удалось запустить проверку файловой системы на /dev/md127.
Как я уже упоминал ранее, у меня установлено nofail в /etc/fstab. Теперь вопросы:
- Что за зависимость в неудавшейся зависимости на скриншоте?
- Если fsck не удалось на
/dev/md127, почему система переходит в режим экстренной поддержки и как это отключить?
ИЗМ 2:
Несколько других моментов, которые я могу добавить:
- виртуальная машина является виртуальной машиной kvm
- это программный RAID
С наилучшими пожеланиями, Анкур
Ваша система попыталась исправить повреждение и автоматически загрузиться, но не смогла. Вот почему она вошла в режим экстренной поддержки.
Это не что-то, что вы можете просто переопределить, потому что файловую систему нельзя смонтировать в таком состоянии, и вы указали монтировать файловую систему при загрузке.
Вы можете попробовать одно из следующих действий:
- Не повреждайте файловую систему. Отключайте ее нормально, а не выключайте виртуальную машину прямо во время записи данных.
- Не монтируйте файловую систему автоматически (установите
noautoв/etc/fstab). Виртуальная машина запустится, но вам все равно придется позже вручную подключить файловую систему. - Перейдите на более устойчивую файловую систему, такую как XFS.
systemd не учел nofail при неудаче fsck из-за ошибки. Я исправил это в systemd 250 и далее.
Если вы застряли на более старой версии systemd, я думаю, у вас есть только один вариант – не использовать двоичный файл /lib/systemd/systemd-fsck. Возможно, не указывать файловую систему в /etc/fstab, вместо этого создав свой собственный unit systemd для fsck и монтирования.
Ответ или решение
Проблема с поврежденным RAID-носителем на Ubuntu 18.04: Решение и рекомендации
Вы столкнулись с трудной ситуацией, когда ваша виртуальная машина (VM) на основе Ubuntu 18.04 попадает в режим восстановления (или экстренный режим) из-за ошибок на RAID-устройстве, подключенном к системе. В этом ответе мы рассмотрим причины этой проблемы, шаги для ее устранения и рекомендации для предотвращения подобного в будущем.
1. Причины возникновения проблемы
При загрузке вашей системы система обнаружила повреждения на RAID-носителе /dev/md127, что привело к вызову fsck (инструмента для проверки файловых систем). Как видно из логов, система сообщает о следующих проблемах:
- Ошибки в файловой системе: "UNEXPECTED INCONSISTENCY; RUN fsck MANUALLY".
- Зависимости: Система не может осуществить загрузку в обычном режиме, так как файловая система, на которую указывает
/etc/fstab, не может быть смонтирована.
2. Причины перехода в экстренный режим
Вы правы в своем понимании того, что наличие ошибок на RAID-дисках является основной причиной перехода системы в экстренный режим. Система не может демонтировать поврежденный носитель, и, следовательно, загрузка продолжается в безопасном режиме. Указание на nofail в fstab не позволяет избежать перехода в экстренный режим в случае, если fsck завершился с ошибкой.
3. Решение проблемы
Шаг 1: Выполнение fsck вручную
Вы должны перезапустить систему и вручную выполнить проверку файловой системы:
- Загрузитесь в экстренный режим.
- Выполните команду
fsckна устройстве RAID:fsck /dev/md127В процессе могут появляться запросы на исправление ошибок.
Шаг 2: Изменение настроек монтирования
Для предотвращения перехода в экстренный режим в будущем вы можете сделать следующее:
- Уберите запись о RAID из
/etc/fstab, если вам не требуется автоматическое монтирование. Это позволит системе загружаться без зависимостей на файловую систему. - Если вам нужно сохранить запись в
fstab, заменитеnofailнаnoauto. Это отключит автоматическое монтирование при загрузке.
Пример строки для /etc/fstab:
/dev/md127 /mnt/blah ext4 noauto 0 2Шаг 3: Использование альтернативных файловых систем
Вы также можете рассмотреть возможность использования более устойчивых файловых систем, таких как XFS. Эти файловые системы могут избежать некоторых проблем, связанных с частью зависимостей на уровне RAID.
4. Рекомендации по профилактике
Чтобы избежать подобных ситуаций в будущем, следуйте этим рекомендациям:
- Избегайте необдуманных выключений: Убедитесь, что система корректно выключается и не происходит отключений питания во время записи данных.
- Регулярные резервные копии: Создавайте резервные копии критически важных данных. Используйте инструменты автоматизации резервного копирования, такие как
rsyncили специализированные решения для виртуальных машин. - Мониторинг состояния RAID: Используйте инструменты мониторинга, такие как
mdadm, для отслеживания состояния RAID и предотвращения возможных сбоев системы.
Заключение
Проблемы с RAID-носителями могут вызвать значительные затруднения, особенно если вы не вовремя обнаружите ошибки. Следуя приведенным шагам, вы сможете восстановить доступ к вашему RAID и предотвратить повторение проблем в будущем. Если возникнут дополнительные вопросы, не стесняйтесь обращаться за помощью.