• Willkommen im Linux Club - dem deutschsprachigen Supportforum für GNU/Linux. Registriere dich kostenlos, um alle Inhalte zu sehen und Fragen zu stellen.

OS Tumbleweed readonly

hallo zusammen, :)

ich verwende ein Tumbleweed, welches nach einem Upgrade im readonly ist.
Im Usermode treten keine Probleme auf.
Administrative Tätigkeiten lassen sich nicht ausführen und werden mit einer Fehlermeldung quittiert.
Werden diese abgenickt stürzt das OS letzten endes ab. Es ist danach auch kein "shutdoun" mehr möglich.
Nach dem besagten Upgrade ist nach einem restart das OS abgestürzt.
Danach habe ich das OS im safty mode gestartet;
beim anschliessenden shutdown wieder abgestürzt und war nur mit einem powerr off zu beenden.

Danach war das OS im readonly mode.

Nachfolgend eine kleine Diagnose.

Code:
sudo fdisk -l
[sudo] Passwort für root:
Festplatte /dev/sda: 465,76 GiB, 500107862016 Bytes, 976773168 Sektoren
Festplattenmodell: Samsung SSD 870
Einheiten: Sektoren von 1 * 512 = 512 Bytes
Sektorgröße (logisch/physikalisch): 512 Bytes / 512 Bytes
E/A-Größe (minimal/optimal): 512 Bytes / 512 Bytes
Festplattenbezeichnungstyp: gpt
Festplattenbezeichner: 4EC81B0D-6A4F-4473-A56B-925628F99999

Gerät         Anfang      Ende  Sektoren  Größe Typ
/dev/sda1       2048     18431     16384     8M BIOS boot
/dev/sda2      18432 167790591 167772160    80G Linux-Dateisystem
/dev/sda3  167790592 167856127     65536    32M Linux Swap
/dev/sda4  167856128 482428927 314572800   150G Linux-Dateisystem
/dev/sda5  482428928 976769023 494340096 235,7G Linux-Dateisystem


Festplatte /dev/sdb: 232,89 GiB, 250059350016 Bytes, 488397168 Sektoren
Festplattenmodell: Samsung SSD 860
Einheiten: Sektoren von 1 * 512 = 512 Bytes
Sektorgröße (logisch/physikalisch): 512 Bytes / 512 Bytes
E/A-Größe (minimal/optimal): 512 Bytes / 512 Bytes
Festplattenbezeichnungstyp: gpt
Festplattenbezeichner: 52B0ED00-4D14-E04E-B7B2-E6F18C9F2C1E

Gerät         Anfang      Ende  Sektoren Größe Typ
/dev/sdb1       2048   1026047   1024000  500M Microsoft Basisdaten
/dev/sdb2    1026048 168798207 167772160   80G Linux-Dateisystem
/dev/sdb3  168798208 454010879 285212672  136G Linux-Dateisystem
/dev/sdb4  454010880 487565311  33554432   16G Linux Swap
Die GPT-Sicherungstabelle befindet sich nicht am Ende des Gerätes.

Es handel um /dev/sdb

sudo btrfs check /dev/sdb2 | tee logbtrfs_sdb2-25122024-1.txt
[1/7] checking root items
[2/7] checking extents
parent transid verify failed on 22916120576 wanted 141999 found 142575
parent transid verify failed on 22916120576 wanted 141999 found 142575
parent transid verify failed on 22916120576 wanted 141999 found 142575
Ignoring transid failure

........

Code:
sudo btrfs check /dev/sdb2 | tee logbtrfs_sdb2-25122024-1.txt
[1/7] checking root items
[2/7] checking extents
parent transid verify failed on 22916120576 wanted 141999 found 142575
parent transid verify failed on 22916120576 wanted 141999 found 142575
parent transid verify failed on 22916120576 wanted 141999 found 142575
Ignoring transid failure

........

ERROR: errors found in fs roots
Opening filesystem to check...
Checking filesystem on /dev/sdb2
UUID: d303d287-3af6-4345-ab13-f9ce6d26c1c7
found 48430538752 bytes used, error(s) found
total csum bytes: 43444464
total tree bytes: 2003419136
total fs tree bytes: 1874329600
total extent tree bytes: 70434816
btree space waste bytes: 520274852
file data blocks allocated: 121249390592
 referenced 120412176384

Lässt sich hier noch was retten ?
Daten habe keine verloren.
Diese waren auf /dev/sdb3 und sind gesichert.

viele Grüsse
bayernherz :thumbs:
 
hallo zusammen,

nachstehend noch die Version meines Tumbleweed

Betriebssystem: openSUSE Tumbleweed 20240823
KDE-Plasma-Version: 6.1.4
KDE-Frameworks-Version: 6.5.0
Qt-Version: 6.7.2
Kernel-Version: 6.10.5-1-default (64-bit)
Grafik-Plattform: X11
Prozessoren: 4 × Intel® Core™ i5-3570 CPU @ 3.40GHz
Speicher: 15,3 GiB Arbeitsspeicher
Grafikprozessor: Mesa Intel® HD Graphics 2500

Ich würde mich über einen Tipp von Euch sehr freuen, wie man den
readonly Zustand des OS beheben kann. :)

viele grüsse
bayernherz :thumbs:
 
hallo zusammen,


btrfs-restore btrfsPartition sicherungsOrdner

Daten habe ich keine verloren, da eigene home partionen mit ext4 Dateisystem, welches ich bereits gesichert habe.
Fazit: Wir brauchen keine Rücksicht auf Datenverlust nehmen.

Ich bräuchte Hilfe, wie ich das OS aus dem readonly herausbekomme.
Wie meine obenstehende Diagnose bereits zeigt, ist das Dateisystem btrfs auch beschädigt, da ich nach einem Upgrade das eingefrorenen Betriebssystem nur noch mit dem "Netzschalter aus" beenden konnte.

Da ich mit dem btrfs Dateisystem ein newby bin, würde ich mich über weitere Tipps sehr freuen.
Anderenfalls kann ich nur nach trail and error vorgehen. :irre:

viele grüsse
bayernherz :thumbs:
 

susejunky

Moderator
Teammitglied
Hallo @bayernherz ,

ich habe zwar btrfs auf einem meiner Systeme im Einsatz, aber ich musste es noch nie reparieren. Daher kann ich Dich nur auf die openSUSE SDB zu btrfs verweisen.

Im englischsprachigen openSUSE Forum solltest Du einige Beiträge zu dem Thema finden; z.B. diesen hier.

Viele Grüße und viel Erfolg

susejunky
 
hallo zusammen, 😀

vielen Dank für Eure zahlreiche Unterstützung.
Ich habe auch sehr intensiev bezüglich "/ readonly root Filesystem" gegoogle't.
Das Thema ist sehr komplex und Zeitintensiev.
Ein Fehler im root Filesystem führt nach meinen Nachforschungen zu einem readonly des root Filesystems.
Fehler im root-Filesystem können durch ein fehlerhaftes shutdow (bedingt durch einfrieren des OS) oder durch Power off mittels Hauptschalter auftreten.

Ich frage mich immer wieder, auch weil ich keinen Datenverlust habe und auch Linux Ersatzsysteme, ob sich die mühsame und nicht unbedingt erfolgversprechende Reparatur des btrfs Filesystems überhaupt lohnt ?
Wäre es nicht sinnvoller die Zeit dafür zu nutzen und ein neues Tumbleweed aufzusetzen?

viele grüsse
bayernherz :thumbs:
 

susejunky

Moderator
Teammitglied
Hallo @bayernherz ,

Ich frage mich immer wieder, auch weil ich keinen Datenverlust habe und auch Linux Ersatzsysteme, ob sich die mühsame und nicht unbedingt erfolgversprechende Reparatur des btrfs Filesystems überhaupt lohnt ?
die Frage ist, wie man "lohnen" definiert.

Die Neu-Installation ist wahrscheinlich mit weniger Aufwand und höheren Erfolgsaussichten verbunden als die Reparatur.

Andererseits befindest Du Dich aktuell in einer sehr komfortablen Situation (... kein drohender Datenverlust ... Linux Ersatzsysteme vorhanden ...). Das wäre natürlich ideal, um sich "gefahrlos" mit btrfs-Reparaturmöglichkeiten vertraut zu machen (was insbesondere dann sinnvoll wäre, wenn Du weiterhin Systeme mit btrfs betreiben willst).

Ich hoffe, dass mir eine Situation wie die Deine erspart bleibt. Aber sollte sie denn doch einmal eintreten, so würde ich sehr wahrscheinlich - rein aus Interesse - einen Reparaturversuch wagen. Allerdings würde ich danach, selbst bei "Erfolg", das betroffene System neu auf ext4 aufsetzen. Für meine Anwendungsfälle bietet mir btrfs keine nennenswerte Vorteile.

Viele Grüße

susejunky
 
Oben