Вопрос или проблема
У меня есть (я думаю) очень специфическая ситуация с моей встроенной Linux-системой, которую я не могу правильно решить…
Из-за особых (кастомных) проверок, которые необходимо выполнять на файловых системах при загрузке перед их монтированием, я использую начальный RAM-диск для проверки и монтирования всех запрашиваемых файловых систем, а затем переношу их в корневую файловую систему, когда инициализация завершена (поэтому не используется /etc/fstab
для монтирования устройства, а вместо этого они монтируются через скрипт, находящийся внутри начального RAM-диска).
Чтобы быть более конкретным, сначала монтируется раздел /boot
(mmcblk1p1
) (в режиме ТОЛЬКО ЧТЕНИЕ); внутри этого раздела у меня есть файл (rootfs.squashfs
), соответствующий образу squashfs целевой корневой файловой системы… так что после некоторых других операций (не относящихся к цели этого поста) скрипт начального RAM-диска в конечном итоге монтирует образ squashfs в /rootfs
, и в конце скрипта инициализации корневая файловая система системы переключается на /rootfs
(с помощью команды switch-root
);
Проблема возникает при перезагрузке системы (или завершении работы или отключении питания): когда система пытается размонтировать все смонтированные файловые системы, размонтирование /boot
завершается неудачей (поскольку устройство занято, как это очевидно, поскольку корневая файловая система смонтирована из файла squashfs, находящегося в /boot).
Существует ли способ избежать размонтирования /boot
при перезагрузке/завершении работы/отключении питания, чтобы избежать сбоя размонтирования? Поскольку оно смонтировано в режиме только для чтения, это не должно быть рискованно, правда? Или я чего-то не учитываю?
П.С.: Я не знаю, может ли это быть полезным и/или актуальным: моя инициализация ОС управляется через systemd
.
Ответ или решение
Упорядочение umount в Linux при перезагрузке/выключении
Ваша ситуация с использованием встроенного Linux требует внимательного рассмотрения управления точками монтирования во время процесса выключения или перезагрузки. Проблема, с которой вы сталкиваетесь, заключается в том, что при попытке выполнить umount для раздела /boot (который монтируется только для чтения) возникает ошибка, поскольку он используется как источник для корневой файловой системы, монтируемой из образа squashfs. Давайте рассмотрим, как можно решить эту проблему.
Причины проблемы
Когда системы, управляемые systemd, перезапускаются или выключаются, служба umount пытается очистить все точки монтирования, включая /boot. Даже если /boot монтируется только для чтения, его umount может завершиться с ошибкой, если корневая файловая система (в вашем случае /rootfs) находится в зависимом состоянии по отношению к /boot.
Следующие пункты помогут в решении проблемы:
-
Использование специальных опций для umount:
- Одним из решений может стать переопределение поведения umount в systemd. Вы можете использовать команду
systemctl
и задать параметры для управления зависимостями монтирования.
- Одним из решений может стать переопределение поведения umount в systemd. Вы можете использовать команду
-
Создание файла зависимостей:
- В systemd можно создать специфическую единицу для вашего монтирования, которая будет управлять зависимостями. Например, вы можете создать файл службы для монтирования /boot, который будет зависеть от монтирования корневой файловой системы. Нужно настроить его так, чтобы shutdown не вызывал умонтирование /boot до тех пор, пока корневая файловая система не будет автоматически размонтирована.
-
Обработка ошибок при umount:
- Можно также обрабатывать ошибки при выполнения umount, чтобы игнорировать ошибки размонтирования для разделов, которые не могут быть демонтированы из-за зависимостей. В некоторых конфигурациях, если файловая система монтируется только для чтения, это может быть приемлемым.
-
Модификация процесса shutdown:
- Обратите внимание на order of units в systemd. Вы можете задать
After=
иBefore=
в конфигурационных файлах вашего монтирования, чтобы предотвратить проблемы, связанные с зависимостями.
Пример конфигурации:
[Mount] What=/dev/mmcblk1p1 Where=/boot Type=auto Options=ro [Install] WantedBy=multi-user.target
- Обратите внимание на order of units в systemd. Вы можете задать
Беспечный подход
Если /boot монтируется только для чтения, можно рассмотреть возможность оставлять его смонтированным в течение всего времени работы системы, исключая его из процесса umount. Это может потребовать модификации стандартных сценариев при перезагрузке и выключении, но это обеспечит стабильность, избегая ошибок.
Тем не менее, необходимо быть осторожным — если вы не собираетесь размонтировать /boot, важно учитывать, как это повлияет на безопасность и управление системой. Регулярные проверки должны оставаться частью вашего процесса, чтобы гарантировать целостность файловой системы.
Заключение
Приведенные выше методы предлагают различные подходы к решению вашей проблемы с umount в процессе перезагрузки и выключения. Хотя вы можете оставить /boot смонтированным для чтения, вам необходимо учитывать, как это скажется на долгосрочной стабильности системы и ее безопасность. Используйте systemd для управления этими процессами, уделяя внимание зависимостям и особенностям системы, чтобы минимизировать потенциальные проблемы.