From: Roger Heflin <rogerheflin@gmail.com>
To: LVM general discussion and development <linux-lvm@redhat.com>
Subject: Re: [linux-lvm] Recovering "broken" disk ( 17th )
Date: Wed, 20 Oct 2021 13:04:44 -0500 [thread overview]
Message-ID: <CAAMCDedAPFz+EL3MBcOKebZXqB4pSxUCuvhW4DUfjiLX3tznMQ@mail.gmail.com> (raw)
In-Reply-To: <CAAMCDec9HehohCFxCXDd7d+5DVW1DuJ4KVY7Vu1J0x+6ZxUW=w@mail.gmail.com>
[-- Attachment #1.1: Type: text/plain, Size: 3878 bytes --]
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@gmail.com> 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@bdmcc-us.com>
> 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@redhat.com
>> https://listman.redhat.com/mailman/listinfo/linux-lvm
>> read the LVM HOW-TO at http://tldp.org/HOWTO/LVM-HOWTO/
>>
>>
[-- Attachment #1.2: Type: text/html, Size: 5047 bytes --]
[-- Attachment #2: Type: text/plain, Size: 201 bytes --]
_______________________________________________
linux-lvm mailing list
linux-lvm@redhat.com
https://listman.redhat.com/mailman/listinfo/linux-lvm
read the LVM HOW-TO at http://tldp.org/HOWTO/LVM-HOWTO/
next prev parent reply other threads:[~2021-10-21 6:07 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-10-18 2:17 [linux-lvm] Recovering "broken" disk ( 17th ) Brian McCullough
2021-10-18 14:49 ` Roger Heflin
2021-10-18 19:45 ` Brian McCullough
2021-10-19 10:06 ` Roger Heflin
2021-10-20 13:38 ` Brian McCullough
2021-10-20 18:01 ` Roger Heflin
2021-10-20 18:04 ` Roger Heflin [this message]
2021-10-21 6:13 ` Brian McCullough
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=CAAMCDedAPFz+EL3MBcOKebZXqB4pSxUCuvhW4DUfjiLX3tznMQ@mail.gmail.com \
--to=rogerheflin@gmail.com \
--cc=linux-lvm@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
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).