Leap 15.1 bootet nicht, btrfs kaputt

Hardware: Lenovo Thinkpad X1 Tablet 3.Generation, 500GB SSD
Software: Dual boot mit vorinstalliertem Windows 10, OpenSUSE Leap 15.1

Das Gerät wurde vor 3 Monaten gekauft, Linux läuft darauf seit 2 Monaten. Es ist also eine neue Installation. Seit Kauf hat Lenovo die Firmware und das Bios mehrfach aktualisiert.

Die Linuxpartition ist /dev/nvme0n1p5 formatiert mit btrfs, der Swap-Bereich ist auf auf /dev/nvme0n1p6.
/dev/nvme0n1p1 bis /dev/nvme0n1p4 sind für Windows.

Ablauf des Fehlers:
Beim Arbeiten unter Linux erschienen plötzlich, ohne ersichtlichen Grund Fehlermeldungen, dass Dateien nicht mehr ins /home-Verzeichnis geschrieben werden können.
Nach Herunterfahren konnte Linux nicht mehr gebootet. werden. Der Bootprozess kommt bis zum Bootmanager. Windows kann daraus noch gebootet werden. Linux kann nicht gebootet werden und es gibt die folgenden Fehlermeldungen:

BTRFS critical (device nvme0n1p5): corrupt leaf: root=2 block=24961368064 slot=192, bad key order, prev (19392573440 168 4096) current (2038972416 0 4096)

BTRFS error (device nvme0n1p5): failed to read block groups: -5

BTRFS error (device nvme0n1p5): open_ctree failed

In der Ausgabe von journalctl erscheint folgende Fehlermeldung:

sysroot.mount: Mount process exited, code=exited status=32
failed to mount /sysroot

Ich habe von der Installations-DVD ein Rettungssystem gebootet und Folgendes erfolglos versucht:

btrfs rescue super-recover /dev/nvme0n1p5
und
btrfs rescue chunk-recover /dev/nvme0n1p5

Beides lief fehlerfrei durch, änderte aber nichts.

Dann habe ich noch

btrfs check --repair /dev/nvme0n1p5

ausprobiert. Das änderte auch nichts und brach mit folgender Fehlermeldung ab:
bad key ordering 191 192
ERROR: Cannot open file system
Das heißt, ich kann nicht einmal mit den Wartungsprogrammen auf die Partition zugreifen.

Ich bin ratlos. Hat jemand eine Idee, was ich noch machen könnte (außer einer kompletten Neuinstallation)?

Vielen Dank im Voraus

Hi,

spontan habe ich diesen Vorschlag gefunden, der vermeintlich geholfen hat. Kannst du nach Ausführen des folgenden Befehls die Partition mounten?

btrfs check --init-extent-tree /dev/nvme0n1p5

Du hattest keine getrennte Partition für /home?

**Falls doch, **
kannst Du mittels Nutzung des Dateimanagers eines Linux-Live-Systems (ich nutze “Krypton”) Dein User-Verzeichnis aus der Home-Partition Deines Rechners auf einen externen Datenträger (z.B. USB-Stick) sichern.
Falls beim Neuinstallieren von openSUSE ein Fehler passieren sollte.
Dann einfach Suse Leap wieder neu aufspielen auf Deinen Rechner, dabei legst Du den neuen user z.B. mit User-Namen “Neu” an.

Achtung:
Ich formatiere traditionell die Partitionen für / (root) und /home nach wie vor mit ext4, was mir bisher immer problemlosen Betrieb ermöglichte, auch weil ich mit btrfs und Co. schon ähnliche unliebsame Überraschungen hatte und nicht den Beta-Tester spielen möchte. Die Empfehlungen, die man bei der Installation von openSUSE hinsichtlich Partitionierung bekommt, befolge ich bewusst NICHT - Sicherheit geht vor!

Nach dem Dein openSUSE neu installiert ist, fügst Du ggfs. Dein altes User-Verzeichnis wieder in /home hinzu.
Dann legst Du in Yast neben “Neu” einen zweiten User “Dein alter User-Name” an.
Die Frage “Eigentümer ändern?” bestätigst du mit ja.
Du müsstest dann ggfs. noch die Regeln für das Automatische Anmelden ändern und den User “Neu” löschen, falls gewünscht.

Falls nein,
hast Du schon versucht, direkt mit dem Dateimanager eines Live-Systems auf Deine Linux-Partition zuzugreifen?
Wenn dies gelingt, rette Deine Daten, bevor Du neu installierst.
Wenn nicht, hast Du Pech gehabt und trotzdem was gelernt.

Ich habe in den letzten Jahren etliche openSUSE - Versionen durch auf meinen vielen Rechnern, immer wieder Upgrade oder Neuinstallation.
Dabei nutze ich die User-Verzeichnisse immer weiter und Weiter.

Das kann ich nur unterstreichen: seit 1996, seit ich S.u.S.E./SuSE/openSUSE Linux privat und in Firmen einsetze, habe ich mit ext2/ext3/ext4 stets beste Erfahrungen gemacht und nie Probleme gehabt.
Ich kann mich vage an zwei, drei Situationen vor 15 Jahre erinnern, wo ungewollte Stromaussetzer eine Runde mit fsck.ext[2,3] nötig machten, dann war wieder alles klar.

Ich finde neuere bzw. leistungsfähigere Server-Dateisysteme wie ZFS/XFS/btrfs etc faszinierende Errungenschaften, und ich kann die Entscheidung bei SuSE zum Teil verstehen, btrfs zu pushen, aber Sicherheit geht vor Features! Es gibt einige Verteidiger von btrfs hier im Forum, die selten oder nie Probleme mit ihren btrfs-Partitionen hatten. Andererseits vergeht keine Woche, wo nicht immer neue User Threads starten, die neue (und auch längst bekannte) Problemen in Verbindung mit btrfs schildern: Boot-Probleme, CPU-Auslastung und SSD-Verschleiß durch ein Dutzend überaktiver btrfs-Helper-Threads, korrupte Partitionen, alte/korrupte/fehlende Dateien, volle Read-Only-Dateisysteme aufgrund falscher btrfs-Statistiken, verwirrende Mount-/Unmount-/Snapshot-Kapriolen, etc etc.

Fazit: so lange ich nicht unbedingt ZFS-/XFS-/btrfs-Features benötige, lasse ich meine Daten auf ext4.

Der funktioniert auch nicht, aber Danke, man muss alles ausprobieren. Interessanterweise bekomme ich einen core dump mit diesem Befehl. Der signifikante Teil der Fehlermeldugnen lautet:

Unable to find block group for 0
Aborted (core dumped)

Ich habe immer 2 Systempartitionen und unlängst eine davon auf btrfs umgestellt: It’s not a trick, it’s Snapper running on openSUSE | Karl Mistelberger

Unter man btrfs-check kannst du lesen:

Warning

"Do not use –repair unless you are advised to do so by a developer or an experienced user, and then only after having accepted that no fsck successfully repair all types of filesystem corruption. Eg. some other software or hardware bugs can fatally damage a volume. "

Das sollten alle beachten, die btrfs ernsthaft einsetzen. Erfahrene Benutzer haben hier ihre Ratschläge aufgeschrieben: Btrfs - ArchWiki Hilft die das weiter?

Nachtrag: https://fedoraproject.org/wiki/Btrfs#Frequently_Asked_Question.28s.29

If a Btrfs volume fails to mount, try ‘mount -o usebackuproot’. If that also fails report the issue on the Btrfs mailing list, including the output from ‘btrfs check’ without --repair.