4

after a whole system update (that I try to avoid usually), I thought I was unable to boot, but this time I decided to wait more.

so after exactly 6m05s (everytime is that precise delay) it finally completes booting :(

just before the update it was very fast, so I exclude any hardware problem.

[you may jump to read the last update currently 2019-12-25]

other questions I found arent related to LVM, but this case seems to be as the last failure message is about scanning for LVM:

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

yes, initially there is some stuff about irq and ACPI, I tried adding this but didnt help acpi=strict, so my guess is that it is a LVM problem.

I found some stuff on the log that may help (omitting "dups"):

#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

The above, despite saying "for 10 more seconds" it all seems to happen on the same second at "Dec 18 18:52:29" what doesnt make much sense to me, it was many threads? anyway...

obs.: grub v 2.02-2ubuntu8.14

I check the boot time with sudo systemd-analyze time

After this latest update, when I turn on the computer, it usually "freezes" on the 1st boot (just after the boot choice is made (normal or advanced boot etc)), but I can ctrl+alt+del. After this it goes to this slowed boot problem...


19/Dec/2019 Today I saw something interesting +- like this: /dev/mapper/MyLVMGroupName: clean I couldnt take a photo, was too fast and I cant find it anywhere at /var/log (ubuntu has no boot log???) well... it appeared to me that a fsck was being run (has been being run) everytime and it is taking 6min to complete? Obs.: yesterday I did a normal shutdown, so I think it should be clean already, no need for fsck...
Another thing about this: the desktop red led (that shows us if is happening some kind of hard drive I/O) doesnt blink a single time during that 6m delay, before showing fsck clean message, so... it is not spending time reading/writing. So what is happening? could be some kind of timeout, but why it says nothing about it?

there is nothing at systemd-analyze blame that spent more than 6 seconds also.


2019-12-25: to the linux grub command, I added debug --verbose and got this!
after 60s waiting:
systemd-udevd 'SomeDevicePartition' is taking a long time
after more 120s:
systemd-udevd 'SomeDevicePartition' killed
they happen at +- : 60s, 180s, 240s, 365s
so a total of 6minutes!!!
I wonder if udevd killing timeout could be lowered to may be 10s and do not retry? (using some config in the grub entry)


My last guess is that all this is just some annoying bug :(

so, how I can fix this?

Can I hint grub to fastly detect LVM stuff?

linked: https://unix.stackexchange.com/questions/559929/very-slow-boot-6m-where-udevadm-stores-its-config/559979#559979

3
  • What happens when you boot into a previous kernel? Dec 18, 2019 at 3:11
  • I tried with 4 previous kernels on advanced boot options and had the same problem, I think the problem is not a kernel specific thing then? Dec 18, 2019 at 21:57
  • I am wondering if I could use udevadm --timeout=10 (the default says 120s but what I got is 60s) but the problem is that it is about events in general, not specifically to the hard drive detection... Dec 30, 2019 at 19:29

1 Answer 1

0

used a workaround to solve this problem:
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

As I didnt do a lot of tests to be 100% sure:
I think both debug and --verbose let me know what was happening.
I think udev.event-timeout=5 has to be before root= param.
I am sure rd.udev.event-timeout=5 was ignored.

1
  • after setting that entry to default, I found out also that the first time it boots (if I dont ctrl+alt+del) it will boot normally but wont output anything until login screen, so it will look like frozen but isnt! Jun 28, 2020 at 1:18

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .