LINUX.ORG.RU

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

 ,


2

4

Иногда, при загрузке arch система загружается в emergency mode, при этом в логе сообщается

Oct 23 22:32:55 sinx systemd[1]: Job dev-disk-by\x2duuid-a682b657\x2d95fa\x2d4a36\x2db777\x2d45c1b66b0aec.device/start timed out.
Oct 23 22:32:55 sinx systemd[1]: Timed out waiting for device dev-disk-by\x2duuid-a682b657\x2d95fa\x2d4a36\x2db777\x2d45c1b66b0aec.device.


NAME              FSTYPE      LABEL UUID                                   MOUNTPOINT
sda                                                                        
├─sda1            vfat              178D-5295                              /boot
└─sda2            LVM2_member       vTuU2v-iYQk-gO6J-zrgy-FBYe-kMIA-XyiOBf 
  └─sinx_ssd-root ext4        Root  931bf7aa-0ae2-4232-a913-409a03431006   /
sdb               LVM2_member       Ezi6iA-3YLL-U2Cy-7eV4-OZ62-iYVU-k69lb1 
├─sinx_hdd-home   ext4        Home  17caacb4-456b-4e89-8561-47b073d6f487   /home
└─sinx_hdd-data   ext4        Data  a682b657-95fa-4a36-b777-45c1b66b0aec   /media/data
sdc               LVM2_member       bQzfkt-hjAh-B3RI-xZq6-Kjql-cyhv-GPb8Es 
└─sinx_hdd-data   ext4        Data  a682b657-95fa-4a36-b777-45c1b66b0aec   /media/data
sdd               LVM2_member       rj6Ip5-nea9-f5FA-iQPS-d5XO-TJpi-K9ntt2 
└─sinx_hdd-data   ext4        Data  a682b657-95fa-4a36-b777-45c1b66b0aec   /media/data
sr0                                                                        
/dev/sda1: UUID="178D-5295" TYPE="vfat" PARTLABEL="EFI System" PARTUUID="06d173c5-8adf-480d-b82c-df545c2754a6" 
/dev/sda2: UUID="vTuU2v-iYQk-gO6J-zrgy-FBYe-kMIA-XyiOBf" TYPE="LVM2_member" PARTLABEL="Linux LVM" PARTUUID="5b392bcc-2001-4760-b01f-96c3cc97e8e5" 
/dev/sdb: UUID="Ezi6iA-3YLL-U2Cy-7eV4-OZ62-iYVU-k69lb1" TYPE="LVM2_member" 
/dev/sdc: UUID="bQzfkt-hjAh-B3RI-xZq6-Kjql-cyhv-GPb8Es" TYPE="LVM2_member" 
/dev/mapper/sinx_ssd-root: LABEL="Root" UUID="931bf7aa-0ae2-4232-a913-409a03431006" TYPE="ext4" 
/dev/mapper/sinx_hdd-home: LABEL="Home" UUID="17caacb4-456b-4e89-8561-47b073d6f487" TYPE="ext4" 
/dev/sdd: UUID="rj6Ip5-nea9-f5FA-iQPS-d5XO-TJpi-K9ntt2" TYPE="LVM2_member" 
/dev/mapper/sinx_hdd-data: LABEL="Data" UUID="a682b657-95fa-4a36-b777-45c1b66b0aec" TYPE="ext4" 

мой fstab

# 
# /etc/fstab: static file system information
#
# <file system> <dir>   <type>  <options>       <dump>  <pass>
# /dev/mapper/sinx_ssd-root
UUID=931bf7aa-0ae2-4232-a913-409a03431006      /         ext4            rw,relatime,data=ordered,discard        0 1
# /dev/sda1
UUID=178D-5295 /boot vfat rw,relatime,fmask=0022,dmask=0022,codepage=437,iocharset=iso8859-1,shortname=mixed,errors=remount-ro 0 2                                                                                                                                                                                                                                                                                                        
# /dev/mapper/sinx_hdd-home                                                                                                                                                                                                
UUID=17caacb4-456b-4e89-8561-47b073d6f487       /home           ext4            rw,relatime,data=ordered        0 2                                                                                                                                                                                                                                                                                                                                                                               
# /dev/mapper/sinx_hdd-data                                                                                                                                                                                                                                                                                     
UUID=a682b657-95fa-4a36-b777-45c1b66b0aec       /media/data     ext4            rw,relatime,data=ordered        0 2

В большинстве случаев система грузится нормально, s.m.a.r.t дисков в порядке, в ubuntu такой проблемы не наблюдалось, что можете посоветовать? После загрузки никаких проблем нет

Полный лог загрузки http://paste.org.ru/?8fznzl



Последнее исправление: tm4ig (всего исправлений: 3)

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

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

intelfx ★★★★★
()
Ответ на: комментарий от intelfx

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

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 ~]$ 



tm4ig
() автор топика
Ответ на: комментарий от tm4ig

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

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

intelfx ★★★★★
()
Ответ на: комментарий от tm4ig

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

systemctl disable lvm2-lvmetad
intelfx ★★★★★
()
Последнее исправление: intelfx (всего исправлений: 1)
Ответ на: комментарий от intelfx

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

Medar ★★★★★
()

tm4ig Medar

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

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

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

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

intelfx ★★★★★
()
Последнее исправление: intelfx (всего исправлений: 1)
Ответ на: комментарий от intelfx

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

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.]

tm4ig
() автор топика
Ответ на: комментарий от intelfx

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

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

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

Medar ★★★★★
()
Последнее исправление: Medar (всего исправлений: 1)
Ответ на: комментарий от intelfx

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

Medar ★★★★★
()
Ответ на: комментарий от tm4ig

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

intelfx ★★★★★
()
Ответ на: комментарий от tm4ig

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

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

intelfx ★★★★★
()
Ответ на: комментарий от intelfx

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

intelfx ★★★★★
()
Ответ на: комментарий от intelfx

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

intelfx ★★★★★
()
Ответ на: комментарий от tm4ig

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

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

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

intelfx ★★★★★
()
Последнее исправление: intelfx (всего исправлений: 2)
Ответ на: комментарий от intelfx

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

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

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

Medar ★★★★★
()
Последнее исправление: Medar (всего исправлений: 1)
Ответ на: комментарий от intelfx

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

Medar ★★★★★
()
Ответ на: комментарий от Medar

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

intelfx ★★★★★
()

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

sdio ★★★★★
()
31 марта 2015 г.
Ответ на: комментарий от intelfx

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

tm4ig
() автор топика
Ответ на: комментарий от tm4ig

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

intelfx ★★★★★
()
Ответ на: комментарий от intelfx

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

tm4ig
() автор топика
Ответ на: комментарий от tm4ig

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

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

intelfx ★★★★★
()
Последнее исправление: intelfx (всего исправлений: 1)
Ответ на: комментарий от tm4ig

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

intelfx ★★★★★
()
Ответ на: комментарий от intelfx

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

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

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

intelfx ★★★★★
()
Последнее исправление: intelfx (всего исправлений: 2)
Ответ на: комментарий от user_id_68054

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

tm4ig
() автор топика
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.