периодически проблемы при загрузке arch

Хотя бы иногда ты в состоянии загрузиться в систему? Если да, то добейся загрузки и сделай вот это (от рута):

systemctl enable lvm2-monitor lvm2-lvmetad
systemctl status lvm2-monitor lvm2-lvmetad

я же написал, В большинстве случаев система грузится нормально, но иногда возникает эта проблема,

Created symlink from /etc/systemd/system/sysinit.target.wants/lvm2-monitor.service to /usr/lib/systemd/system/lvm2-monitor.service.
Created symlink from /etc/systemd/system/sysinit.target.wants/lvm2-lvmetad.service to /usr/lib/systemd/system/lvm2-lvmetad.service.
[tm4ig@sinx ~]$ sudo systemctl status lvm2-monitor lvm2-lvmetad
● lvm2-monitor.service - Monitoring of LVM2 mirrors, snapshots etc. using dmeventd or progress polling
   Loaded: loaded (/usr/lib/systemd/system/lvm2-monitor.service; enabled)
   Active: inactive (dead)
     Docs: man:dmeventd(8)
           man:lvcreate(8)
           man:lvchange(8)
           man:vgchange(8)

● lvm2-lvmetad.service - LVM2 metadata daemon
   Loaded: loaded (/usr/lib/systemd/system/lvm2-lvmetad.service; enabled)
   Active: active (running) since Чт 2014-10-23 22:34:56 MSK; 41min ago
     Docs: man:lvmetad(8)
 Main PID: 250 (lvmetad)
   CGroup: /system.slice/lvm2-lvmetad.service
           └─250 /usr/bin/lvmetad -f
[tm4ig@sinx ~]$ 

Ну я просто уточнил.

Ага, понятно. Выключены были эти сервисы... Ну теперь можно тестить — если дело было именно в этом, проблема должна исчезнуть.

Ах да, я (по всей видимости) немного неправильный совет дал: lvm2-lvmetad включать было необязательно, он запускается автоматически при необходимости.
Так что можно выключить обратно:

systemctl disable lvm2-lvmetad

Интересно. У меня аналогичная проблема.

Аналогичная гипотеза: проверь юнит lvm2-monitor.service; если выключен — включи.

Спасибо, за помощь, но не сработало три раза подряд ребутнулся, два раза все хорошо, на третий опять тоже самое
http://itmages.ru/image/view/1999234/251885d0
http://itmages.ru/image/view/1999236/81376b3e

Был выключен. Теперь включил. Но что с ним дальше делать?

tm4ig Medar

Так, похоже, я совсем не прав. Соответствующий багрепорт: FS#41833.

Как насчёт запихнуть systemd в initramfs? Файл /etc/mkinitcpio.conf:

HOOKS="systemd sd-lvm2 autodetect modconf block filesystems keyboard fsck"

И пересобрать initcpio (mkinitcpio -p linux).

Прописывать именно в таком порядке? в руководстве сказано:

You will need to make sure the udev and lvm2 mkinitcpio hooks are enabled. udev is there by default. Edit the file and insert lvm2 between block and filesystems:[quote.]

А у нас не udev и lvm2, а systemd и sd-lvm2. Их без разницы, куда пихать.

10 ребутов - ошибок нет, думаю совет выше действительно помог

У меня вот такая строка.

HOOKS="base udev autodetect modconf block lvm2 filesystems keyboard fsck"

base и udev можно заменять на systemd, а lvm2 на sd-lvm2 ?

Вроде того.

Спасибо, попробую. Но ноутбук я не выключаю, так что не знаю, когда выйдет проверить.

Это было бы хорошо. Я сейчас читаю багрепорт (и ещё один в багзилле Федоры) — там как-то очень криво всё сделано сейчас; не удивлюсь, если через пятьдесят ребутов оно опять проявится...

действительно, это опять произошло, причем два раза подряд в чем дело-то?

Апстримный баг: https://bugzilla.redhat.com/show_bug.cgi?id=1148352

pvscan не успевает завершиться до того, как останавливается udev. Я, в общем-то, не знаю, что с этим делать. Там предлагают вернуться к не-systemd в initramfs и запилить костыль вида «подождём, пока не останется процессов pvscan».

Альтернативно, можно пропатчить lvm2-pvscan@.service (и команду systemd-run в правиле udev'а) так, чтобы запускаемый pvscan был отсортирован After=systemd-udevd.service, но, поскольку у меня нет LVM, не могу проверить это решение.

Ну и BindsTo=systemd-udevd.service, конечно же, т. к. упорядочивание не подразумевает зависимости.

Есть возможность протестировать этот патч — ftp://intelfx.homenet.org/after-udevd.patch ?

cd /
sudo patch -Np1 -i <путь-к-патчу>
sudo mkinitcpio -p linux

Соответственно, в initramfs должен быть systemd (т. е. HOOKS="systemd ...").

Пришлось выключить ноут и решил, что пора попробовать твой патч. Но, примерно за 30 загрузок проблема не вылезла.

systemd в initramfs не запихивал. Может это в 3.14.23-1-lts пофиксили или в systemd 216-3 ?

Так что патчем пока не воспользовался.

Нет, эта проблема не имеет отношения ни к ядру, ни к systemd. Поэтому там её пофиксить не могли.

Но что-то то случилось. Раньше эта проблема вылазила стабильно на пять перезагрузок. Понаблюдаю еще.

Это же race condition. Могли поправить драйвера так, что обнаружение дисков стало выполняться быстрее. Или ещё что-то в этом роде. Понятия не имею.

Добавь в grub параметр rootdelay=10 мне помогло, но возможно это другой случай

Я так и не понял, в чем причина проблемы, но прошло уже с пол года, а она все равно периодически возникает

Там сложная проблема. Я до сих пор подписан на соответствующий багрепорт в арче — решения нет и не особо видно, причём нет даже однозначного (гарантированно работающего) костыля.

Т.е. это арч-специфичная проблема? В других дистрибутивах я такого не наблюдал, хотя из других, длительное время сидел только на убунте.

Скажем так: это проблема во взаимодействии udev, pvscan и lvmetad (причём я даже не могу сказать, как её нужно архитектурно правильно фиксить), которая, в частности, проявляется в арче ввиду того, как устроены его стартовые скрипты и udev-правила.

Почему не проявляется где-то ещё — понятия не имею.

С другой стороны, если я правильно понимаю происходящее, есть пара идей. К сожалению, у меня нет конфигурации, на которой это можно протестить (и нет времени сделать такую конфигурацию из рабочей машины).

Что за идеи? А вообще странно, странно, что проблему не могут пофиксить, т.к. невозможность штатно загрузить ос, это очень плохо, особенно если это проявится на серверах.

• впилить systemd в initramfs, заставить pvscan запускаться как юнит systemd, добавить нужное количество зависимостей для того, чтобы systemd ждал завершения всех pvscan перед началом убивания udev/lvmetad/всего остального
• впилить в lvmetad обработку SIGTERM и перед собственной смертью подождать завершения всех pvscan (сработает только в том случае, если pvscan сначала открывает соединение с lvmetad и только после этого начинает сканить диски)
• как вариант, заставить pvscan «сначала открывать соединение» и см. п. 2 (но это переизобретение systemd, на самом деле)

Думаю, на серверах такой конфиг просто не используют... Ну или, как вариант, в каждом серверном дистре свой набор инициализационных костылей, которые уже как-то работают и которые никто не трогает.

Скинь, пожалуйста, ссылку на багрепорт

вот этот? https://bugs.archlinux.org/task/41833

Да, спасибо, ссылка была уже выше