#2647 Issue `closed`: LVM PV recreation fails: excluded by a filter.¶

Labels: support / question, fixed / solved / done

abbbi opened issue at 2021-07-05 14:31:¶

ReaR version ("/usr/sbin/rear -V"): 2.6
OS version ("cat /etc/os-release" or "lsb_release -a" or "cat /etc/rear/os.conf"):

SLES15

Hardware (PC or PowerNV BareMetal or ARM) or virtual machine (KVM guest or PoverVM LPAR):

Power LPAR

System architecture (x86 compatible or PPC64/PPC64LE or what exact ARM device):

PPC64

hi,

today i came across following situation: Rear Recovery on PPC64 with multipath SAN setup.
Disk layout recreation failed with following error message:

 +++ lvm pvcreate -ff --yes -v --uuid R7iUAc-3rHe-sLi8-4eb4-PVHM-gwOj-D76cKT --norestorefile /dev/mapper/360050768108183224800000000000246-part1
     Wiping internal VG cache
     Wiping cache of LVM-capable devices
   Device /dev/mapper/360050768108183224800000000000246-part1 excluded by a filter.

Investigation showed that the partition included some "data" to an extend where it would include parts of an UEFI bootloader,
old data ..

So i attempted to wipe any data on it via:

wipefs -a /dev/mapper/360050768108183224800000000000246-part1

which didnt help, carried on and cleared the partitions disk data using dd, and everything worked smoothly:

 4 RESCUE sapdb:~ # dd if=/dev/zero of=/dev/mapper/36005076810818322480000
  5 0000000246-part1 bs=1M count=10
  6 10+0 records in
  7 10+0 records out
  8 10485760 bytes (10 MB, 10 MiB) copied, 0.0393749 s, 266 MB/s
  9 RESCUE sapdb:~ # lvm pvcreate -ff --yes -v --uuid "R7iUAc-3rHe-sLi8-4eb
 10 4-PVHM-gwOj-D76cKT" --norestorefile /dev/mapper/3600507681081832248000000000002
 11 46-part1
 12     Wiping internal VG cache
 13     Wiping cache of LVM-capable devices
 14     Wiping signatures on new PV /dev/mapper/360050768108183224800000000000246-part1.
 15     Set up physical volume for "/dev/mapper/360050768108183224800000000000246-part1" with 41940959 available sectors.
 16     Zeroing start of device /dev/mapper/360050768108183224800000000000246-part1.
 17     Writing physical volume data to disk "/dev/mapper/360050768108183224800000000000246-part1".
 18   Physical volume "/dev/mapper/360050768108183224800000000000246-part1" successfully created.

As far as i can see, REAR does only call wipefs or dd on partitions before creating the filesystems, maybe it makes sense to do so before attempting to create logical volumes, too?

abbbi commented at 2021-07-05 19:18:¶

I dont have access to the original disks data anymore, it is hard to tell what data on the disk may have caused the situation.
Usually lvm create -ff should wipe all things like an existing partition table, as reproduced via:

sles15ppclefix:~ # truncate -s 30M testfile
sles15ppclefix:~ # losetup /dev/loop0 testfile
sles15ppclefix:~ # parted /dev/loop0 mklabel gpt
lvm pvcreate -ff --yes -v --uuid R7iUAc-3rHe-sLi8-4eb4-PVHM-gwOj-D76cKT --norestorefile /dev/loop0 
    Scanning all devices to update lvmetad.
    No PV label found on /dev/loop0.
    No PV label found on /dev/build/build.
    No PV label found on /dev/sda1.
    No PV label found on /dev/sda2.
    No PV label found on /dev/sda3.
    No PV label found on /dev/sda4.
    Wiping internal VG cache
    Wiping cache of LVM-capable devices
    Wiping signatures on new PV /dev/loop0.
    Found existing signature on /dev/loop0 at offset 512: LABEL="(null)" UUID="(null)" TYPE="gpt" USAGE="partition table"
  Wiping gpt signature on /dev/loop0.
    Found existing signature on /dev/loop0 at offset 31456768: LABEL="(null)" UUID="(null)" TYPE="gpt" USAGE="partition table"
  Wiping gpt signature on /dev/loop0.
    Found existing signature on /dev/loop0 at offset 510: LABEL="(null)" UUID="(null)" TYPE="PMBR" USAGE="partition table"
  Wiping PMBR signature on /dev/loop0.
    Set up physical volume for "/dev/loop0" with 61440 available sectors.
    Zeroing start of device /dev/loop0.
    Writing physical volume data to disk "/dev/loop0".
  Physical volume "/dev/loop0" successfully created.

abbbi commented at 2021-07-06 09:22:¶

Nevermind, i just found out about #799

jsmeix commented at 2021-07-06 12:15:¶

Yes, https://github.com/rear/rear/issues/799 is the matching issue.

See also the comments in https://github.com/rear/rear/pull/2514
and the comments in the code for some background information
about the current state of the DISKS_TO_BE_WIPED functionality.

In particular regarding removing LVs and VGs see
https://github.com/rear/rear/pull/2514#issuecomment-729009274

jsmeix commented at 2021-07-07 06:27:¶

In general see also my reply
https://github.com/rear/rear/issues/2638#issuecomment-868223949

jsmeix commented at 2021-07-13 13:53:¶

@abbbi FYI:
I am neither an LVM nor a multipath expert but I think the message
Device /dev/mapper/360050768108183224800000000000246-part1 excluded by a filter.
could be only an information message but no actual error message.
I think such a message could be caused by a filter in /etc/lvm/lvm.conf
e.g. something similar as https://github.com/rear/rear/issues/2651

abbbi commented at 2021-07-13 14:37:¶

@abbbi FYI:
I am neither an LVM nor a multipath expert but I think the message
Device /dev/mapper/360050768108183224800000000000246-part1 excluded by a filter.
could be only an information message but no actual error message.
I think such a message could be caused by a filter in /etc/lvm/lvm.conf
e.g. something similar as #2651

no, it wasnt informational, The "excluded by filter" was gone after nulling the device!
in /etc/lvm/lvm.conf no settings regards filters were set.

jsmeix commented at 2021-07-13 15:07:¶

Only an offhanded blind guess:
Perhaps there was whatever kind of LVM metadata on that device
and the (as far as I know via udev triggered) automated LVM detection
detects something and reports the "excluded by a filter" message.
In contrast after nulling that device the automated LVM detection
can no longer detect anything LVM related so there is no message.
So the actual root cause could have been LVM metadata remainders
but not whether or not some LVM things are "excluded by a filter".

On my SLES15-SP3 test VM /etc/lvm/lvm.conf contains

# This configuration option has an automatic default value.
# global_filter = [ "a|.*/|" ]

I don't know what that automatic default value actually is
but perhaps such an automatic default value might result
some automatic "excluded by a filter" message in some cases?

[Export of Github issue for rear/rear.]

#2647 Issue closed: LVM PV recreation fails: excluded by a filter.¶