после обновления всей системы (которого я обычно стараюсь избегать), я думал, что не могу загрузиться, но на этот раз решил подождать еще.
поэтому ровно через 6 мин. 05 сек. (Каждый раз - именно эта задержка) он, наконец, завершает загрузку: (
как раз перед обновлением это было очень быстро, поэтому я исключаю любые проблемы с оборудованием.
[вы можете перейти, чтобы прочитать последнее обновление на текущий момент 2019-12-25]
другие вопросы, которые я обнаружил, не относятся к LVM, но этот случай, похоже, связан с последним сообщением об ошибке о сканировании LVM :
да, изначально есть кое-что о 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-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
был проигнорирован.