18.04, grub загружается около 6 минут, проблема: `systemd-udevd 'SomeDevice' занимает много времени`

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

поэтому ровно через 6 мин. 05 сек. (Каждый раз - именно эта задержка) он, наконец, завершает загрузку: (

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

[вы можете перейти, чтобы прочитать последнее обновление на текущий момент 2019-12-25]

другие вопросы, которые я обнаружил, не относятся к LVM, но этот случай, похоже, связан с последним сообщением об ошибке о сканировании LVM :

enter image description here enter image description here enter image description here

да, изначально есть кое-что о irq и ACPI, я пытался добавить это, но не помогло acpi = strict , так что я предполагаю, что это проблема LVM.

Я обнаружил в журнале кое-что, что может помочь (без «дубликатов»):

#happens 5 times
syslog.1:Dec 18 18:52:29 MyHostName lvm[803]:   WARNING: lvmetad is being updated, retrying (setup) for 10 more seconds.

syslog.1:Dec 18 18:52:29 MyHostName systemd[1]: Created slice system-lvm2\x2dpvscan.slice.

# happens 20 times, each for a different device
syslog.1:Dec 18 18:52:29 MyHostName lvm[814]:   WARNING: lvmetad is being updated, retrying (setup) for 10 more seconds.
syslog.1:Dec 18 18:52:29 MyHostName systemd[1]: Starting LVM2 PV scan on device 8:31...

syslog.1:Dec 18 18:52:29 MyHostName systemd[1]: Started Monitoring of LVM2 mirrors, snapshots etc. using dmeventd or progress polling.

syslog.1:Dec 18 18:52:29 MyHostName kernel: [    2.460879] random: lvm: uninitialized urandom read (4 bytes read)

#logs like this happened for each device also
syslog.1:Dec 18 18:52:29 MyHostName lvm[625]:   4 logical volume(s) in volume group "MyLvmGroupName" monitored
syslog.1:Dec 18 18:52:29 MyHostName lvm[911]:   4 logical volume(s) in volume group "MyLvmGroupName" now active

Вышеупомянутое, несмотря на то, что сказано «еще 10 секунд», похоже, все происходит в ту же секунду в »18 декабря, 18:52 : 29 "что для меня не имеет особого смысла, это было много тем? в любом случае ...

obs .: grub v 2.02-2ubuntu8.14

Я проверяю время загрузки с помощью sudo systemd-analysis time

После этого последнего обновления, когда я включаю компьютер, он обычно "зависает" при первой загрузке (сразу после выбора загрузки (нормальная или расширенная загрузка и т. д.)), но я могу ctrl + alt + del. После этого переходит к этой проблеме с замедленной загрузкой ...


19 / дек / 2019 Сегодня увидел кое-что интересное + - вот такое: / dev / mapper / MyLVMGroupName: clean Я не смог сделать фото, было слишком быстро, и я не могу найти его нигде в / var / log (ubuntu не имеет журнала загрузки ???) ну ... похоже мне, что fsck запускался (запускался) каждый раз, и для его завершения требуется 6 минут? Обс .: вчера я сделал нормальное завершение работы, так что, думаю, он уже должен быть чистым, нет необходимости в fsck ...
Еще об этом: красный светодиод на рабочем столе (который показывает нам, происходит ли какой-либо ввод-вывод жесткого диска) не мигает ни разу в течение этой 6-минутной задержки перед отображением сообщения fsck clean, поэтому ... он не тратит время на чтение / запись. Так что же происходит? может быть таймаут какой-то, но почему об этом ничего не сказано?

нет ничего в systemd-analysis виноват , который также потратил бы больше 6 секунд.


2019-12-25 : к команде linux grub я добавил debug --verbose и получил это!
после 60 секунд ожидания:
systemd-udevd 'SomeDevicePartition' занимает много времени
после более 120 секунд:
systemd-udevd 'SomeDevicePartition' убит
они происходят в + -: 60 секунд, 180 секунд, 240 секунд, 365s
итого 6минут !!!
Интересно, можно ли уменьшить тайм-аут udevd до 10 секунд и не повторять попытку? (используя некоторую конфигурацию в записи grub)


Мое последнее предположение - все это просто неприятная ошибка: (

итак, как я могу это исправить?

Могу я намекнуть grub, чтобы быстро обнаружить LVM-файлы?

ссылка: https://unix.stackexchange.com/questions/559929/very-slow-boot-6m-where-udevadm-stores-its-config/559979#559979

1
задан 21 December 2019 в 02:42

1 ответ

использовал обходной путь для решения этой проблемы:
https: // unix .stackexchange.com / questions / 559929 / very-slow-boot-6m-how-to-force-change-systemd-udevd-timeout-to-5s / 559979 # comment1041816_559979

linux /vmlinuz-4.15.0-72-generic \
 udev.event-timeout=5 \
 root=/dev/mapper/MyLvmGroupName ro nosplash \
 $vt_handoff debug --verbose

Поскольку я не проводил много тестов, чтобы будьте на 100% уверены:
Я думаю, что и debug , и - verbose сообщают мне, что происходит.
Я думаю, что udev.event-timeout = 5 должно быть до root = param.
Я уверен, что rd.udev.event-timeout = 5 был проигнорирован.

0
ответ дан 5 January 2020 в 17:56

Другие вопросы по тегам:

Похожие вопросы: