I’ve recently been attempting to diagnose how to utilise Subnautica 2, via Proton Experimental, provided by Terra’s SteamRT3 package. However, today, after my brother’s host installation reproduced what the undermentioned describes:
…when I sat back at my computer (after dealing with it on his end), I noticed that my compositor was stuck in a reinitialisation-loop, solely visible because it occasionally displayed a different shade of black.
When I switched to an alternative TTY (evidently, KWin was not entirely broken), [1] I observed a kernel trace, from the AMDGPU driver. Via this TTY, I reboot’d, expecting to be able to report the bug on the next boot.
Indeed, initially, I was able to: I invoked gnome-abrt, and began to report five crashes, of at least plasma-desktop and plasma-workspace. However, PT7S afterward, I noticed OSErrors appear on each gnome-abrt window, soon after which multiple components of the DE informed me that they were unable to write to the filesystem. Evidently, the filesystem had been remounted as RO.
(In retrospect, naively), I qdbus-qt6 org.kde.LogoutPrompt /LogoutPrompt promptReboot’d, hoping that it was an edge-case consequence of the previous errata. Instead, when I re-did that exact sequence of events the next boot, the exact error recurred after I invoked gnome-abrt. I originally believed gnome-abrt to be the culprit, because I was initially able to capture a screenshot with spectacle. However, because this problem has since recurred without me ever invoking abrt, I now doubt so.
I’m currently posting this from a USB-connected live image. [2] Originally, I was unable to mount the filesystem, because:
liveuser@localhost-live:~$ sudo mount -t btrfs /dev/nvme1n1p4 /mnt/nvme1n1p4
mount: /mnt/nvme1n1p4: can't read superblock on /dev/nvme1n1p4.
dmesg(1) may have more information after failed mount system call.
However, I have since realised that I am able to, with:
#!/usr/bin/env sh
cd /mnt && \
mkdir ./nvme1n1p4 && \
sudo mount -o ro,rescue=nologreplay /dev/nvme1n1p4 /mnt/nvme1n1p4
I shall attempt to acquire the initramfs’s aforecited rdsosreport.txt, when I am next able to. However, in the meantime, I hope that dmesg’s (verbatim, but potentially truncated) output, from the current boot of the live image, is useful:
Its content certainly appears to equivalate that of the broken installation’s.
Conducted Diagnosis
The SMART status of the storage device appeared to be entirely positive: [4][5]
liveuser@localhost-live:~$ sudo smartctl --health /dev/nvme1n1p4
smartctl 7.5 2025-04-30 r5714 [x86_64-linux-6.19.10-300.fc44.x86_64] (local build)
Copyright (C) 2002-25, Bruce Allen, Christian Franke, www.smartmontools.org
=== START OF SMART DATA SECTION ===
SMART overall-health self-assessment test result: PASSED
Consequently, I tried btrfs check, which appears to be the official tool for this. [6] However, it failed to even locate a fault:
liveuser@localhost-live:~$ run0 btrfs check /dev/nvme1n1p4
Opening filesystem to check...
Checking filesystem on /dev/nvme1n1p4
UUID: e70e2a08-dcc9-4696-9a41-1b34ee1b4b94
[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 862623690752 bytes used, no error found
total csum bytes: 727458776
total tree bytes: 5773246464
total fs tree bytes: 4419207168
total extent tree bytes: 462553088
btree space waste bytes: 1209091940
file data blocks allocated: 1490614075392
referenced 1019905949696
Despite this, the error appeared to be evident; log replay failure. Consequently, I performed:
This worked! [7] However, the second time that I rebooted after remediating it, it recurred. To diagnose this, I had GPT5-o analyse my JournalCtl logs, wherein it observed that a specific Steam file appeared to be the cause. This is not unexpected, considering the original cause. It elaborates on the potential cause, although its explanation is difficult for me to understand:
@emanuc, thank you. However, I’ve since been forced to reinstall the OS over the affected installation, thereby, presumably, replacing the FS. I’ve retained Steam logs, albeit not any more of the JournalD logs than the kernel and FS traces aforeprovided.
Consequently, would me posting a notice to either communication venue remain useful?
