Леннарт Поттеринг

Неделю назад кончился жёсткий диск в сервере. Вот в том, который отдал вам сейчас эту страничку. Приказал долго жить бэкапый диск, который не состоял в RAID’е. Проблема лишь в том, что на нём ещё были /boot и GRUB. Потеря загрузчика — не слишком большая беда, так как в этом деле главное не перезагружаться, пока не будет готов диск на замену. Вчера утром он был уже был мной подготовлен, и я собирался ехать в ДЦ, чтобы его поставить в сервер. Инструменты, документы, и надо было сделать live-флешку. Сервер, конечно, должен был штатно стартовать с тем диском, который для него был подготовлен, но мало ли что… Берём флешку, вставляем, делаем dd… и понимаем, что dd мы сделали на ту флешку, на которой лежит /boot и GRUB моей домашней машины (да, дома у меня тоже RAID и отдельный /boot). Это печально, но…

Как мы уже знаем, потеря загрузчика и /boot — не слишком большая проблема. Главное, как уже было отмечено, не перезагружаться. Надо было лишь переразметить пострадавшую флешку, смонтировать её и переставить GRUB. Но… новый /boot упорно не монтировался! mount возвращает 0, в dmesg записи об успешном монтировании, а в /proc/mounts её нет! Как, мать его, так?! А что если глянуть логи systemd?

-- Logs begin at Sun 2017-12-10 05:36:11 MSK, end at Sun 2017-12-10 11:25:02 MSK. --
дек 10 11:19:58 arcturus kernel: EXT4-fs (sdc2): mounting ext2 file system using the ext4 subsystem
дек 10 11:19:58 arcturus kernel: EXT4-fs (sdc2): mounted filesystem without journal. Opts: (null)
дек 10 11:19:58 arcturus systemd[1]: boot.mount: Unit is bound to inactive unit dev-disk-by\x2duuid-b236eeed\x2dfcaa\x2
дек 10 11:19:58 arcturus systemd[1]: Unmounting /boot...
-- Subject: Начинается остановка юнита boot.mount
-- Defined-By: systemd
-- Support: https://www.debian.org/support
-- 
-- Начат процесс остановки юнита boot.mount.
дек 10 11:19:58 arcturus systemd[1]: Unmounted /boot.
-- Subject: Завершена остановка юнита boot.mount.
-- Defined-By: systemd
-- Support: https://www.debian.org/support
-- 
-- Процесс остановки юнита boot.mount был завершен.
дек 10 11:25:02 arcturus kernel: EXT4-fs (sdc2): mounting ext2 file system using the ext4 subsystem
дек 10 11:25:02 arcturus kernel: EXT4-fs (sdc2): mounted filesystem without journal. Opts: (null)
дек 10 11:25:02 arcturus systemd[1]: boot.mount: Unit is bound to inactive unit dev-disk-by\x2duuid-b236eeed\x2dfcaa\x2
дек 10 11:25:02 arcturus systemd[1]: Unmounting /boot...
-- Subject: Начинается остановка юнита boot.mount
-- Defined-By: systemd
-- Support: https://www.debian.org/support
-- 
-- Начат процесс остановки юнита boot.mount.
дек 10 11:25:02 arcturus systemd[1]: Unmounted /boot.
-- Subject: Завершена остановка юнита boot.mount.
-- Defined-By: systemd
-- Support: https://www.debian.org/support
-- 
-- Процесс остановки юнита boot.mount был завершен.

Ага! Короче, systemd при запуске создаёт ресурсные записи для точек монтирования, которые она почерпнула из fstab. /boot был мной размонтирован, и systemd решил, что этот сервис-ресурс теперь stoped. Я поправил fstab и смонтировал /boot. fstab systemd читает ТОЛЬКО при запуске системы, так что данные о ресурсе оно не обновило. У нового раздела был другой UUID, так что systemd решил, что это что-то, что должно быть отмонтировано сразу. Нафиг. Как всё это вообще возможно? Погуглил, и мне стало понятно, что возможно, и ещё как!

А что самое характерное, в том треде, что я нашёл, засветился сам Поттеринг! И конечно, это, с его точки зрения, и не баг это вообще. Типа вполне себе правильное поведение. Ещё разок, это тело считает, что отмонтирование init’ом (init’ом Карл!) нового раздела, который даже внесён в fstab, сразу после его монтирования, — это нормально. Тот факт, что администратор системы после выполнения mount ещё и не получает никаких предупреждений — тоже нормально. И исправить поведение systemd может только перезагрузка. Да он больной!

Короче, linux стал так распространён и популярен только лишь потому, что практиковался unix-way: система состоит из простых и хорошо отлаженных компонентов, сочетанием которых можно достигать потрясающего результата при минимальных денежно-временных вложениях. TMTOWTDI во всём. Пример с восстановлением /boot — каноничен. Просто потому, что никогда не было проблемой содержать не критичные данные без RAID’а. Зачем, если всегда можно заменить сбойный носитель и вернуть пропавшую директорию на место? Но теперь больше так нельзя! Ынтерпрайз тогда, когда у тебя всё на аппаратном RAID’е, а init может по своей воле взять и размонтировать тебе любую точку в ФС.

Надеюсь, что этот упорышь будет страдать…

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

Ваш e-mail не будет опубликован. Обязательные поля помечены *

÷ 8 = 1