replying to my last email.
do the pvcreate -uuid and then do a pvs/lvs/vgs and see if the vg/lv's look like that are there. if so do a vgchange -ay <vgname> and then test mounting the fs.
And if with the fs either commented out and/or ,nofail the normal os boots up work from there as you should have backup files.
On Wed, Oct 20, 2021 at 1:01 PM Roger Heflin <rogerheflin@xxxxxxxxx> wrote:
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.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.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.On Wed, Oct 20, 2021 at 8:39 AM Brian McCullough <bdmc@xxxxxxxxxxxx> wrote:On Tue, Oct 19, 2021 at 05:06:37AM -0500, Roger Heflin wrote:
> I would edit the vgconfig you dd'ed with an editor and make sure it looks
> reasonable for what you think you had.
It turns out, comparing the information that I pulled off of the drive
with what I find in /etc/lvm/backup, that the first part of the vgconfig
information is missing. As I said in one of my messages, the
information that I retrieved from the disk starts at 0x1200. I don't
know whether that is correct or not. It does not appear to be a proper
"backup" file, which I think it should be.
I rebooted ( partially ) the machine and copied the vgconfig backup file
from that, but am somewhat concerned, because I don't seem to be able to
match the UUIDs. The one that I seem to see in the vgconfig data that I
pulled off of the drive vs what I got out of /etc/lvm/backup. Maybe I
am just mis-reading it. I will continue my research for a bit.
> When you do the pvcreate --uuid it won't use anything except the uuid info
> so the rest may not need to be exactly right, if you have to do a
> vgcfgrestore to get it to read the rest of the info will be used.
Oh, thank you. I did see that things got somewhat different on the
target drive when I did "pvcreate --uuid --restorefile." I got paranoid
when I saw that, and re-copied the ddrestore file back to the target
drive before I did anything else. Should I do "pvcreate --uuid
--norestorefile," instead? Then, once it is back in the machine, do the
pvscan and vgcfgrestore, and expect good things?
> I have seen some weird disk controller failures that appeared to zero out
> the first bit of the disk (enough to get the partition table, grub, and the
> pv header depending on where the first partition starts).
I APPEAR to have a partition table, containing an NTFS partition, an LVM
partiton ( the one that I am concentrating on ) and a Linux partion. I
would have thought that it was all LVM, but my memory could easily be
wrong.
> You will need to reinstall grub if this was the bootable disk, since there
> were 384 bytes of grub in the sector with the partition table that you know
> are missing.
Fortunately, this is all data, nothing to do with the boot sequence,
except that the machine will not boot with the missing PV.
Thank you,
Brian
_______________________________________________
linux-lvm mailing list
linux-lvm@xxxxxxxxxx
https://listman.redhat.com/mailman/listinfo/linux-lvm
read the LVM HOW-TO at http://tldp.org/HOWTO/LVM-HOWTO/
_______________________________________________ linux-lvm mailing list linux-lvm@xxxxxxxxxx https://listman.redhat.com/mailman/listinfo/linux-lvm read the LVM HOW-TO at http://tldp.org/HOWTO/LVM-HOWTO/
