18.04, grub takes about 6 minutes to boot, problem: `systemd-udevd 'SomeDevice' is taking a long time`

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:

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