archive mirror
 help / color / mirror / Atom feed
From: Zdenek Kabelac <>
To: LVM general discussion and development <>,
	Dave Cohen <>
Subject: Re: [linux-lvm] repair pool with bad checksum in superblock
Date: Fri, 23 Aug 2019 10:59:10 +0200	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <>

Dne 23. 08. 19 v 2:18 Dave Cohen napsal(a):
> I've read some old posts on this group, which give me some hope that I might recover a failed drive.  But I'm not well-versed in LVM, so details of what I've read are going over my head.
> My problems started when my laptop failed to shut down properly, and afterwards booted only to dracut emergency shell.  I've since attempted to rescue the bad drive, using `ddrescue`.  That tool reported 99.99% of the drive rescued, but so far I'm unable to access the LVM data.
> Decrypting the copy I made with `ddrescue` gives me /dev/mapper/encrypted_rescue, but I can't activate the LVM data that is there.  I get these errors:
> $ sudo lvconvert --repair qubes_dom0/pool00
>    WARNING: Not using lvmetad because of repair.
>    WARNING: Disabling lvmetad cache for repair command.
> bad checksum in superblock, wanted 823063976
>    Repair of thin metadata volume of thin pool qubes_dom0/pool00 failed (status:1). Manual repair required!
> $ sudo thin_check /dev/mapper/encrypted_rescue
> examining superblock
>    superblock is corrupt
>      bad checksum in superblock, wanted 636045691
> (Note the two command return different "wanted" values.  Are there two superblocks?)
> I found a post, several years old, written by Ming-Hung Tsai, which describes restoring a broken superblock.  I'll show that post below, along with my questions, because I'm missing some of the knowledge necessary.
> I would greatly appreciate any help!

I think it's important to know the version of thin tools ?

Are you using  0.8.5 ?

If so  - feel free to open Bugzilla and upload your metadata so we can check 
what's going on there.

In BZ provide also lvm2 metadata and the way how the error was reached.

Out typical error we see with thin-pool usage is  'doubled' activation.
So thin-pool gets acticated on 2 host in parallel (usually unwantedly) - and 
when this happens and 2 pools are updating same metadata - it gets damaged.



  reply	other threads:[~2019-08-23  8:59 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-08-23  0:18 [linux-lvm] repair pool with bad checksum in superblock Dave Cohen
2019-08-23  8:59 ` Zdenek Kabelac [this message]
2019-08-23 11:40   ` Dave Cohen
2019-08-23 12:47     ` Zdenek Kabelac
2019-08-23 14:58       ` Gionatan Danti
2019-08-23 15:29         ` Stuart D. Gathman
2019-08-25  2:13       ` Dave Cohen

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:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \ \ \ \ \

* 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).