Не удается отмонтировать контейнер LUKS, смонтированный systemd в RAID.

Вопрос или проблема

Я смонтировал раздел raid1 luks, не являющийся корневым, который автоматизирован через созданный юнит монтирования. Недавно я обнаружил, что файловая система повреждена, и решил проверить её с помощью fsck удаленно, не перезагружая сервер.

Так что я остановил юнит и попытался выполнить fsck, но получил ответ, что устройство всё ещё видится как смонтированное. То же самое происходит, когда я пытаюсь размонтировать вручную: система сообщает, что ресурс занят, и только ленивое размонтирование работает, но результат такой же, как и при остановке юнита.

Таким образом, я решил изменить Options=defaults,noauto в юните монтирования. Остановка/запуск приводят к ошибкам. В логе я вижу: kernel: [258607.858951] dm-1: Can't mount, would change RO state.

Так как же правильно размонтировать раздел и выполнить fsck, не перезагружая в режим live, который нельзя контролировать удаленно?

Ответ или решение

Для решения проблемы с размонтированием системного раздела LUKS на RAID1, который был автоматически смонтирован с помощью unit-файла systemd, важно выполнить несколько шагов для обеспечения корректной работы. Давайте разберем вашу ситуацию и предложим последовательные действия.

Анализ проблемы

Вы столкнулись с ситуацией, когда после остановки unit-файла и попытки размонтирования раздела система сообщает, что устройство занято. Эта проблема может возникнуть по нескольким причинам, включая процессы, которые продолжают использовать файловую систему или специальные ограничения, связанные с работающими модулями RAID и LUKS.

Шаги по решению проблемы

  1. Проверка активных процессов: Первоначально необходимо убедиться, что никакие процессы не используют файловую систему. Для этого выполните команду:

    lsof +D /путь/к/монтированному/разделу

    Эта команда покажет, какие процессы могут блокировать размонтирование. Если такие процессы есть, прекратите их выполнение.

  2. Использование fuser для определения зависимостей: Если команда lsof не помогла, вы можете использовать fuser:

    fuser -m /путь/к/монтированному/разделу

    Это отобразит ID процессов, использующих раздел.

  3. Принудительное размонтирование: Если вы уверены, что все процессы завершены, можно попробовать принудительное размонтирование:

    umount -l /путь/к/монтированному/разделу

    Ленивая (lazy) размонтировка не всегда безопасна, так как она может привести к неожиданному поведению системы, если к устройству все же будут обращаться.

  4. Изменение параметров unit-файла: Вы упомянули, что собираетесь изменить настройки unit-файла. Убедитесь, что вы корректно обновили его, добавив Options=defaults,noauto. После этого перезапустите systemd и проверьте статус:

    systemctl daemon-reload
    systemctl status имя_unit-файла
  5. Запуск fsck в режиме "только для чтения": Если файловая система все еще отображается как смонтированная, попробуйте выполнить проверку с параметрами, которые позволят избежать конфликта с kernel:

    fsck -f /dev/имя_устройства

    Часто fsck может быть запущена в режиме, невозможном для монтирования, что дублируется в журнале.

  6. Перезагрузка для доступа к Live Mode: Если проблема все еще не решена, может потребоваться перезагрузка сервера. Вы можете попробовать инициировать перезагрузку через SSH и убедитесь, что все необходимые сохранения данных выполнены.

Заключение

Размонтирование LUKS-разделов, особенно в контексте RAID, требует тщательного подхода и понимания того, какие процессы могут блокировать доступ к файловой системе. Следуя приведенным выше шагам и обеспечивая тщательную проверку процессов, вам удастся выполнить необходимые операции без перезагрузки системы в живом режиме. Если же все попытки провалились, возможно, стоит рассмотреть консультацию с более опытными системными администраторами, знакомыми с вашей средой.

Оцените материал
Добавить комментарий

Капча загружается...