There is only a reject, there are no included devices. Once you add a
filter it overrides the default filter including all I believe.
The fixes may have been fixing filtering as once you specify a filter
then there is no implied include (anymore). You should probably look
at the list of fixes
Hi Roger,
Thanks for the information shared.
Filter which we used in our conf file was,
# Accept every block device:
filter = [ "r|^/dev/drbd.*|" ]
Thanks.
On Tue, 15 Sep 2020 at 16:36, Roger Heflin wrote:
> #1:
> Device /dev/sda3 excluded by a filter.)
> Failed to execute
Hi Roger,
Missed to add my comment in the earlier mail.
>From the filter it should not exclude /dev/sda*. But not sure why it is
being excluded while executing pvcreate command.
Thanks.
On Tue, 15 Sep 2020 at 18:28, KrishnaMurali Chennuboina <
krishchennu...@gmail.com> wrote:
> Hi Roger,
>
>
Dne 15. 09. 20 v 13:05 Roger Heflin napsal(a):
#1:
Device /dev/sda3 excluded by a filter.)
Failed to execute command: pvcreate -ffy /dev/sda3
ec=0
excluded by filter is likely the issue, I think there was a bug were
it allowed that pvcreate to work when it should have blocked it
because of the
#1:
Device /dev/sda3 excluded by a filter.)
Failed to execute command: pvcreate -ffy /dev/sda3
ec=0
excluded by filter is likely the issue, I think there was a bug were
it allowed that pvcreate to work when it should have blocked it
because of the filter. It should not allow a pvcreate against
Hi Roger,
I have tried this with the older LVM package(.176) and this issue was not
seen. Issue was seen with .180 version every time.
# executing command: vgchange -ay
(status, output): (0, WARNING: Failed to connect to lvmetad. Falling back
to device scanning.)
WARNING: Failed to connect to
In general I would suggest fully disabling lvmetad from the config
files and from being started up.
Issues around it not answering (like above) and answering but somehow
having stale/wrong info have burned me too many times to trust it. It
may be a lvmetad bug, or be udevd weirdness.
The only
Hi Team,
While trying to analyze one the issue, we felt that upgrading the current
LVM2 package in our repository will be the best approach.
As part of that, we have updated the respective package from 2.02.176 to
2.02.180. We have verified the same and booted x86_64 hardware without any
issues.
