eOS failed to mount /sysroot nach hartem reset

[cbgilb]

Hallo zusammen,
mein eOS läuft schon seit einer Weile holprig. Immer mal wieder stürzen Fenster ab. Mal aber auch der ganze Grafiktreiber mit Blackscreen (sound läuft manchmal ungehindert weiter). Meistens wenn ich im Firefox oder mpv irgendwelche Videos/Streams schaue. Ist aber auch schon bei lokalen Dateien vorgekommen. Dazu kommt seit 1 Woche dass meine Maus in unregelmäßigen Abständen für 1-2 Sekunden hängt. Mal merk ich gar nichts, mal mehrmals in 10 Minuten.
Bis jetzt hab ich das immer auf den "kwin" Prozess geschoben der sich auch nur gelegentlich mit einem Restart in den Notifications meldet. So sehr ich KDE Plasma mag, irgendwas läuft da nicht rund.

Den momentanen dracut "Fehler" habe ich auch, aber das sollte laut den eOS devs keine Rolle spielen für User die nur den rolling Arch Kernel benutzen und nur btrfs Partitionen haben. Alle Pakete sind vor ein paar Tagen noch problemlos geupdated worden. Hardware ist ein 7800X3D, B650 Gaming AX X V2, Radeon 7800XT, 32GB Patriot RAM auf EXPO1, 2TB Lexar NM790, quasi der hiesige Gaming Rechner vom letzten Jahr.

Der Crash kam gestern Abend. Wieder nur Stream geschaut in "mpv", dann Bild eingefroren. Keine Reaktion auf Eingaben oder keine sichtbare jedenfalls. Dann Blackscreen aber Sound ging weiter. Nach 30 Sekunden ohne Kontrolle habe ich Reset gedrückt.

Dann kam beim Booten der Fehler unten. Failed to mount /sysroot.
Beim Versuch über GRUB die Fallback Option zu booten ist es exakt der selbe Fehler.

Ich habe hier schon einen neuen CachyOS live stick zur Hand, aber wenn möglich würde ich erst versuchen das zu fixen. Also stellen sich mir 2 Fragen:
1) Wieso ist das bei diesem Reset passiert und nicht bei den anderen Malen in den letzten Monaten?
2) Wie bekomme ich über die emergency shell oder den livestick die /sysroot Partition wieder gemounted?

Habe mich schon durch die arch/eos Foren und Reddit gebuddelt mit ganz ähnlichen Fehlern aber leider ohne Erfolg.
Den Livestick hab ich auch schon gebooted, aber konnte die SSD in Dolphin auch nicht mounten.
Sorry für die Reflektionen im Bild.

 

[fixedwater]

Den Livestick hab ich auch schon gebooted, aber konnte die SSD in Dolphin auch nicht mounten.

Hört sich für mich eigentlich nach einem Hardwareproblem mit der SSD an. Die anderen "Symptome" ehrlich gesagt auch...

 

[JumpingCat]

Wie sind die smart Werte?

Kaputt gehen kann ein btrfs aus, es ist nur mehr resilent gegen Crashes.

 

[cbgilb]

Im UEFI gab es eine SSD Test Funktion, da scheint alles in Ordnung zu sein. Mal gucken wie ich mit dem Livestick an die SMART Werte komme. Mit den einfachsten Recovery Tools sollte eigentlich jeder LiveStick ausgestattet werden

 

[cbgilb]

Ok, ich dachte man koennte keine Pakete in der Liveumgebung hinyuf[gen aber war doch einfacher als gedacht.

smartctl sagt nun das hier

=== START OF INFORMATION SECTION ===
Model Number: Lexar SSD NM790 2TB
Serial Number: PCN513R000041P220J
Firmware Version: 18950
PCI Vendor/Subsystem ID: 0x1d97
IEEE OUI Identifier: 0xcaf25b
Total NVM Capacity: 2,048,408,248,320 [2.04 TB]
Unallocated NVM Capacity: 0
Controller ID: 0
NVMe Version: 2.0
Number of Namespaces: 1
Namespace 1 Size/Capacity: 2,048,408,248,320 [2.04 TB]
Namespace 1 Formatted LBA Size: 512
Namespace 1 IEEE EUI-64: caf25b 035e000029
Local Time is: Sun Aug 10 19:49:00 2025 UTC
Firmware Updates (0x14): 2 Slots, no Reset required
Optional Admin Commands (0x0017): Security Format Frmw_DL Self_Test
Optional NVM Commands (0x005f): Comp Wr_Unc DS_Mngmt Wr_Zero Sav/Sel_Feat Timestmp
Log Page Attributes (0x0e): Cmd_Eff_Lg Ext_Get_Lg Telmtry_Lg
Maximum Data Transfer Size: 128 Pages
Warning Comp. Temp. Threshold: 90 Celsius
Critical Comp. Temp. Threshold: 95 Celsius

Supported Power States
St Op Max Active Idle RL RT WL WT Ent_Lat Ex_Lat
0 + 6.50W - - 0 0 0 0 0 0
1 + 5.80W - - 1 1 1 1 0 0
2 + 3.60W - - 2 2 2 2 0 0
3 - 0.0500W - - 3 3 3 3 5000 10000
4 - 0.0025W - - 4 4 4 4 8000 45000

Supported LBA Sizes (NSID 0x1)
Id Fmt Data Metadt Rel_Perf
0 + 512 0 0

=== START OF SMART DATA SECTION ===
SMART overall-health self-assessment test result: PASSED

SMART/Health Information (NVMe Log 0x02, NSID 0xffffffff)
Critical Warning: 0x00
Temperature: 35 Celsius
Available Spare: 100%
Available Spare Threshold: 10%
Percentage Used: 0%
Data Units Read: 18,105,993 [9.27 TB]
Data Units Written: 10,440,109 [5.34 TB]
Host Read Commands: 110,135,823
Host Write Commands: 223,857,053
Controller Busy Time: 137
Power Cycles: 1,156
Power On Hours: 3,959
Unsafe Shutdowns: 19
Media and Data Integrity Errors: 0
Error Information Log Entries: 0
Warning Comp. Temperature Time: 0
Critical Comp. Temperature Time: 0
Temperature Sensor 1: 35 Celsius
Temperature Sensor 2: 36 Celsius

Error Information (NVMe Log 0x01, 16 of 64 entries)
No Errors Logged

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 Short Completed without error 3949 - - - - -
1 Extended Completed without error 3949 - - - - -


Gefuehlt waren es im letzten Jahr aber mehr als 19 unsafe shutdowns.
Und auch hier live stottert die Maus gelegentlich, vielleicht ist die nach 8 Jahren auch hinueber, da braucht ich aber keine Hilfe

Und die Dolphin Fehlermeldung beim mounten ist "cant read superblock on /dev/nvmen1p2"

Noch ein edit:
[liveuser@CachyOS ~]$ sudo btrfs check /dev/nvme0n1p2
Opening filesystem to check...
Checking filesystem on /dev/nvme0n1p2
UUID: dadc5ad6-fbb5-45ae-9c29-96f94b578395
[1/8] checking log
[2/8] checking root items
[3/8] checking extents
[4/8] checking free space tree
[5/8] checking fs roots
[6/8] checking only csums items (without verifying data)
[7/8] checking root refs
[8/8] checking quota groups skipped (not enabled on this FS)
found 332859097088 bytes used, no error found
total csum bytes: 321551372
total tree bytes: 1149665280
total fs tree bytes: 652886016
total extent tree bytes: 124698624
btree space waste bytes: 185148705
file data blocks allocated: 388839198720
referenced 406956593152
[liveuser@CachyOS ~]$

 

[Uridium]

Mounte manuell und poste die /var/log/dmesg, falls möglich.

Ramtest machen.

 

[foofoobar]

Dann kam beim Booten der Fehler unten. Failed to mount /sysroot.
Beim Versuch über GRUB die Fallback Option zu booten ist es exakt der selbe Fehler.

Dein "/" hat nen Schalg weg. Mach mal ein fsck (oder das entsprechende btrfs-Equvivalent) darauf.

1) Wieso ist das bei diesem Reset passiert und nicht bei den anderen Malen in den letzten Monaten?

Irgendwas war anders als beim letzten Mal.

 

[cbgilb]

Ok die Antwort habe ich wohl verdient, passt zum Avatar .
Besser: Welche normale Schreib- und Lesetätigkeit kann einem so das Dateisystem zerschießen. Oder ist es bei vielen Resets quasi nur eine Frage der Zeit bis sowas passiert?

Ich fasse mal zusammen: alle Hardwaretests (Smartwerte, Memtest) scheinen keinen Fehler zu zeigen.
mvme0n1p1 (EFI partition) wird gebooted und ended in der emergency shell weil...
mve0n1p2 (eOS partition) wird nicht gebooted wegen btrfs error (failed to recover log tree)
Manuelles mounten der eOS partition im live system is auch nicht möglich (cant read superblock)

Über den Fehler bin ich jetzt in einem Manjaro Forum über diesen Rat gestolpert.

You can recover the superblock by another copy on the same partition:
sudo btrfs rescue super-recover /dev/...
https://btrfs.readthedocs.io/en/latest/btrfs-rescue.html

Bevor ich das Versuche, würde ich mich aber erst noch ein wenig über btrfs schlau machen.
Oder kann einer von euch sagen dass das easy läuft?

 

[foofoobar]

Ok die Antwort habe ich wohl verdient, passt zum Avatar .
Besser: Welche normale Schreib- und Lesetätigkeit kann einem so das Dateisystem zerschießen. Oder ist es bei vielen Resets quasi nur eine Frage der Zeit bis sowas passiert?

Normalerweise ist es ein Designgoal von Filesystemen mit journaling und insbesondere mit COW das so etwas nicht vorkommt. Dafür muss sich allerdings die Platten-HW an bestimmte Spielregeln halten die auch so definiert sind, aber Balken länger machen. PLP gibt es auch nicht aus Spaß.
Möglicherweise hat auch die Firmware der Platte ein Problem.
RAM-Fehler sind eine weitere Möglichkeit. (Vorsicht: Ich bin bekennender ECC-Nazi)

Ich fasse mal zusammen: alle Hardwaretests (Smartwerte, Memtest) scheinen keinen Fehler zu zeigen.
mvme0n1p1 (EFI partition) wird gebooted und ended in der emergency shell weil...
mve0n1p2 (eOS partition) wird nicht gebooted wegen btrfs error (failed to recover log tree)
Manuelles mounten der eOS partition im live system is auch nicht möglich (cant read superblock)

btrfs habe ich mir nie angeschaut, das wäre meine erste Maßnahme:
https://btrfs.readthedocs.io/en/latest/btrfs-check.html

By default, btrfs check will not modify the device but you can reaffirm thatby the option --readonly.

Also erstmal nur glotzen.

 

[cbgilb]

Ist da oben als letzter edit in einem Post. Alle 8 checks haben keinen Fehler aufgezeigt. :/

edit: ok die --backup option zeigt mehr

liveuser@CachyOS ~]$ sudo btrfs check --backup /dev/nvme0n1p2
Opening filesystem to check...
Checking filesystem on /dev/nvme0n1p2
UUID: dadc5ad6-fbb5-45ae-9c29-96f94b578395
[1/8] checking log
[2/8] checking root items
[3/8] checking extents
super bytes used 332859097088 mismatches actual used 332859027456
ERROR: errors found in extent allocation tree or chunk allocation
[4/8] checking free space tree
[5/8] checking fs roots
[6/8] checking only csums items (without verifying data)
[7/8] checking root refs
[8/8] checking quota groups skipped (not enabled on this FS)
found 332859027456 bytes used, error(s) found
total csum bytes: 321551304
total tree bytes: 1149665280
total fs tree bytes: 652886016
total extent tree bytes: 124698624
btree space waste bytes: 185148929
file data blocks allocated: 388839129088
 referenced 406956593152
[liveuser@CachyOS ~]$

Ergänzung (11. August 2025)

OK, nach eifrigem Studium würde ich es in folgender Reihenfolge versuchen

1) btrfs check --repair (scheint mir die catch all option zu sein)
2) btrfs check --init-extent-tree (hier weiß ich aber nicht was ich tue, ich sehe nur den error dort)
3) btrfs rescue super-recover (falls die ersten Versuche nichts bringen)

Oder lieber 2 und 3 tauschen?
Rescue hat auch noch die zero-log option, deutet der boot error darauf hin?
"This may fix a specificset of problem when the filesystem mount fails during log replay."

 

[Uridium]

Nochmal... manuell mounten und den Kernel Log posten. Poste deine Befehle exakt aus dem Terminal (nicht abschreiben, sondern copy&paste). Du hast weiter oben schon zu viele Syntaxfehler verursacht.

Du machst was falsch beim mounten oder Du hast das falsche Laufwerk geprüft. Das gilt es herauszufinden. Dazu benötigt es die exakte Ein- und Ausgabe.

 

[foofoobar]

Du machst was falsch beim mounten oder Du hast das falsche Laufwerk geprüft. Das gilt es herauszufinden. Dazu benötigt es die exakte Ein- und Ausgabe.

Es bleibt fast nur diese Richtung.

 

[cbgilb]

Ok, ich glaube ihr wollt dass ich das alles in der Konsole mache hm?? Na dann, roast my syntax

[liveuser@CachyOS ~]$ sudo mount -v -o ro,rescue=usebackuproot /dev/nvme0n1p2 /mnt/eos

mount: /mnt/eos: can't read superblock on /dev/nvme0n1p2.
       dmesg(1) may have more information after failed mount system call.

danach sudo dmesg
hier die problematischen zeilen

[ 8927.744708] BTRFS: device label endeavouros devid 1 transid 386453 /dev/nvme0n1p2 (259:2) scanned by mount (17067)

[ 8927.745262] BTRFS info (device nvme0n1p2): first mount of filesystem dadc5ad6-fbb5-45ae-9c29-96f94b578395
[ 8927.745276] BTRFS info (device nvme0n1p2): using crc32c (crc32c-x86) checksum algorithm
[ 8927.745280] BTRFS info (device nvme0n1p2): using free-space-tree
[ 8927.773056] BTRFS info (device nvme0n1p2): start tree-log replay
[ 8927.827788] BTRFS: error (device nvme0n1p2) in btrfs_replay_log:2100: errno=-5 IO failure (Failed to recover log tree)
[ 8927.842477] ------------[ cut here ]------------
[ 8927.842479] WARNING: CPU: 2 PID: 17067 at fs/btrfs/block-rsv.c:452 btrfs_release_global_block_rsv+0x1fa/0x370
[ 8927.842485] Modules linked in: vfat fat rfcomm snd_seq_dummy snd_hrtimer snd_seq snd_seq_device qrtr cmac algif_hash algif_skcipher af_alg bnep amd_atl intel_rapl_msr intel_rapl_common kvm_amd kvm snd_hda_codec_realtek irqbypass btusb snd_hda_codec_generic btrtl btintel btbcm snd_hda
_scodec_component snd_hda_codec_hdmi polyval_clmulni btmtk bluetooth mt7921e snd_hda_intel polyval_generic mt7921_common mt792x_lib snd_intel_dspcfg mt76_connac_lib snd_intel_sdw_acpi mousedev joydev mt76 snd_hda_codec ghash_clmulni_intel snd_hda_core snd_hwdep mac80211 snd_pcm snd_time
r snd sha1_ssse3 i2c_piix4 libarc4 soundcore cfg80211 rfkill k10temp rapl wmi_bmof ccp gigabyte_wmi i2c_smbus mac_hid zfs(POE) spl(OE) pkcs8_key_parser nouveau mxm_wmi drm_gpuvm ntsync i2c_dev crypto_user dm_mod nfnetlink lz4 zram 842_decompress 842_compress lz4hc_compress lz4_compress
ip_tables x_tables overlay squashfs loop isofs cdrom uas usb_storage amdgpu amdxcp gpu_sched drm_panel_backlight_quirks drm_buddy drm_exec sha512_ssse3 drm_suballoc_helper
[ 8927.842545]  sha256_ssse3 drm_ttm_helper r8169 ttm aesni_intel nvme realtek crypto_simd i2c_algo_bit cryptd mdio_devres nvme_core drm_display_helper libphy nvme_keyring cec nvme_auth video wmi
[ 8927.842560] CPU: 2 UID: 0 PID: 17067 Comm: mount Tainted: P           OE       6.15.5-1-cachyos #1 PREEMPT(full)  76cc5d3e8db567abcd1651f7c8c095d4318d3355
[ 8927.842563] Tainted: [P]=PROPRIETARY_MODULE, [O]=OOT_MODULE, [E]=UNSIGNED_MODULE
[ 8927.842564] Hardware name: Gigabyte Technology Co., Ltd. B650 GAMING X AX V2/B650 GAMING X AX V2, BIOS F36 07/31/2025
[ 8927.842565] RIP: 0010:btrfs_release_global_block_rsv+0x1fa/0x370
[ 8927.842567] Code: 01 00 00 00 0f 84 c9 fe ff ff 0f 0b 48 83 bb 48 01 00 00 00 0f 84 c7 fe ff ff 0f 0b 48 83 bb 70 01 00 00 00 0f 84 c5 fe ff ff <0f> 0b 48 83 bb 78 01 00 00 00 0f 84 c3 fe ff ff 0f 0b 48 83 bb a8
[ 8927.842569] RSP: 0018:ffffcfc1ce84bb58 EFLAGS: 00010286
[ 8927.842571] RAX: ffff8d83145fd4b0 RBX: ffff8d829d720000 RCX: 0000000000200001
[ 8927.842572] RDX: 0000000000000001 RSI: ffff8d83145fd400 RDI: ffff8d83145fd408
[ 8927.842573] RBP: 000000001d99c000 R08: 0000000000000001 R09: ffffffffa34d1000
[ 8927.842574] R10: ffffffffe2664000 R11: ffff8d83145fc000 R12: ffff8d83145fd400
[ 8927.842575] R13: ffff8d829d720098 R14: 0000000000000000 R15: dead000000000100
[ 8927.842576] FS:  00007f29fa8ccb80(0000) GS:ffff8d87f875b000(0000) knlGS:0000000000000000
[ 8927.842578] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 8927.842579] CR2: 000055583f1f50e8 CR3: 0000000318783000 CR4: 0000000000f50ef0
[ 8927.842580] PKRU: 55555554
[ 8927.842581] Call Trace:
[ 8927.842582]  <TASK>
[ 8927.842584]  btrfs_free_block_groups+0x454/0x530
[ 8927.842587]  open_ctree+0x81c/0x141d
[ 8927.842593]  btrfs_get_tree.cold+0xb/0x132
[ 8927.842595]  ? vfs_dup_fs_context+0x2f/0x1e0
[ 8927.842598]  vfs_get_tree+0x26/0xd0
[ 8927.842601]  ? srso_alias_return_thunk+0x5/0xfbef5
[ 8927.842603]  fc_mount+0x12/0x40
[ 8927.842606]  btrfs_get_tree+0x286/0x660
[ 8927.842609]  ? srso_alias_return_thunk+0x5/0xfbef5
[ 8927.842610]  ? __kmalloc_node_track_caller_noprof+0x257/0x510
[ 8927.842613]  vfs_get_tree+0x26/0xd0
[ 8927.842615]  ? srso_alias_return_thunk+0x5/0xfbef5
[ 8927.842617]  __x64_sys_fsconfig+0x4c1/0x700
[ 8927.842620]  do_syscall_64+0x7b/0x810
[ 8927.842623]  ? srso_alias_return_thunk+0x5/0xfbef5
[ 8927.842625]  ? syscall_exit_to_user_mode_prepare+0x17e/0x1f0
[ 8927.842627]  ? srso_alias_return_thunk+0x5/0xfbef5
[ 8927.842629]  ? syscall_exit_to_user_mode+0x10/0x210
[ 8927.842631]  ? srso_alias_return_thunk+0x5/0xfbef5
[ 8927.842633]  ? do_syscall_64+0x87/0x810
[ 8927.842634]  ? srso_alias_return_thunk+0x5/0xfbef5
[ 8927.842636]  ? syscall_exit_to_user_mode+0x10/0x210
[ 8927.842638]  ? srso_alias_return_thunk+0x5/0xfbef5
[ 8927.842639]  ? do_syscall_64+0x87/0x810
[ 8927.842641]  ? srso_alias_return_thunk+0x5/0xfbef5
[ 8927.842642]  ? syscall_exit_to_user_mode_prepare+0x17e/0x1f0
[ 8927.842644]  ? srso_alias_return_thunk+0x5/0xfbef5
[ 8927.842645]  ? syscall_exit_to_user_mode+0x10/0x210
[ 8927.842647]  ? srso_alias_return_thunk+0x5/0xfbef5
[ 8927.842648]  ? do_syscall_64+0x87/0x810
[ 8927.842650]  ? exc_page_fault+0x81/0x190
[ 8927.842652]  entry_SYSCALL_64_after_hwframe+0x76/0x7e
[ 8927.842653] RIP: 0033:0x7f29faa21efe
[ 8927.842665] Code: 73 01 c3 48 8b 0d 12 be 0c 00 f7 d8 64 89 01 48 83 c8 ff c3 0f 1f 84 00 00 00 00 00 f3 0f 1e fa 49 89 ca b8 af 01 00 00 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d e2 bd 0c 00 f7 d8 64 89 01 48
[ 8927.842666] RSP: 002b:00007ffdd1b7e778 EFLAGS: 00000246 ORIG_RAX: 00000000000001af
[ 8927.842668] RAX: ffffffffffffffda RBX: 0000560d31407500 RCX: 00007f29faa21efe
[ 8927.842669] RDX: 0000000000000000 RSI: 0000000000000006 RDI: 0000000000000003
[ 8927.842670] RBP: 00007ffdd1b7e7a0 R08: 0000000000000000 R09: 0000000000000000
[ 8927.842671] R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000
[ 8927.842672] R13: 0000560d314091e0 R14: 00007f29fab4b980 R15: 0000560d31409518
[ 8927.842675]  </TASK>
[ 8927.842676] ---[ end trace 0000000000000000 ]---
[ 8927.842759] BTRFS error (device nvme0n1p2 state E): open_ctree failed: -5

Mit mount -o rescue=usebackuproot,nologreplay konnte ich dann doch zugreifen und ein paar Dateien sichern. Eigentlich koennte ich jetzt CachyOS installieren, aber reparieren ist interessanter. Besonders wenn es nur ein kleiner Befehl ist. Bin mir trotz Dokumentation aber noch nicht sicher was als naechstes ansteht. Die zero-log Option schliesse ich nach meiner Interpretation jetzt jedenfalls aus.

Ergänzung (13. August 2025)

Ich habe auf der Platte auch noch eine system.journal Datei gefunden von dem Crashzeitpunkt. Ist die von Interesse? Ich weiss aber noch nicht wie die zu lesen ist, bin erst seit 1 Jahr in der Linux Welt und hatte noch keine major problems, bis auf die gelegentlichen KDE Probleme.

 

[Uridium]

Und in der gleichen Umgebung hast Du fsck ausgeführt und der hat gesagt "alles in Ordnung"? Das ist schwer zu glauben.

 

[cbgilb]

jedenfall ohne die --backup option
mit der option spuckt er das hier aus

liveuser@CachyOS ~]$ sudo btrfs check --backup /dev/nvme0n1p2
Opening filesystem to check...
Checking filesystem on /dev/nvme0n1p2
UUID: dadc5ad6-fbb5-45ae-9c29-96f94b578395
[1/8] checking log
[2/8] checking root items
[3/8] checking extents
super bytes used 332859097088 mismatches actual used 332859027456
ERROR: errors found in extent allocation tree or chunk allocation
[4/8] checking free space tree
[5/8] checking fs roots
[6/8] checking only csums items (without verifying data)
[7/8] checking root refs
[8/8] checking quota groups skipped (not enabled on this FS)
found 332859027456 bytes used, error(s) found
total csum bytes: 321551304
total tree bytes: 1149665280
total fs tree bytes: 652886016
total extent tree bytes: 124698624
btree space waste bytes: 185148929
file data blocks allocated: 388839129088
 referenced 406956593152
[liveuser@CachyOS ~]$

 

[cbgilb]

Ich will ja nicht verwirren, aber:
in der live session steht "errno=-5 IO failure" (failed to recover log tree)
in der emergency shell steht "errno=-2 No such entry" (failed to recover log tree)
Oder ist das zu erwarten weil die Platte da automatisch gemounted wird?

 

[Uridium]

Folge mal der Anweisung der Emergency Shell:
systemctl status sysroot.mount

Memtest war ok?
System übertaktet?

 

[cbgilb]

weder übertaktet, noch undervolted, temps laut bios alles top
wollte ich bei dem 7800x3d eigentlich machen aber bist jetzt ist nur Expo1 aktiv
memtest war in ordnung, smart werte scheinen auch ok
ich probiere nochmal die emergency shell, aber da habe ich glaub ich nicht die btrfs progs
hier noch was:

[liveuser@CachyOS ~]$ sudo btrfs check --check-data-csum /dev/nvme0n1p2
Opening filesystem to check...
Checking filesystem on /dev/nvme0n1p2
UUID: dadc5ad6-fbb5-45ae-9c29-96f94b578395
[1/8] checking log
[2/8] checking root items
[3/8] checking extents
[4/8] checking free space tree
[5/8] checking fs roots
[6/8] checking csums against data
[7/8] checking root refs
[8/8] checking quota groups skipped (not enabled on this FS)
found 332859097088 bytes used, no error found
total csum bytes: 321551372
total tree bytes: 1149665280
total fs tree bytes: 652886016
total extent tree bytes: 124698624
btree space waste bytes: 185148705
file data blocks allocated: 388839198720
 referenced 406956593152


[liveuser@CachyOS ~]$ sudo btrfs rescue super-recover -v /dev/nvme0n1p2
All Devices:
Device: id = 1, name = /dev/nvme0n1p2

Before Recovering:
[All good supers]:
device name = /dev/nvme0n1p2
superblock bytenr = 65536

device name = /dev/nvme0n1p2
superblock bytenr = 67108864

device name = /dev/nvme0n1p2
superblock bytenr = 274877906944

[All bad supers]:

All supers are valid, no need to recover
[liveuser@CachyOS ~]$

Error: kein Error gefunden
es bleibt eigentlich nur noch
1) btrfs rescue zero-log (obwohl mein Kernel Backtrace anders als in den online Beispielen aussieht)
2) btrfs check --init-csum-tree (bevor ich hier so lange warte wie User es schreiben, installiere ich lieber neu)
3) btrfs check --repair (die machen einem ja angst davor, aber ich wette es kommen nochmal abfragen zu spezifischen unteraktionen wenn probleme erkannt werden)

Ergänzung (13. August 2025)

 

[Uridium]

Wir müssen mal rekapitulieren. Das ist ziemlich verwirrend mit den ganzen Mountoptionen. Das können auch zwei isolierte Probleme sein.

In der Emergency Shell:
ls -l /dev/disk/by-uuid
Dort sollte die dadc5ad6-... auf die /dev/nvme0n1p2 verlinkt sein.
Dann mache dies:

mkdir /tmp/nvme0n1p2
mount -t btrfs /dev/nvme0n1p2 /tmp/nvme0n1p2
dmesg |tail -n30 # hiervon Screenshot
cat /etc/fstab # hiervon auch Ich glaube, das geht da noch nicht.

Edit:
Hiervon auch:
cat /proc/cmdline

Hast Du schon mal mit Timeshift, Backup Tools oder ähnlichem rumgespielt?

Edit2:
Hilft zwar nicht weiter, sieht aber ähnlich aus (und ist aktuell).
https://forum.garudalinux.org/t/failed-to-mount-sysroot/45291

 

[cbgilb]

Ok die UUID zeigt auf die korrekte Partition.
cat /proc/cmdline zeigt das richtige boot image und root=UUID=dadc5... sieht normal aus.

Der Mountversuch schlägt wieder fehl. (ich könnte es nochmal mit nologreplay versuchen)
Der |tail befehl funktionier nicht, und /etc... gibts auch noch nicht.
Aber hier trotzdem die letzten Zeilen trace. Die unterscheiden sich minimal von der trace aus der live session.

Ergänzung (13. August 2025)

Gerade nochmal in der live session alle mount Optionen durchgespielt. Es braucht "read only" und "nologreplay" zum mounten. Hab dann noch den btrfs scrub drüber gejagt ohne Fehler. Ich würde also morgen erst zero-log versuchen und danach sogar die ominöse repair Funktion. Außer ein paar KDE Einstellungen und Browsertabs hab ich auf der Maschine nichts zu verlieren.