systemd-udevd delays boot for 4+ minutes when an LVM PV is inside an LV

[Knickers Brown]

$ lsb_release -rd
Description: Ubuntu 17.10
Release: 17.10

$ apt-cache policy udev
udev:
  Installed: 234-2ubuntu12.1
  Candidate: 234-2ubuntu12.1
  Version table:
 *** 234-2ubuntu12.1 500
        500 http://us.archive.ubuntu.com/ubuntu artful-updates/main amd64 Packages
        500 http://security.ubuntu.com/ubuntu artful-security/main amd64 Packages
        100 /var/lib/dpkg/status
     234-2ubuntu12 500
        500 http://us.archive.ubuntu.com/ubuntu artful/main amd64 Packages

Expected:

Ubuntu 17.10 booting up as fast as Ubuntu 16.04

What happened instead:

During boot up the system will hang and then a timeout will allow it continue. This happens twice.

The first one occurs right after the network interfaces are renamed. Example:
[ 5.160480] e1000e 0000:02:00.0 enp2s0f0: renamed from eth0
[ 121.345255] raid6: sse2x1 gen() 4431 MB/s

The second one is from /scripts/init-bottom/lvm where 'udevadm --settle' is run.

# we cannot properly synthesize LVM LV change events with udevadm trigger, so
# if we use LVM, we need to let it finish; otherwise we get missing LV symlinks
# (LP #1185394)
if [ -x /sbin/vgchange ]; then
    udevadm settle --timeout=121 || true
fi

Reproducing:

Where $vg is some existing volume group name:

lvcreate -n pvtest -L 20m $vg
pvcreate /dev/$vg/pvtest
reboot

Use case:

KVM/Qemu libvirt VM guest's vda with PV in it stored in host LV.
This is somewhat involuntary as certain appliance VMs come configured this way.

ProblemType: Bug
DistroRelease: Ubuntu 17.10
Package: udev 234-2ubuntu12.1
ProcVersionSignature: Ubuntu 4.13.0-16.19-generic 4.13.4
Uname: Linux 4.13.0-16-generic x86_64
ApportVersion: 2.20.7-0ubuntu3.1
Architecture: amd64
CurrentDesktop: ubuntu:GNOME
Date: Fri Nov 10 18:29:33 2017
InstallationDate: Installed on 2017-11-05 (5 days ago)
InstallationMedia: Ubuntu-Server 17.10 "Artful Aardvark" - Release amd64 (20171017.1)
MachineType: System manufacturer System Product Name
ProcEnviron:
 TERM=xterm-256color
 PATH=(custom, no user)
 XDG_RUNTIME_DIR=<set>
 LANG=en_US.UTF-8
 SHELL=/bin/bash
ProcKernelCmdLine: BOOT_IMAGE=/vmlinuz-4.13.0-16-generic root=/dev/mapper/vg1-root ro verbose
SourcePackage: systemd
UpgradeStatus: No upgrade log present (probably fresh install)
dmi.bios.date: 07/05/2012
dmi.bios.vendor: American Megatrends Inc.
dmi.bios.version: 3029
dmi.board.asset.tag: To Be Filled By O.E.M.
dmi.board.name: M4A89GTD-PRO/USB3
dmi.board.vendor: ASUSTeK Computer INC.
dmi.board.version: Rev 1.xx
dmi.chassis.asset.tag: Asset-1234567890
dmi.chassis.type: 3
dmi.chassis.vendor: Chassis Manufacture
dmi.chassis.version: Chassis Version
dmi.modalias: dmi:bvnAmericanMegatrendsInc.:bvr3029:bd07/05/2012:svnSystemmanufacturer:pnSystemProductName:pvrSystemVersion:rvnASUSTeKComputerINC.:rnM4A89GTD-PRO/USB3:rvrRev1.xx:cvnChassisManufacture:ct3:cvrChassisVersion:
dmi.product.family: To Be Filled By O.E.M.
dmi.product.name: System Product Name
dmi.product.version: System Version
dmi.sys.vendor: System manufacturer

[Dimitri John Ledkov (xnox)]

> KVM/Qemu libvirt VM guest's vda with PV in it stored in host LV.

But the inner PV is only for the guest to use - no?
and thus it should not be mounted on the host, on boot.
Or do you somehow mount and access that PV on the host as well as the guest? That doesn't sound right.

Or are you saying when such things exist (and not required to mount/boot the host) the boot stalls nonetheless, and should not?

[Dimitri John Ledkov (xnox)]

I'll try to reproduce this locally to understand what is going on, sounds bad based on the description.

[Knickers Brown (metta-crawler)]

Re: But the inner PV is only for the guest to use - no?

The intent is that the inner PV is only for the guest to use. What has happened for years and years is that unless you mask using /etc/lvm/lvm.conf the host will vgscan the inner PV and vgchange it too. Until 17.10 (possibly 17.04, I skipped that one) this was mostly a cosmetic issue, now it adds four minutes to the boot time.

[Dan Streetman (ddstreet)]

please reopen if this is still an issue