systemd, fstab mount failed

В гугл спрятал, а я нашла! И ты найдешь.

Покажи grep boot /etc/fstab и systemctl list-unit-files '*boot*'

и systemctl status boot.mount ещё

UUID=... /boot xfs defaults 0 0

Во втором всякие посторонние штуки (reboot.target итд), про раздел ничего нет.

И journalctl -u boot.mount тоже не вдаётся в подробности?

P.S. А, стоп, у тебя же через fstab монтирование, а не через юнит…

спрятал лог неудавшегося mount-а при старте

А он есть? Там же, вроде как, монтирует юнит, и, если в него не прописать LIBMOUNT_DEBUG=all, то сообщений и не будет?

Ребутать для проверок больше нельзя.

Скопировать систему на другой носитель и запускать на другой железяке?

через fstab монтирование, а не через юнит

А это возможно? Там же systemd сам юнитов по содержимому fstab нагенерит, типа /run/systemd/generator/boot.mount

journalctl -u boot.mount

А во нашлось

mount: special device /dev/disk/by-uuid/... does not exist

почему этого нет в основном логе то? И в systemctl status boot.mount тоже только «mount exit status 32» без подробностей.

Только понятнее не стало, почему он этот by-uuid на тот момент не видел хотя загрузился с этого же устройства несколько секунд назад.

Скопировать систему на другой носитель и запускать на другой железяке?

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

Да, есть такой файл и в нём всё правильно заполнено.

systemctl stop boot.mount && systemctl start boot.mount оба отрабатывают успешно. И после них в systemctl status boot.mount наконец-то появился лог:

systemd[1]: Mounting /boot...
systemd[1]: Mounted /boot.

Но думаю дело не в юните уже а в том почему он тогда в by-uuid отсутствовал и почему оно просто упало в recovery вместо того чтобы подождать.

В корне та же ФС, что и в /boot?

xfs везде. Единственное отличие - корень в lvm, у которого pv на том же диске, монтирован через vg-lv-имя, а boot напрямую раздел диска по uuid.

multipathd случайно нет в системе?

Есть.

У меня такая же хрень была из-за него.

Там был boot from SAN. Решилась как-то очень просто, что я даже не запомнил. Кажется, пересборкой initramfs с правильным /var/lib/multipath/*

Или /boot через /dev/mpath замонтировал, не помню.

а какая разница? systemd и это тоже контролирует. никогда не видел его требования перегрузить демонов после правки fstab?

Да, согласен. Тем более и автор это сообщение нашёл после подсказки.

boot отдельно потому, что с LVM нельзя напрямую загрузиться.

Хм, ну похоже, но у меня нет /var/lib/multipath. Есть /etc/multipath/ - в нём список текстовых алиасов к multipath id-ам.

В journalctl -b логи инициализации multipath на секунду раньше логов неудавшегося монтирования. Но может при исправленном initramfs они будут ещё раньше.

boot физически локальный? grub используется?

пмсм скорее всего initramfs не совсем корректная, тут с бигбит согласен. типичный признак.

можешь распаковать её и глянуть - есть она там в архиве или нет? ну или просто попробовать по новой её сделать , -u и тыпы

Это выходит разделы на multipath нельзя монтировать по uuid? Но раньше то всё работало. Или оно рандомно то получается то нет.

э…загрузиться мог по LABEL или вообще по прямой ссылке на устройство.

этим и плохо зависеть от UUID, иногда староверство с /dev/?d? рулит!

В моем случае multipath лочил девайс. Если у тебя тоже /boot нелокальный, по попробуй /dev/mpath или даже /dev/sda1 (да, костыль, но всяко лучше, чем в recovery mode вываливаться).

так ты чо, по SAN грузишься что ли?

тогда там широкое поле для граблей!

например, был указан UUID путь, который на следующей загрузке контроллер с той стороны перевёл в запасные или вообще неактивные ибо ALUA!

смотри по blkid все пути и сравнивай со своим бутом - могут быть неожиданные открытия

ну и попробуй напрямую /dev/mapper/mpath? прописать

Да, в initramfs в /etc/multipath/ устаревший конфиг. Надо пересобрать с новым, правда проверять когда-нить потом.

Не, с uuid всё правильно.

Думаю дело действительно в том что в initramfs в /etc/multipath/ текущих wwn-ов нет и от этого что-то где-то не успевает настроиться к моменту монтирований. А монтирование по LV-имени (как у корня) почему то не ломается от этого.

sdX имя может не тем оказаться если они в другом порядке распознаются.

А вот /dev/mpathX походу создаются уже после переключения с initramfs-а на обычный корень т.к. в конфиге initramfs их нет, это и исправлю, надеюсь поможет, ну или в следующий раз увижу что не помогло.

Много раз видел, как переезжают другие диски, особенно если их много, и отданы по нескольким путям. Но вот /dev/sda почему-то всегда соответствовало системному диску. Может, потому что его всегда отдавали с LUN=0.

может потому что lv name не зависит от пути? это сущность другого порядка, если по любому из 2/4/8 путей приехала VG - то и ладно, по ней и опознается, там же обычно что-то типа:

VG UUID/LV UUID

я же не зря спросил, что у тебя там? grub? systemd? прямой EFI загрузчик? lilo? 8) и стич )))))

grub

Так uuid файловой системы на разделе тоже от пути не зависит. Могло бы примонтироваться к /dev/sdXa какому-нить. Хотя это конечно не то что нужно, надо чтобы к multipath монтировалось.

А lvm, если он инициализировал свои PV напрямую с /dev/sdXY мимо multipath-а, потом сможет использовать multipath?

ему на это пофиг, очевидно же!

обрати внимание, в grub.cfg будут упоминания VG и LV UUID но не самих дисков ))))

это же разного уровня сущности

а для бута грубу нужен конкретность

У LVM обычно фильтры прописаны на дисковые девайсы в lvm.conf. Так что скорее всего, он все правильно инициализировал.