BTRFS is mounted as read-only; snapper-cleanup.service failed: Please help me trouble shoot!

Yep. As it never happened on my systems so far I have no instant suggestion. Be warned: running “btrfs check --repair” is extremely dangerous!

Well understood. I’ve already arranged back-ups having a reinstall in mind. I think I’ll give the repair flag a try and see if it starts smoking. :wink:
Thanks for the support Karl!

Not on mounted filesystem. You should do it when booted from other media.

The mount is read-only. Thus the check is valid. The repair can only be done when unmounted.

rd.break parameter tells initrd to stop booting and start interactive shell at defined point. In logs you provided there is no indication that filesystem was remounted read-only because of errors. If it turns out it is mounted this way from the very beginning, next step would be to find out why.

OK, conceptually, I get it. :smiley:
Just wanted to let you all know that I ended up backing-up my files and reinstalling openSuSE because it seemed just like it was less effort. Thread closed, if it was up to me… But thank you for the help!

Thanks for the feedback. I am wondering what caused the issue. Was it caused by a forced shutdown? Any idea?

To be fair @karlmistelberger, I think there’s a number of things that could have went wrogn:
There were a bunch of weird behaviours that I was wondering about what is going on…
I had a ‘backup’ win10 install on an (actual) HDD in which I have booted into every couple of months or so to update it and to use some specific software or what-not. At one point about 4 weeks ago I did, and updated it and then: Every time I started this machine (where the nvme with openSuSE was first in boot order) it got stuck on BIOS splash screen. Then I restarted it by pressing the power button and then it would always boot normally. Well… at one point, I think after updating win10, the BTRFS became ro. About 2 weeks ago, the machine got completely stuck on splash. Then I kind of paniced and just popped the MoBo battery out, which let me get back into BIOS so i could boot into anything. Also this machine is about 10 years old, quite dusty and has travelled twice as check-in luggage :smiley: Other than that, the NVME is from a friend of mine, from some mixed-IT-stuff drawer… Saying that I don’t want to rule out hardware issues as well… So, yeah, a number of things could have been the breaking point.

None of the above should affect btrfs. I tried weird things on my machines. They wouldn’t break the file systems.

You may want to check your device. Mine is:

erlangen:~ # smartctl -A /dev/nvme0n1
smartctl 7.3 2022-02-28 r5338 [x86_64-linux-5.18.11-1-default] (SUSE RPM)
Copyright (C) 2002-22, Bruce Allen, Christian Franke, www.smartmontools.org

=== START OF SMART DATA SECTION ===
SMART/Health Information (NVMe Log 0x02)
Critical Warning:                   0x00
Temperature:                        43 Celsius
Available Spare:                    100%
Available Spare Threshold:          10%
Percentage Used:                    0%
Data Units Read:                    31,884,620 [16.3 TB]
Data Units Written:                 26,310,395 [13.4 TB]
Host Read Commands:                 248,493,363
Host Write Commands:                469,124,852
Controller Busy Time:               769
Power Cycles:                       1,011
Power On Hours:                     664
Unsafe Shutdowns:                   14
Media and Data Integrity Errors:    0
Error Information Log Entries:      1,619
Warning  Comp. Temperature Time:    0
Critical Comp. Temperature Time:    0
Temperature Sensor 1:               43 Celsius
Temperature Sensor 2:               42 Celsius

erlangen:~ #