All of lore.kernel.org
 help / color / mirror / Atom feed
From: Martin Steigerwald <martin@lichtvoll.de>
To: linux-btrfs@vger.kernel.org
Subject: Re: parent transid verify failed + level verify failed
Date: Sun, 19 Nov 2023 19:41:58 +0100	[thread overview]
Message-ID: <4868643.GXAFRqVoOG@lichtvoll.de> (raw)
In-Reply-To: <4896535.31r3eYUQgx@lichtvoll.de>

Martin Steigerwald - 19.11.23, 17:41:17 CET:
> / was not mountable anymore after booting into GRML. Made image with dd
> and restored from backup onto a newly created BTRFS.

I at least have a possible explanation.

Yesterday I experienced 6.7-almost-rc2 not hibernating correctly, but 
instead hanging with black screen. I rebooted into 6.6.1. Last thing I did 
was remove 6.7-almost-rc2 and hibernate.

In the morning I was greeted by GRUB command line prompt for a reason I do 
not understand yet either. I recovered from this with two GRML sessions. 
For that at least I unlocked LUKS and mounted / and /boot in GRML. If my 
memory is correct after I fixed booting up in these two GRML sessions, 
kernel 6.6.1 resumed from hibernation. That does make some session as in 
the GRML session I did not touch the swap volume. So I bet the hibernation 
image was not invalidated. However that would explain the corruption on / 
filesystem. Cause it was mounted in between and then the kernel resumed 
from a hibernation image with outdated in-memory data structures for 
BTRFS.

If my memory and analysis is correct this would easily explain the 
corruption on /. Still not sure what happened to /home. I think I did not 
touch it on attempting to repair GRUB. However I am not 100% sure about 
that.

Would be interesting to know whether diagnostic data would fit that 
explanation.

In case that is correct, then I think it would be good that in case I ever 
need to fix up GRUB again I also activate swap volume within GRML in the 
hope to invalidate the hibernation image. But I am not completely sure 
whether activating swap would be enough for that.

> /home also had errors. Did not take a chance. Scrubbed it, updated a
> backup with good old rsync, recreated filesystem and restored from
> updated backup.

Best,
-- 
Martin



      reply	other threads:[~2023-11-19 18:42 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-11-19 11:34 parent transid verify failed + level verify failed Martin Steigerwald
2023-11-19 16:41 ` Martin Steigerwald
2023-11-19 18:41   ` Martin Steigerwald [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:
  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=4868643.GXAFRqVoOG@lichtvoll.de \
    --to=martin@lichtvoll.de \
    --cc=linux-btrfs@vger.kernel.org \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.