Bug#791869: lvm2: updating src:lvm2 from 2.02.111-2.2 to 2.02.122-1 breaks booting, mounting LVs other than / fails

Michael Biebl biebl at debian.org
Fri Jul 31 08:54:00 UTC 2015

On Fri, 31 Jul 2015 08:08:38 +0200 Stefan Lippers-Hollmann
<s.l-h at gmx.de> wrote:
> Hi
> On 2015-07-31, Stefan Lippers-Hollmann wrote:
> > On 2015-07-31, Stefan Lippers-Hollmann wrote:
> > > On 2015-07-25, Bastian Blank wrote:
> [...]
> > The attached bootlog (serial console && udev.log-priority=7) has
> > unfortunately not been recorded with an official Debian kernel, but
> > I've been able to reproduce it with 4.0.0-2-amd64 as well. Just that I
> > missed increasing the scrollback buffer in time and wasn't able to 
> > fetch a full bootlog then - and, regardless of the kernel in use, 
> > reproducing takes quite many reboots (too many for now) with full 
> > logging enabled.
> It took many reboots (>50), but here is a reproduction with the
> official Debian kernel - gzipped logs attached.

Stefan, you are running amd64, right?

Bastian built the lvm2 on amd64 on a non-systemd system, it seems. This
results in /lib/udev/rules.d/69-lvm-metad.rules lookin like this:
RUN+="/sbin/lvm pvscan --background --cache --activate ay --major $major
--minor $minor", ENV{LVM_SCANNED}="1"

If you build lvm2 on a systemd system, those rules look like
ACTION!="remove", ENV{LVM_PV_GONE}=="1", RUN+="/bin/systemd-run
/sbin/lvm pvscan --cache $major:$minor", GOTO="lvm_end"
ENV{ID_MODEL}="LVM PV $env{ID_FS_UUID_ENC} on /dev/$name"

If I replace /lib/udev/rules.d/69-lvm-metad.rules with the attached
file, my problems with LVM on top of RAID1 are gone. Can you copy the
attached file to /etc/udev/rules.d/ and test if that fixes your problem?

We likely need a runtime check, not a compile time check, in
69-lvm-metad.rules to decide which rules to run.

Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?
-------------- next part --------------
# Copyright (C) 2012 Red Hat, Inc. All rights reserved.
# This file is part of LVM2.

# Udev rules for LVM.
# Scan all block devices having a PV label for LVM metadata.
# Store this information in LVMetaD (the LVM metadata daemon) and maintain LVM
# metadata state for improved performance by avoiding further scans while
# running subsequent LVM commands or while using lvm2app library.
# Also, notify LVMetaD about any relevant block device removal.
# This rule is essential for having the information in LVMetaD up-to-date.
# It also requires blkid to be called on block devices before so only devices
# used as LVM PVs are processed (ID_FS_TYPE="LVM2_member" or "LVM1_member").

SUBSYSTEM!="block", GOTO="lvm_end"


# If the PV label got lost, inform lvmetad immediately.
# Detect the lost PV label by comparing previous ID_FS_TYPE value with current one.
ENV{ID_FS_TYPE}=="LVM2_member|LVM1_member", ENV{.ID_FS_TYPE_NEW}!="LVM2_member|LVM1_member", ENV{LVM_PV_GONE}="1"
ENV{LVM_PV_GONE}=="1", GOTO="lvm_scan"

# Only process devices already marked as a PV - this requires blkid to be called before.
ENV{ID_FS_TYPE}!="LVM2_member|LVM1_member", GOTO="lvm_end"

# Inform lvmetad about any PV that is gone.
ACTION=="remove", GOTO="lvm_scan"

# Create /dev/disk/by-id/lvm-pv-uuid-<PV_UUID> symlink for each PV
ENV{ID_FS_UUID_ENC}=="?*", SYMLINK+="disk/by-id/lvm-pv-uuid-$env{ID_FS_UUID_ENC}"

# If the PV is a special device listed below, scan only if the device is
# properly activated. These devices are not usable after an ADD event,
# but they require an extra setup and they are ready after a CHANGE event.
# Also support coldplugging with ADD event but only if the device is already
# properly activated.
# This logic should be eventually moved to rules where those particular
# devices are processed primarily (MD and loop).

# DM device:
KERNEL!="dm-[0-9]*", GOTO="next"

# MD device:
KERNEL!="md[0-9]*", GOTO="next"
ACTION=="add", ENV{LVM_MD_PV_ACTIVATED}=="1", GOTO="lvm_scan"
ACTION=="change", ENV{LVM_MD_PV_ACTIVATED}!="1", TEST=="md/array_state", ENV{LVM_MD_PV_ACTIVATED}="1", GOTO="lvm_scan"
ACTION=="add", KERNEL=="md[0-9]*p[0-9]*", GOTO="lvm_scan"

# Loop device:
KERNEL!="loop[0-9]*", GOTO="next"
ACTION=="add", ENV{LVM_LOOP_PV_ACTIVATED}=="1", GOTO="lvm_scan"
ACTION=="change", ENV{LVM_LOOP_PV_ACTIVATED}!="1", TEST=="loop/backing_file", ENV{LVM_LOOP_PV_ACTIVATED}="1", GOTO="lvm_scan"

# If the PV is not a special device listed above, scan only after device addition (ADD event)
ACTION!="add", GOTO="lvm_end"


# The table below summarises the situations in which we reach the LABEL="lvm_scan".
# Marked by X, X* means only if the special dev is properly set up.
# The artificial ADD is supported for coldplugging. We avoid running the pvscan
# on artificial CHANGE so there's no unexpected autoactivation when WATCH rule fires.
# N.B. MD and loop never actually  reaches lvm_scan on REMOVE as the PV label is gone
# within a CHANGE event (these are caught by the "LVM_PV_GONE" rule at the beginning).
#        | real ADD | real CHANGE | artificial ADD | artificial CHANGE | REMOVE
# =============================================================================
#  DM    |          |      X      |       X*       |                   |   X
#  MD    |          |      X      |       X*       |                   |
#  loop  |          |      X      |       X*       |                   |
#  other |    X     |             |       X        |                   |   X
ACTION!="remove", ENV{LVM_PV_GONE}=="1", RUN+="/bin/systemd-run /sbin/lvm pvscan --cache $major:$minor", GOTO="lvm_end"
ENV{ID_MODEL}="LVM PV $env{ID_FS_UUID_ENC} on /dev/$name"

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <http://lists.alioth.debian.org/pipermail/pkg-lvm-maintainers/attachments/20150731/ab7461ce/attachment.sig>

More information about the pkg-lvm-maintainers mailing list