* [linux-lvm] What to do about new lvm messages @ 2020-08-22 11:36 L A Walsh 2020-08-22 11:45 ` Stuart D Gathman 2020-08-24 15:33 ` David Teigland 0 siblings, 2 replies; 4+ messages in thread From: L A Walsh @ 2020-08-22 11:36 UTC (permalink / raw) To: linux-lvm 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! ^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [linux-lvm] What to do about new lvm messages 2020-08-22 11:36 [linux-lvm] What to do about new lvm messages L A Walsh @ 2020-08-22 11:45 ` Stuart D Gathman 2020-08-24 2:35 ` L A Walsh 2020-08-24 15:33 ` David Teigland 1 sibling, 1 reply; 4+ messages in thread From: Stuart D Gathman @ 2020-08-22 11:45 UTC (permalink / raw) To: LVM general discussion and development 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. ^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [linux-lvm] What to do about new lvm messages 2020-08-22 11:45 ` Stuart D Gathman @ 2020-08-24 2:35 ` L A Walsh 0 siblings, 0 replies; 4+ messages in thread From: L A Walsh @ 2020-08-24 2:35 UTC (permalink / raw) To: LVM general discussion and development 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! ^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [linux-lvm] What to do about new lvm messages 2020-08-22 11:36 [linux-lvm] What to do about new lvm messages L A Walsh 2020-08-22 11:45 ` Stuart D Gathman @ 2020-08-24 15:33 ` David Teigland 1 sibling, 0 replies; 4+ messages in thread From: David Teigland @ 2020-08-24 15:33 UTC (permalink / raw) To: L A Walsh; +Cc: linux-lvm 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. ^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2020-08-24 15:33 UTC | newest] Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2020-08-22 11:36 [linux-lvm] What to do about new lvm messages L A Walsh 2020-08-22 11:45 ` Stuart D Gathman 2020-08-24 2:35 ` L A Walsh 2020-08-24 15:33 ` David Teigland
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).