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
prev parent 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.