Bug#892193: lvm2: Debian 9 fails to boot from the LV on a multipath device

[Marco d'Itri]

On Mar 06, Piotr Pańczyk  wrote:

> Interestingly, the situation described above happens in about 80-90% of
> boots, sometimes everything works well. Some kind of race condition?
Probably yes: everything should happen as a result of udev events, 
trying to do it syncronously is very very hard.

> I have found that the problem is caused by the option
> --disable-udev-systemd-background-jobs in package configuration. As a
> consequence, in /lib/udev/rules.d/69-lvm-metad.rules, pvscan is run
> directly. With package compiled with udev systemd background jobs
> enabled, it is run by /bin/systemd-run and everything works fine. In
> current versions of Jessie and even Sid, this option is enabled, so why
> was it disabled in Stretch?
No clue, since I am not the lvm2 maintainer, but I can confirm that 
multipath + LVM is totally broken in stretch.
Unless somebody has a better idea I will upload to stretch-backports 
a backport of the current LVM package.

-- 
ciao,
Marco


signature.asc
Description: PGP signature

Bug#892193: lvm2: Debian 9 fails to boot from the LV on a multipath device

[Piotr Pańczyk]

Package: lvm2
Version: 2.02.168-2
Severity: important

Dear Maintainer,
there is a problem with booting Debian Stretch from LV on a multipath
device (I have multipath-tools-boot installed). At initramfs, logical
volumes are activated by udev as soon as the disks appear, so lvm
complains that there are duplicate VGs found. Later on, multipath says
that it cannot use one of the devices, because it is in use - there
already are active LVs on top of it. Further situation depends on
configuration. In legacy BIOS mode and everything on LVs, the system
continues to boot using a single path - device mapper has already mapped
LVs to /dev/mapper/* and /dev/VG/*. In UEFI mode (EFI partition directly
on a multipath device, /dev/mapper/WWID-partN in fstab), however, it
exits to the initramfs shell, because the partitions are not mapped in
/dev/mapper/. In that case the system does not boot, so this is a
serious problem.

Interestingly, the situation described above happens in about 80-90% of
boots, sometimes everything works well. Some kind of race condition?

I have found that the problem is caused by the option
--disable-udev-systemd-background-jobs in package configuration. As a
consequence, in /lib/udev/rules.d/69-lvm-metad.rules, pvscan is run
directly. With package compiled with udev systemd background jobs
enabled, it is run by /bin/systemd-run and everything works fine. In
current versions of Jessie and even Sid, this option is enabled, so why
was it disabled in Stretch?

I believe that #870692 may also be related to this.

Greetings,
Piotr


-- System Information:
Debian Release: 9.3
  APT prefers stable
  APT policy: (500, 'stable')
Architecture: amd64 (x86_64)

Kernel: Linux 4.9.0-6-amd64 (SMP w/40 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages lvm2 depends on:
ii  dmeventd  2:1.02.137-2
ii  dmsetup   2:1.02.137-2
ii  init-system-helpers   1.48
ii  libblkid1 2.29.2-1
ii  libc6 2.24-11+deb9u1
ii  libdevmapper-event1.02.1  2:1.02.137-2
ii  libdevmapper1.02.12:1.02.137-2
ii  liblvm2app2.2 2.02.168-2
ii  libreadline5  5.2+dfsg-3+b1
ii  libudev1  232-25+deb9u1
ii  lsb-base  9.20161125

lvm2 recommends no packages.

Versions of packages lvm2 suggests:
pn  thin-provisioning-tools  

-- no debconf information