archive mirror
 help / color / mirror / Atom feed
From: "Dave Cohen" <>
To: Zdenek Kabelac <>,
	LVM general discussion and development <>
Subject: Re: [linux-lvm] repair pool with bad checksum in superblock
Date: Sat, 24 Aug 2019 22:13:38 -0400	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <>

On Fri, Aug 23, 2019, at 8:47 AM, Zdenek Kabelac wrote:
> Dne 23. 08. 19 v 13:40 Dave Cohen napsal(a):
> > 
> > 
> > $ thin_check --version
> > 0.8.5
> Hi
> So if repairing fails even with the latest version - it's better to upload 
> metadata into BZ created here:

I've created

> >> 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.
> >>
> > 
> > When you say "upload your metadata" and "lvm2 metadata", can you tell me exactly how to get it?  Sorry for the basic question but I'm not sure what to run and what to upload.
> Upload 'dd' compressed copy of you ORIGINAL  _tmeta content (which now could 
> be likely already in volume  _meta0 - if you had one succesful run of --repair 
> command).

Hmmm.  I'm not sure how to use `dd` for this.  If I'm missing something obvious, please let me know. Note, I cannot activate any portion of the pool.

> If you use older 'lvm2' you might have a problem with accessing _tmeta
> device content - if you have latest fc30 - you should be able
> to activate _tmeta as standalone component activation.
> To get lvm2 metadata backup just use  'vgcfgbackup -f output.txt  VGNAME'

This succeeded, and I attached to the ticket.

> Let us know if you have problem with getting kernel _tmeta or lvm2 meta.

As I wrote above, could not get the _tmeta.  If you're referring to a part of the pool, it does not activate via `lvchange -ay`

> > In my case, lvm was set up by qubes-os, on a laptop.  The disk drive had a physical problem.  I'll put those details into bugzilla.  (But I'm waiting for answer to metadata question above before I submit ticket.)
> Ok - serious disk error might lead to eventually irrepairable metadata content 
> - since if you lose some root b-tree node sequence it might be really hard
> to get something sensible  (it's the reason why the metadata should be located
> on some 'mirrored' device - since while there is lot of effort put into
> protection again software errors - it's hard to do something with hardware 
> error...

Exactly how to do this is still beyond me.  But I'm up for learning, and contributing it back to the qubes-os project.


      parent reply	other threads:[~2019-08-25  2:13 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
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 [this message]

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