<div dir="ltr"><div>is the pv in the root device vg?  if not changing fstab to not mount the missing  fs(es) should get it bootable.   I have a practice of putting ",nofail" on all non-root filesystems (ie defaults,nofail) since priority #1 is getting the machine up and on the network after a reboot such that it can be ssh'ed to and fixed as needed.<br></div><div><br></div><div>If it is not the root device then on the root device there should be several prior archive copy in /etc/lvm/archive/<vgname>*, and maybe some copies in /etc/lvm/backup.<br></div><div><br></div><div>In the vg backup file there will be a bunch of uuids, you want the specific pv uuid and not the vg/lv uuids.  Each pv has a uuid and each lv has a uuid and the vg has a uuid.<br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Oct 20, 2021 at 8:39 AM Brian McCullough <<a href="mailto:bdmc@bdmcc-us.com">bdmc@bdmcc-us.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On Tue, Oct 19, 2021 at 05:06:37AM -0500, Roger Heflin wrote:<br>
> I would edit the vgconfig you dd'ed with an editor and make sure it looks<br>
> reasonable for what you think you had.<br>
<br>
It turns out, comparing the information that I pulled off of the drive<br>
with what I find in /etc/lvm/backup, that the first part of the vgconfig<br>
information is missing.  As I said in one of my messages, the<br>
information that I retrieved from the disk starts at 0x1200.  I don't<br>
know whether that is correct or not.  It does not appear to be a proper<br>
"backup" file, which I think it should be.<br>
<br>
I rebooted ( partially ) the machine and copied the vgconfig backup file<br>
from that, but am somewhat concerned, because I don't seem to be able to<br>
match the UUIDs.  The one that I seem to see in the vgconfig data that I<br>
pulled off of the drive vs what I got out of /etc/lvm/backup.  Maybe I<br>
am just mis-reading it.  I will continue my research for a bit.<br>
<br>
<br>
<br>
<br>
> When you do the pvcreate --uuid it won't use anything except the uuid info<br>
> so the rest may not need to be exactly right, if you have to do a<br>
> vgcfgrestore to get it to read the rest of the info will be used.<br>
<br>
Oh, thank you.   I did see that things got somewhat different on the<br>
target drive when I did "pvcreate --uuid --restorefile."  I got paranoid<br>
when I saw that, and re-copied the ddrestore file back to the target<br>
drive before I did anything else.   Should I do "pvcreate --uuid<br>
--norestorefile," instead?  Then, once it is back in the machine, do the<br>
pvscan and vgcfgrestore, and expect good things?<br>
<br>
<br>
<br>
> I have seen some weird disk controller failures that appeared to zero out<br>
> the first bit of the disk (enough to get the partition table, grub, and the<br>
> pv header depending on where the first partition starts).<br>
<br>
I APPEAR to have a partition table, containing an NTFS partition, an LVM<br>
partiton ( the one that I am concentrating on ) and a Linux partion.  I<br>
would have thought that it was all LVM, but my memory could easily be<br>
wrong.<br>
<br>
<br>
<br>
> You will need to reinstall grub if this was the bootable disk, since there<br>
> were 384 bytes of grub in the sector with the partition table that you know<br>
> are missing.<br>
<br>
Fortunately, this is all data, nothing to do with the boot sequence,<br>
except that the machine will not boot with the missing PV.<br>
<br>
<br>
<br>
Thank you,<br>
Brian<br>
<br>
_______________________________________________<br>
linux-lvm mailing list<br>
<a href="mailto:linux-lvm@redhat.com" target="_blank">linux-lvm@redhat.com</a><br>
<a href="https://listman.redhat.com/mailman/listinfo/linux-lvm" rel="noreferrer" target="_blank">https://listman.redhat.com/mailman/listinfo/linux-lvm</a><br>
read the LVM HOW-TO at <a href="http://tldp.org/HOWTO/LVM-HOWTO/" rel="noreferrer" target="_blank">http://tldp.org/HOWTO/LVM-HOWTO/</a><br>
<br>
</blockquote></div>