[linux-lvm] What to do about new lvm messages

[linux-lvm] What to do about new lvm messages

[L A Walsh]

I am trying to create a new pv/vg/+lvs setup but am getting some weird messages

pvcreate  -M2 --pvmetadatacopies 2 /dev/sda1
  Failed to clear hint file.
  WARNING: PV /dev/sdd1 in VG Backup is using an old PV header, modify
the VG to update.
  Physical volume "/dev/sda1" successfully created.

So why am I getting a message about not clearing a hint file (running s root)

and how do I modify a VG that I don't want to make any modifications to?

From an online man page, I should have been able to use -ff to
recreate a pv over
the top of a preexisting one, but that didn't seem to work.  I got:
 pvcreate -ff -M2 --pvmetadatacopies 2 /dev/sda1
  Failed to clear hint file.
  WARNING: PV /dev/sdd1 in VG Backup is using an old PV header, modify
the VG to update.
  Cannot access VG Space with system ID Ishtar with unknown local system ID.
  Device /dev/sda1 excluded by a filter.
---
   So it seems that is broken.  I was able to work around that with:
dd if=/dev/zero of=/dev/sda1 bs=4096 count=1
1+0 records in
1+0 records out
4096 bytes (4.1 kB, 4.0 KiB) copied, 0.000175409 s, 23.4 MB/s

I also ran into a problem on how to tell vgcreate to use the whole pv.
That was complicated by trying to specify my hostname as a system id:
vgcreate -A y --alloc contiguous --systemid Ishtar --dataalignment
64KiB Space /dev/sda1
  Failed to clear hint file.
  WARNING: PV /dev/sdd1 in VG Backup is using an old PV header, modify
the VG to update.
  Volume group "Space" successfully created with system ID Ishtar

vgs
  WARNING: PV /dev/sdd1 in VG Backup is using an old PV header, modify
the VG to update.
  Cannot access VG Space with system ID Ishtar with unknown local system ID.
  VG     #PV #LV #SN Attr   VSize  VFree
Didn't know where the VG group ended up, which was why I needed to
redo creating the pv (vgremove didn't work):
vgremove Space
  Failed to clear hint file.
  Cannot access VG Space with system ID Ishtar with unknown local system ID.
  Cannot access VG Space with system ID Ishtar with unknown local system ID.

Version info:
pvcreate --version
  LVM version:     2.03.05(2) (2019-06-15)
  Library version: 1.03.01 (2019-06-15)
  Driver version:  4.42.0
  Configuration:   ./configure --host=x86_64-suse-linux-gnu
--build=x86_64-suse-linux-gnu --program-prefix=
--disable-dependency-tracking --prefix=/usr --exec-prefix=/usr
--bindir=/usr/bin --sbindir=/usr/sbin --sysconfdir=/etc
--datadir=/usr/share --includedir=/usr/include --libdir=/usr/lib64
--libexecdir=/usr/lib --localstatedir=/var --sharedstatedir=/var/lib
--mandir=/usr/share/man --infodir=/usr/share/info
--disable-dependency-tracking --enable-dmeventd --enable-cmdlib
--enable-udev_rules --enable-udev_sync --with-udev-prefix=/usr/
--enable-selinux --enable-pkgconfig --with-usrlibdir=/usr/lib64
--with-usrsbindir=/usr/sbin --with-default-dm-run-dir=/run
--with-tmpfilesdir=/usr/lib/tmpfiles.d --with-thin=internal
--with-device-gid=6 --with-device-mode=0640 --with-device-uid=0
--with-dmeventd-path=/usr/sbin/dmeventd
--with-thin-check=/usr/sbin/thin_check
--with-thin-dump=/usr/sbin/thin_dump
--with-thin-repair=/usr/sbin/thin_repair --enable-blkid_wiping
--enable-lvmpolld --enable-realtime --with-cache=internal
--with-default-locking-dir=/run/lock/lvm --with-default-pid-dir=/run
--with-default-run-dir=/run/lvm --enable-cmirrord --enable-fsadm
--disable-silent-rules --enable-write_install --with-vdo=internal
--with-vdo-format=/usr/bin/vdoformat

Anyway -- why does it keep failing to clear the hint file?  And how
can I modify a VG without changing it (just to remove the annoying
WARNING with every command).

Thanks!

Re: [linux-lvm] What to do about new lvm messages

[Stuart D Gathman]

On Sat, 22 Aug 2020, L A Walsh wrote:

> I am trying to create a new pv/vg/+lvs setup but am getting some weird messages
>
> pvcreate  -M2 --pvmetadatacopies 2 /dev/sda1
>  Failed to clear hint file.
>  WARNING: PV /dev/sdd1 in VG Backup is using an old PV header, modify
> the VG to update.
>  Physical volume "/dev/sda1" successfully created.
>
> So why am I getting a message about not clearing a hint file (running s root)

Because there is an ole PV header on sdd1

>> From an online man page, I should have been able to use -ff to
> recreate a pv over
> the top of a preexisting one, but that didn't seem to work.  I got:
> pvcreate -ff -M2 --pvmetadatacopies 2 /dev/sda1
>  Failed to clear hint file.
>  WARNING: PV /dev/sdd1 in VG Backup is using an old PV header, modify

You wrote a new PV header on sda1 - but that didn't do diddly squat 
about the old one on sdd1.

> the VG to update.
>  Cannot access VG Space with system ID Ishtar with unknown local system ID.
>  Device /dev/sda1 excluded by a filter.

The PV filter is excluding sda1.  Are you confused about what is on 
which sdx?

> dd if=/dev/zero of=/dev/sda1 bs=4096 count=1
> 1+0 records in
> 1+0 records out
> 4096 bytes (4.1 kB, 4.0 KiB) copied, 0.000175409 s, 23.4 MB/s

I hope sda1 was really what you think it was.

What is on sdd1?  None of your listings examine it.

Re: [linux-lvm] What to do about new lvm messages

[L A Walsh]

On Sat, Aug 22, 2020 at 5:39 AM Stuart D Gathman <stuart@gathman.org> wrote:
>
> On Sat, 22 Aug 2020, L A Walsh wrote:
>
> > pvcreate  -M2 --pvmetadatacopies 2 /dev/sda1
> >  Failed to clear hint file.
> > So why am I getting a message about not clearing a hint file (running as root)
>
> Because there is an ole PV header on sdd1
----
What does an ole PV header on sdd1 have to do with me recreating a PV
from/on  /dev/sda1?  I take it from your comment, that the 'hint' file
may be what is telling me to update the PV with /dev/sdd1?  That's not
very clear.


> >> From an online man page, I should have been able to use -ff to
> > recreate a pv over
> > the top of a preexisting one, but that didn't seem to work.  I got:
> > pvcreate -ff -M2 --pvmetadatacopies 2 /dev/sda1
> >  Failed to clear hint file.
> >  WARNING: PV /dev/sdd1 in VG Backup is using an old PV header, modify the VG to update.
>
> You wrote a new PV header on sda1 - but that didn't do diddly squat
> about the old one on sdd1.
---
  But I *didn't* write a new PV header on sda -- it said that
/dev/sda1 had an inaccessible VG on it with system ID ishtar with
unknown local system ID.
What does that mean?  the local system name is 'ishtar', which is why
I tried putting it in the system ID -- but then it says the VG with
system ID ishtar has an unknown local system ID.  But I thought the
system ID was the local system ID.  Ok, I'm ignoring system ID,
obviously it has nothing to do
with the system's name, which is why I wanted to recreate the PV
(sda1) without the 'ID' specification, thus my attempt at using
the '-ff' switch to force pvcreate to recreate the pv entry no matter what.


> >  Cannot access VG Space with system ID Ishtar with unknown local system ID.
> >  Device /dev/sda1 excluded by a filter.
>
> The PV filter is excluding sda1.  Are you confused about what is on
> which sdx?
---
   No -- I'm confused why it would tell me that the device I was
trying to create a new PV label on (/dev/sda1, from above) was
excluded by a filter.  I.e. instead of recreating the PV (without the
system id switch being specified), it said that the PV I was trying to
change was excluded by some filter.  Why would a filter be excluding
the 1 device I wanted to create a PV on?  I don't understand why it
would do that.


>
> > dd if=/dev/zero of=/dev/sda1 bs=4096 count=1
> > 1+0 records in
> > 1+0 records out
> > 4096 bytes (4.1 kB, 4.0 KiB) copied, 0.000175409 s, 23.4 MB/s
>
> I hope sda1 was really what you think it was.
----
       Me too!  That's why I first tried using the "-ff" switch on the
disk with pvcreate -- so it would force a new pv to be created.  Since
I couldn't use pvcreate to force overriding the bad, previous,
"VG-in-PV" that had that bad systemID in it, I was forced to use 'dd'
-- which I was uncomfortable with but it seems the -ff switch isn't
there anymore -- so the only way to force an overwrite is to use the
less safe 'dd' method.

    So, yes, I hope sda1 was really what I thought it was -- but would
have preferred that the safer "-ff" switch was still available.  IMO,
putting users into a position of needing to manually zero-out the
previous contents isn't ideal.  I.e. nothing about what to use instead
of '-ff' -- just a message about the  PV being excluded by a filter
(which didn't help me overwrite the old, incorrect PV.  So instead of
relying on users to hopefully get it write when zapping the old label,
it seems a "-ff" switch would be a bit safer, no?  Is there a reason
why it was removed?  Maybe, if there was a good reason, if it saw me
using a previously legal switch (-ff), it could have told me the new
way to do it.  Note, I didn't have the manpages for thew new version
installed yet, which is why I found the version telling me about use
of -f or -ff to forceably recreate the pv.

>
> What is on sdd1?  None of your listings examine it.
---
    A Red-Herring?  Not sure why it matters -- but, what is on the "VG
Backup"?
       Backups!
   I wasn't strongly motivated to mess with anything involving
"writes" to sdd1 -- which seemed to be my only copy of the data I am
trying to restore onto a new disk.   I had no idea what command to use
to modify the PV containing sdd1 that wouldn't involve me making a
change to a PV that I didn't want to make any changes to (at least not
until I'd recreated its contents on PV "/dev/sda1").

   It would be preferable to have an "update-PV label" that would
convert the older format to the new one.  That way I could be sure
that by executing it I wouldn't accidently create some side effect
that might compromise the data on the volume.

   So I'm still not sure why my new pvcreate wouldn't overwrite the
old one, nor am I sure why root failed to clear a hint file  (or at
least why it doen't tell me that they hint was to modify the PV
containing /dev/sdd1) -- I didn't know how the hint file was related
to my attempt to recreate th PV, nor do I know why the 1 volume I
wanted to change (sda1) should be filtered out to block my updating
the PV containg it.  I.e. I primarly reporting that these messages are
rather confusing.

   As it stands now, after a reboot, none of the LVM manage volumes
are accesible as, instead, I'm getting:
   " Waiting for udev to settle...
    Scanning for LVM volume groups...
      WARNING: Device /dev/sda not initialized in udev database even
after waiting 10000000 microseconds."
on each of the 'disks' (sda-sdd) managed by LVM...*sigh*.

The version of udevd isn't very helpful in telling what might have
changed as it just displays "210" when I ask for version.  That seems
to be what was workign before (on same kernel).

I have a feeling, BTW, that I wasn't very clear in asking why
1) I couldn't clear some hint file,
2) how I should have used pvcreate to overwrite the previous attemp
that had an ill-considered attempt to create a VG with a system-ID so
I wouldn't need to resort to using 'dd', and
3) how I should safely modify my backup PV (/dev/sdd1) such that it
wouldn't really be modified.

Thanks, and Cheers!

Re: [linux-lvm] What to do about new lvm messages

[David Teigland]

On Sat, Aug 22, 2020 at 04:36:27AM -0700, L A Walsh wrote:
> pvcreate  -M2 --pvmetadatacopies 2 /dev/sda1
>   Failed to clear hint file.
> So why am I getting a message about not clearing a hint file (running s root)

I'm guessing that no commands have permission to use /run/lvm/hints, so
they just skip it.  But, this is one place printing a warning about it.
I'll remove the warning.  Run 'pvs', and check if /run/lvm/hints exists.
If not, you might want to look at permission issues.

> and how do I modify a VG that I don't want to make any modifications to?

To fix that header you can run 'vgck --updatemetadata Backup'.

> From an online man page, I should have been able to use -ff to recreate
> a pv over the top of a preexisting one, but that didn't seem to work.  I
> got:
>  pvcreate -ff -M2 --pvmetadatacopies 2 /dev/sda1
>   Failed to clear hint file.
>   WARNING: PV /dev/sdd1 in VG Backup is using an old PV header, modify
> the VG to update.
>   Cannot access VG Space with system ID Ishtar with unknown local system ID.
>   Device /dev/sda1 excluded by a filter.

You're not using system ID correctly.

> I also ran into a problem on how to tell vgcreate to use the whole pv.
> That was complicated by trying to specify my hostname as a system id:

>   Cannot access VG Space with system ID Ishtar with unknown local system ID.

The machine needs to have a system ID configured.  See lvmsysystemid(7)
and edit lvm.conf/lvmlocal.conf.  Then vgcreate will use the machine's
system for the new VG.  Using --systemid overrides the local value which
you don't want.