Emergency mode - superblock error - Wieso ist das passiert?

thommes · July 15, 2025, 8:52pm

Hey liebe Geekos,

dies wird mein erster Post in diesem Forum. Ebenso sei gesagt, dass ich weder der größte Linuxnerd bin, noch vermutlich dazu avancieren werde. Ich bemühe ich. Ich muss allerdings öfter als es mir lieb ist auf Internetsuchen zurückgreifen für Lösung und Verständnis. Jetzt ist mir etwas passiert, dass ich gerne besser verstehen würde und brauche dafür eure Hilfe.

Worum soll es in diesem Post also gehen?

Ich benutze seit einigen Monaten OpenSUSE Tumbleweed als mein einziges OS mit btrfs-Dateisystem. Zuvor habe ich Ubuntu benutzt. Mir ist zwar aufgefallen, dass das System ingesamt etwas leistungsfähiger scheint, allerdings hatte ich sporadisch Probleme damit, dass mein OS, ohne Korrelation mit irgendeiner Aktion eingefroren ist. Das konnte mal bei der Arbeit in der IDE, beim Surfen, oder beim Schreiben sein. Nervig, aber aushaltbar. Bis gestern kam.

Der Bildschirm fror abermals ein, diesmal bootete das System jedoch nur noch in den emergency mode, mit dem ich bisher gottseidank keine Bekanntschaft machen musste.

Nach Konsultation von journalctl ergab sich ein Hinweis darauf, dass die Partition /sysroot nicht mehr eingehangen werden konnte. Zwar verstand ich nun warum mein System nicht startete, aber die mögliche Ursache ist mir bis jetzt unklar. Dabei erhoffe ich mir hier vielleicht ein paar Insights.

Was habe ich versucht um mein Problem zu lösen?

Zunächst dachte ich ganz naiv an snapper. Also zack neugestartet, letztes, “funktionales” Snapshot ausgewählt und oopsie saß ich wieder im emergency mode. Das brachte also keine Lösung.
Dann habe ich meine Installations-USB eingeworfen (kein Live-Medium), durch die ich über ein entsprechendes Optionsmenü auf wundersameweise (nicht “boot from hard disk”, das war eine andere Option) in ein offensichtlich älteren Snapshot meines Systems booten konnte. Hier ist spannend, dass ich über sudo snapper listauch sehen konnte, dass das nun gebootete System nur Snapshots von vor 3 Monaten kannte. Interessante Beobachtung, da ich in meinem normalen Bootmenü zumindest die neueren Snapshots gelistet bekam.
Ich habe dieses wackelige System benutzt, um eine Tumbleweed Live-Image auf einen anderen USB-Stick zu ziehen und erste weitere Analysen zu wagen.

Mein System hat folgende Partitionen:

nvme0n1p1 EFI-System Partition
nvme0n1p3 BTRFS-Systempartition mit /
nvme0n1p4 BTRFS-Partition die offensichtlich nur ältere Snapshots enthält (not sure why what and how)
nvme0n1p5 Swap

Ich konnte nun feststellen, dass die entsprechende Partition nvme0n1p3, die mein Dateisystem enthält nicht eingehangen werden konnte mit dem Hinweis cant read superblock. Autsch, das klang schmerzhaft.

Das erstellte Live-System habe ich dann benutzt, um alle weiteren Schritte zu unternehmen:

Zunächst habe ich über

sudo parted -l

versucht festzustellen, ob meine Partition als damaged angezeigt wird. Dann habe ich btrfs-progs instaliert und folgendes versucht:

sudo btrfs rescue super-recover -v /dev/nvme0n1p3

bekam allerdings zu lesen:
“All supers are valid. No need to recover”

Ok, was nun? Zum Ziel führte mich

sudo dmesg

worüber ich feststellen konnte, dass mein log tree fehlerhaft ist. Was das ganz genau bedeutet, well, not so sure.

Final führte ich dann folgenden Befehl aus:

sudo btrfs rescue zero-log /dev/nvme0n1p3

Danach war es gottseidank wieder möglich meine Systempartition zu mounten und mein System normal zu booten.

Wtf just happened. Das ist mir unter Ubuntu noch nie passiert, ich möchte aber auch nicht OpenSuse blamen, oder btrfs,oder meine SSD, oder mich,…ohne etwas mehr Verständnis aufzubauen.

Ich wäre dankbar für die mögliche Hintergründe und ob die Gefahr besteht, dass dies wieder passiert. Denn ich bin eigentlich sehr zufrieden mit OpenSUSE, mit Tumbleweed und überhaupt

Viele Grüße

(Viele der genannten Schritte habe ich auf linuxbabe.com gefunden, das sei mal als Referenz erwähnt).

karlmistelberger · July 16, 2025, 7:06am

thommes:

Final führte ich dann folgenden Befehl aus:
sudo btrfs rescue zero-log /dev/nvme0n1p3
Danach war es gottseidank wieder möglich meine Systempartition zu mounten und mein System normal zu booten.

Wtf just happened. Das ist mir unter Ubuntu noch nie passiert, ich möchte aber auch nicht OpenSuse blamen, oder btrfs,oder meine SSD, oder mich,…ohne etwas mehr Verständnis aufzubauen.

Ich wäre dankbar für die mögliche Hintergründe und ob die Gefahr besteht, dass dies wieder passiert. Denn ich bin eigentlich sehr zufrieden mit OpenSUSE, mit Tumbleweed und überhaupt

Gefahren sind immer und überall. Nichtsdestotrotz habe ich Dutzende Systeme auf Tumbleweed mit btrfs umgestellt. Ich verwende auf allen Systemen diese Standardeinstellungen:

erlangen:~ # btrfs filesystem usage /
Overall:
    Device size:                   1.82TiB
    Device allocated:              1.06TiB
    Device unallocated:          775.86GiB
    Device missing:                  0.00B
    Device slack:                    0.00B
    Used:                        955.96GiB
    Free (estimated):            903.95GiB      (min: 516.02GiB)
    Free (statfs, df):           903.95GiB
    Data ratio:                       1.00
    Metadata ratio:                   2.00
    Global reserve:              512.00MiB      (used: 0.00B)
    Multiple profiles:                  no

Data,single: Size:1.02TiB, Used:918.91GiB (87.77%)
   /dev/nvme0n1p2          1.02TiB

Metadata,DUP: Size:20.00GiB, Used:18.53GiB (92.63%)
   /dev/nvme0n1p2         40.00GiB

System,DUP: Size:32.00MiB, Used:144.00KiB (0.44%)
   /dev/nvme0n1p2         64.00MiB

Unallocated:
   /dev/nvme0n1p2        775.86GiB
erlangen:~ #

Ein Filesystem mit diesen Einstellungen ist robust und auch mutwillig nicht totzukriegen. Ich habe mehrfach intensive Schreibvorgänge auf der Systempartition durchgeführt und dabei buchstäblich den Netzstecker gezogen. Um weitermachen zu können musste ich ihn natürlich wieder einstecken und den Einschaltkopf drücken. Dann konnte ich weitermachen wo ich unterbrochen hatte.

Die Benutzer von btrfs tendieren dazu, einige wichtige Betrachtungen zu ignorieren:

Hardware as the main source of filesystem corruptions

If you use unreliable hardware and don’t know about that, don’t blame the filesystem when it tells you.

https://btrfs.readthedocs.io/en/latest/Hardware.html#hardware-as-the-main-source-of-filesystem-corruptions

thommes · July 16, 2025, 7:37am

Vielen Dank für deine Antwort.

Ich lese durch die Blume: Meine SSD ist Schuld? Und andere Dinge sind quasi auszuschließen, richtig?

Ich benutze ein relativ neues Thinkpad P14s G4, die verbaute SSD ist diese.

Kann natürlich ein Sonntagsgerät sein. Es schien mir nur relevant zu erwähnen, dass ich diese Probleme erst nach dem Wechsel zu OpenSuse hatte. Die Frage für mich wäre also, sollte ich das System neu aufsetzen? Könnte hier etwas schief gelaufen sein?

Oder sollte ich davon ausgehen, dass die SSD eine Schluckauf hatte und die Wahrscheinlichkeit gering ist, dass dies wieder passiert? Oder eben hoch, weil “broken”?

VG

karlmistelberger · July 16, 2025, 11:30am

Falsch. Viele Fehlerursachen sind möglich.

Seit 3 Jahren mache ich intensive Betreuung für eine Handvoll ThinkPads W530 aus 2013. Tumbleweed läuft darauf problemlos. btrfs ist auf Samsung 850 EVOs und PROs installiert und hatte noch nie Grund zum Meckern. Mit der SK hynix PC801 HFS512GEJ9X162N habe ich keine Erfahrung.

Von irgend etwas auszugehen ist keine gute Idee. Meistens stellt sich das bei intensiver Benutzung sehr schnell heraus. Schluckauf kommt vor. Klarheit schafft nur der Betrieb über längere Zeit. Das Journal von Infamous Host Erlangen reicht ein Jahr zurück und enthält keine BTRFS Fehler. Was liefert auf deinem System dieses Kommando als Benutzer root ausgeführt:

journalctl -q -g 'BTRFS: error'

Spezielle Tests können den Zeitraum abkürzen.

thommes · July 16, 2025, 8:12pm

Folgendes konnte ich finden. 14. Juli passt vom Datum zu dem von mir beschriebenen Vorfall, auch zeitlich.

[...]
Jul 07 13:23:13 xxx kernel: BTRFS warning (device nvme0n1p3): failed to trim 118 block group(s), last error -512
Jul 07 13:23:13 xxx kernel: BTRFS warning (device nvme0n1p3): failed to trim 1 device(s), last error -512
[...]
Jul 14 20:27:19 xxx kernel: BTRFS warning (device nvme0n1p3): failed to trim 136 block group(s), last error -512
Jul 14 20:27:19 xxx kernel: BTRFS warning (device nvme0n1p3): failed to trim 1 device(s), last error -512
[...]

Das war aber wirklich auch alles. Kannst du darauf basierend eine Fehlerhypothese verifizieren oder falsifizieren?

VG

karlmistelberger · July 17, 2025, 5:33am

Mit diesem Blick durch das Schlüsselloch wirst du der Ursache für das wiederholte Einfrieren und das gelegentliche Versagen von btrfs nicht auf die Spur kommen. Hauptverdächtiger ist natürlich die SSD.

Ich habe ein Google Konto und kriege damit brauchbare KI Übersicht:
https://www.google.com/search?q=how+to+troubleshoot+btrfs

Zwei Beispiele aus dem Forum:

Wenn dir das obige nicht weiterhilft kannst du versuchen von vorne anzufangen und neu zu installieren. Bei relativ neuer Hardware wie deinem ThinkPad funktioniert Tumbleweed mit den Standardeinstellungen problemlos. Ich verwende grundsätzlich bei allen Neuinstallationen diese minimale Partitionierung:

6700k:~ # fdl /dev/nvme0n1
Disk /dev/nvme0n1: 476.94 GiB, 512110190592 bytes, 1000215216 sectors
Disk model: Samsung SSD 950 PRO 512GB               
Disklabel type: gpt
Disk identifier: A84F222E-0177-499B-A7EA-BDA6F31E2196

Device           Size Type
/dev/nvme0n1p1   100M EFI System
/dev/nvme0n1p2 476.8G Linux filesystem
6700k:~ #

thommes · July 17, 2025, 9:12pm

Mein Ziel hier war es etwas mehr über die Ursachen der beschriebenen Störung herauszufinden. Den Fehler konnte ich selber beheben und dass die Ursache sich irgendwo zwischen btrfs, SSD, OpenSUSE und mir abspielt ist mir auch soweit klar. Entsprechend hätte mich interessiert wie ich z.B. einen SSD-Fehler ausschließen kann, oder ein Fehler des Filesystems, oder, oder, oder.

Es ist logisch anzunehmen, dass ich bei meiner weiteren Recherche an Grenzen gestoßen bin, die mich dazu veranlasst haben hier zielgerichteter nach Informationen zu fragen. Hingegen ist es unlogisch anzunehmen, dass ich zu faul war, um selbst im Internet oder in diesem Forum zu suchen.

Ich bin mir auch nicht zu fein, etwas über die entsprechenden Themen zu lernen und warte hier auch nicht feist darauf, dass mir jemand den Hof kehrt.

Gute Lehre ist besser als “Schmerz für jeden”, so dass es insgesamt effizienter gewesen wäre hier wohlwollend in die richtige Richtung gestoßen zu werden (oder klar gesagt zu bekommen, dass man das so nicht feststellen wird können).

Verzeih mir also bitte vielmals, falls ich dich missverstehe. Dennoch habe ich das Gefühl, dass du mich ein wenig düpierst.

Hätte ich beim “Googlen” Informationen gefunden, die das beschriebene Verhalten für mich befriedigend erklären, oder die ich diesbezüglich ohne Erklärung verstehen kann, dann hätte ich mich nicht an dieses Forum gewandt.

Dann sagst du mir folgendes:

um mir dann jenes zu sagen:

Wie gesagt, du hast mir mehrfach geantwortet. Dafür danke! Gut möglich, dass ich deine Antworten fehlinterpretiere. Es fiel mir allerdings etwas schwer, um ehrlich zu sein.

Trotzdem vielen Dank für deine Antworten. Ich werde vermutlich eine Neuinstallation durchführen und deine Minimalpartitionierung übernehmen. Dann darauf hoffen, dass die beschriebene Korrelation mit der Benutzung von OpenSUSE keine Kausalität bedeutet.

thommes · July 24, 2025, 12:28pm

Zur Dokumentation:

Meine Probleme sind behoben, seitdem ich meine SSD komplett formatiert und OpenSUSE neuinstalliert habe. Leider kann ich über die Gründe nur spekulieren, an der SSD scheint es eben nicht zu liegen.

Eventuell besteht ein Zusammenhang mit der Tatsache, dass es zuvor noch eine alte Windows-Bootpartition gab.

karlmistelberger · July 24, 2025, 1:26pm

Das ist einerseits erfreulich. Anderseits können sie jederzeit wieder auftauchen.

Meinen geht immer, ist aber selten zweckmäßig.

@alle:

thommes · July 24, 2025, 3:38pm

Ah nochmal aus der Reserve gelockt, lieber Karl

Ja, da stimme ich dir zu; Da haben wir hier dann offenbar etwas gemeinsam, denn nachvollziehbare Gründe, warum die SSD jetzt fehlerhaft sein soll, konnten wir jetzt nicht aufdecken. Darüberhinaus stelle ich erstmal nur eine Arbeitshypothese, basierend auf den spärlichen Fakten auf. Das ist erstmal alles. Der Ursache versuche ich mich über ein Ausschlussverfahren zu nähern:

Konfiguration	Beobachtung	Zeitraum
Ubuntu/ext4 + alte Windows-Part.	Problemlos	circa 1 Jahr
OpenSuse/Btrfs + alte Windows-Part.	Problembehaftet	mehrere Monate
OpenSuse/Btrfs - alte Windows-Part.	Problemlos	einige Tage

Da aber mein Leben nicht davon abhängt und das Finden der realen Ursache womöglich sehr zeitintensiv ist, da ich kein Experte für Dateisysteme und Festplatten bin (und deswegen ja auch noch Hilfe gefragt hatte), kann ich unter Umständen auch damit leben, dass ich in diesem Fall zu keiner finalen Erklärung kommen werde.

Ist zwar durchaus unbefriedigend, aber so ist das manchmal.

Viele Grüße nach Erlangen und danke für einen würzigen Austausch. I love it.

Sauerrahm · July 30, 2025, 9:07am

Hi Thomas,

nur zur Info, ich finde mich in Deinen Schilderungen wieder und hatte im Zeitraum ~01.7. (oder etwas früher) bis ~20.07. genau die gleichen Beschwerden (mehrfach, entweder eingefroren oder nicht mehr aus dem Schlaf erwacht), welche aber seit ca. ~10 Tagen nicht mehr aufgetreten sind.

Meine alte Windows-Partition (ganz vorne, ~15 MB; “Microsoft reserved partition” ) ist aber noch da, weil ich bisher gescheut habe, daran zu drehen oder neu aufzusetzen.

Schönen Tag noch.

thommes · July 31, 2025, 9:46am

Hey,

danke dir für die Information! Das macht es natürlich mysteriöser; Immerhin scheinen wir jetzt beide keine Probleme mehr zu haben.

Problem gelöst, Erkenntnisgewinn leider nicht so groß

VG

GrandDixence2 · August 6, 2025, 9:12pm

Oder sollte ich davon ausgehen, dass die SSD eine Schluckauf hatte und die Wahrscheinlichkeit gering ist, dass dies wieder passiert? Oder eben hoch, weil “broken”?

Zu einer ordentlichen Gerätewartung gehört die regelmässige Kontrolle der SSD-/Festplatten-Gesundheit per S.M.A.R.T.:

# zypper install smartmontools

#!/bin/bash
############################################
# /usr/local/sbin/ssdKontrolle.sh
# GrandDixence, 22.03.2015
#
# S.M.A.R.T-Werte der Festplatte
# kontrollieren.
#
#############################################

festplatte="/dev/sda"
echo " "
echo "Langer Selbsttest der Festplatte starten (Full/Long Scan)"
echo "------------------------------------------------------------------------------"
/usr/sbin/smartctl -t long ${festplatte}
echo " "
echo "Allgemeine Angaben zur Festplatte"
echo "------------------------------------------------------------------------------"
/usr/sbin/smartctl -i ${festplatte}
echo " "
echo "Gesundheitszustand der Festplatte"
echo "------------------------------------------------------------------------------"
/usr/sbin/smartctl -H -l error ${festplatte}
echo " "
echo "S.M.A.R.T.-Werte der Festplatte"
echo "------------------------------------------------------------------------------"
/usr/sbin/smartctl -A ${festplatte}
echo " "
echo "Kontrolle des S.M.A.R.T.-Wert Media Wearout Indicator"
echo "------------------------------------------------------------------------------"
echo "Der S.M.A.R.T.-Wert Media Wearout Indicator (Intel: E9/233)"
echo "einer neuen SSD ist 0. Steigt der Rohwert (Raw) über 10, sollte die SSD"
echo "ausgetauscht werden."
echo " "
MediaWearoutIndicator=`/usr/sbin/smartctl -A ${festplatte} | /usr/bin/grep "^233"| /usr/bin/awk '{print $10}'`
echo "Der aktuelle Wert ist (Intel)  : " ${MediaWearoutIndicator}
echo " "
echo "------------------------------------------------------------------------------"
echo " "
echo "Kontrolle des S.M.A.R.T.-Wert Media Wearout Indicator"
echo "------------------------------------------------------------------------------"
echo "Der normalisierte S.M.A.R.T.-Wert Media Wearout Indicator (Samsung: 177)"
echo "einer neuen SSD ist 100. Sinkt der normalisierte Wert (Value) unter 90,"
echo "sollte die SSD ausgetauscht werden."
echo " "
MediaWearoutIndicator=`/usr/sbin/smartctl -A ${festplatte} | /usr/bin/grep "^177"| /usr/bin/awk '{print $4}'`
echo "Der aktuelle Wert ist (Samsung): " ${MediaWearoutIndicator}
echo " "
echo "------------------------------------------------------------------------------"
echo " "

Mit ssdResultate.sh die Resultate vom langen Selbsttest kontrollieren. Auf die Angabe der Betriebsstunden achten!

#!/bin/bash
############################################
# /usr/local/sbin/ssdResultate.sh
# GrandDixence, 29.09.2012
#
# S.M.A.R.T-Werte der Festplatte
# kontrollieren.
#
#############################################

festplatte="/dev/sda"
echo " "
echo "Allgemeine Angaben zur Festplatte"
echo "------------------------------------------------------------------------------"
/usr/sbin/smartctl -i ${festplatte}
echo " "
echo "S.M.A.R.T.-Werte der Festplatte"
echo "------------------------------------------------------------------------------"
/usr/sbin/smartctl -A ${festplatte}
echo " "
echo "Resultate des S.M.A.R.T.-Selbsttest anzeigen"
echo "------------------------------------------------------------------------------"
/usr/sbin/smartctl -l selftest ${festplatte}
echo " "

TRIM-Unterstützung mit einem händischen TRIM-Befehl kontrollieren:

# fstrim --all --verbose

thommes · August 7, 2025, 6:45pm

Danke dir. Sehr hilfreich!

=== START OF SMART DATA SECTION ===
SMART/Health Information (NVMe Log 0x02, NSID 0xffffffff)


Critical Warning:	0x00
Available Spare:	100%
Available Spare Threshold:	10%
Percentage Used:	0%
Data Units Read:	13.424.493 [6,87 TB]
Data Units Written:	11.199.475 [5,73 TB]

Self-test Log (NVMe Log 0x06, NSID 0xffffffff)
Self-test status: No self-test in progress
Num  Test_Description  Status                       Power_on_Hours  Failing_LBA  NSID Seg SCT Code
 0   Extended          Completed without error                2177            -     -   -   -    -
 1   Extended          Completed without error                2177            -     -   -   -    -
 2   Short             Completed without error                2174            -     -   -   -    -
 3   Short             Completed without error                2172            -     -   -   -    -
 4   Extended          Completed without error                2170            -     -   -   -    -
 5   Short             Completed without error                2170            -     -   -   -    -
 6   Short             Completed without error                2170            -     -   -   -    -
 7   Short             Completed without error                2168            -     -   -   -    -
 8   Short             Completed without error                2166            -     -   -   -    -
 9   Short             Completed without error                2162            -     -   -   -    -
10   Short             Completed without error                2158            -     -   -   -    -
11   Short             Completed without error                2155            -     -   -   -    -
12   Short             Completed without error                2153            -     -   -   -    -
13   Short             Completed without error                2150            -     -   -   -    -
14   Short             Completed without error                2146            -     -   -   -    -
15   Short             Completed without error                2143            -     -   -   -    -
16   Short             Completed without error                2141            -     -   -   -    -
17   Short             Completed without error                2139            -     -   -   -    -
18   Short             Completed without error                2136            -     -   -   -    -
19   Short             Completed without error                2133            -     -   -   -    -

Meine SSD sieht erstmal noch recht iO aus, soweit ich das sagen kann.

thommes · August 10, 2025, 7:55pm

FYI:
Schien zuvorderst ein Kernelbug bzgl Btrfs Log-tree replay zu sein:

system · August 17, 2025, 7:55pm

This topic was automatically closed 7 days after the last reply. New replies are no longer allowed.