Using: - LVM2 2.02.183 with udev enabled - Linux Kernel 4.20.x - devtmpfs, proc, and sysfs mounted - Underdog init script (which I wrote, can be found at underdog.sourceforge.net) (which I've been using for a long time previously) Invoking "lvm vgchange -ay" with or without any combination of --sysinit and --noudevsync in early user context, e.g. with no UDEV running but devtmpfs, causes a ten second delay for every block device in the system. Sample message below is printed for each block device WARNING: Device /dev/(whatever) not initialized in udev database even after waiting 10000000 microseconds With a dual boot system of two drives with several partitions each and several scans automatically searching for various details this can add several minutes to what used to be nominal boot times. This didn't happen until quite recently and is localized to lvm2 The --sysinit or --noudevsync option _should_ stop lvm from interracting with the udev system, or there should be a --noudev option to suppress this new and unwanted query/wait cycle in lvm. I must stress this is new behavior, and since my root file system is in an LVM logical volume which is, in turn, inside a cryptsetup/LUKS partition, I need LVM long before udev is a reasonable option. Reproducible: Always Steps to Reproduce: 1. build an initramfs with an LVM2 binary that includes udev support but no udev binaries 2. boot a 4.20 kernel into that initramfs 3. mount /sys and /proc 4. run lvm vgchange -ay regardless of any other options, inn the /init script or in a shell prompt Expected Results: lvm vgchange -ay should take mere moments per partition to scan the disk. This behavior was well established in the /init script I use since at least linux 4.5 and up through 4.19.* CAVEAT: lvm needs /sys and /proc to function correctly, other more fundimental errors happen without these pseudo filesystems mounted, but the delay goes away without /sys.
I found the solution. Works for me, lvm is now fast again in initramfs. See: https://forums.gentoo.org/viewtopic-t-1090704-start-0.html TL;DR: devices { multipath_component_detection = 0 md_component_detection = 0 }
*** This bug has been marked as a duplicate of bug 673796 ***
