How can I repair BTRFS /boot, getting error after power loss and reboot

I had a loss of power, and now I can get to the boot menu, however if I continue to boot I get the following error:

BTRFS error (device nvme2n1p4 state E): open_ctree failed: -2

Then it enters emergency mode and I am told to press CTRL-D to continue. However, doing this willl put me back into emergency mode.

How can I use the install CD to rescue my system and possibly repair the boot partition.

I also tried the advanced menu option, and used the last kernel as well as entering repair mode. Both put me in the emergency mode loop.

To start with, use the root password and run
btrfs check /dev/nvme2n1p4
Also check the BTRFS troubleshooting on the openSUSE wiki pages

Something odd is going on with openSUSE TW KDE, I tired to install it and it just hangs during the hardware check afaik.

So I gave up and was able to install Fedora KDE with no issue. How can I figure out what’s causing the hang?

This occurs after the growing horizontal bar along the bottom. It switches into text mode and starts to do some checks? and then just hangs. The screen is black with a cursor “_” at the top left of the screen.

Also I dual boot into Win 11 and this never stopped working.

@devguy wrote:

Windows is not Linux and does not use the BTRFS filesystem, especially the one [possibly corrupted] used by your TW install

What about booting to a previous snapshot??

You can’t, since your action destroyed all potential evidence that could help debug things.
I do have a question though: How was the install USB created? If Ventoy ( again ) is involved, it stops here, see the dozens of other threads on that. BTW, what did my previous comment give?

The BTRFS check ran fine, I didn’t see any errors. If I recall maybe some blocks freeded or reallocated, don’t recall the wording.

I created the disk image on the USB using “Etcher”, I have done this multiple times in the past with no issues.

Do you have another way I can create the USB image, tool, utility to see if I can get opensuse TW install to not hang?

OK, make sure you have a backup of your data, then run
btrfs check --repair /dev/nvme2n1p4
that should fix the tree.

This is my experience too trying to replace an existing openSUSE TW install with a new one. I have to delete all openSUSE partitions and start again from scratch, and then the installer won’t hang. I had a friend experience this behaviour recently too.

That could be very well explained by the recent changes in TW. Most likely a too small EFI partition.

What are “openSUSE partitions” ??

The partitions associated with my previous openSUSE Tumbleweed install.

The latest updated seems to have crippled my machine with the same issue. My system is the latest KDE on TW 6.15.6-1. The btrfs check command reported no error found but did not fix the problem. In following the BTRFS troubleshoot procedure I find that firstly the btrfs filesystem show / and btrfs filesystem df /both fail. Secondly, I find the booting the latest TW iso openSUSE-Tumbleweed-DVD-x86_64-Snapshot20250722-Media on USB hangs after starting udev at loading basic drivers. No matter which option I choose this happens. Could you please suggest what I can do next? Thanks

BTW … just to add to the above … booting my second machine (6.13.8-1) from the TW iso USB produces the immediate error ../../grub-core/kern/mm.c:548:out of memory. Press any key to continue ... and then continues to a screen of instructions and stalls … I had the same behaviour with the 250718 iso … could there be issues with the iso as well? Thanks

This command did fix my system: btrfs check --repair /dev/nvme0n1p2… thanks

1 Like

I always put my home folder on another partition, this time I got my home on another drive. So not too worry about blowing away things. It’s too late for me to repair the partition and for the life of me, I cannot do a fesh install of opensuse TW KDE?

The installer makes it to the point where it says it’s probing the terminal, says it found it at /dev/console and after this the terminal screen goes blank and it just hangs. I cannot even perform CTRL+ALT+DEL to reboot.

So for now I got Fedora 42 KDE working. I even reset my BIOS setting and this didn’t help with opensuse TW KDE fresh install.

I formatted both my NVME SSD I have two and did a reinstall on each, same hanging issue.

Could the problem possibly be with the kernel? because it seems others are reporting similar issues. At least @stuartn is experiencing the same thing I am seeing.

So for me, I hope it’s nothing hardware related.

@stuartn

FWIW, when I built my new PC I ran into the same grub error you are reporting. The system has 64 GB of memory so it is definitely not out of memory :slight_smile:

Someone from SUSE told me to disable TPM during the install to work around the issue and then re-enable it after the installation is complete.

That worked fine for when I encountered that issue but that was in 11/2023 using TW 20231120 for the installation but possibly it will help you now.

Thanks @JoeS, it’s too late for me…I’ve gone and switched distros. I discoved their KDE Wayland support is rock solid and with parallel package downloads, won’t be returning. Also the system not goes to sleep and wake up without hanging. With TW I was convinced it was my hardware.

I’m simply stating some personal thoughts - any question is rhetorical , so no answer required.

First off, you mentioned you’re now running Fedora 42 KDE. That’s comparable to Leap 15.6 (and upcoming 16.0).

TW is a rolling release. You should have chosen Fedora Rawhide, a rolling release, like TW.

Might have been interesting to try Leap 15.6 , since it is more in line with 42.

openSUSE does parallel downloads, so mentioning that Fedora does it, as if it’s unique, is incorrect.

Longtime TW users here, but to be forthright, we did switch from TW to Leap. A couple reasons: mostly because TW requires more handholding, overall, than Leap.

Reason 2 was the “xz utils” fiasco. That proved that a cutting edge rolling release is more susceptible. (we got the backdoor on our machines) . But guess what? Fedora Rawhide also had the “xz utils” backdoor distributed to users.

So, to us, TW and Leap is not an apples to apples comparison, just like TW and Fedora 42, or Fedora 42 and Rawhide :+1:

1 Like

I tried to resize my /boot and then now I cannot log into my TW. It is going into emergency mode.

Trying to check the filesystem with btrfs check gives me:

jurombo@MathW15:~> sudo btrfs check /dev/sdb5
Opening filesystem to check...
parent transid verify failed on 55999217664 wanted 1153971 found 1157407
parent transid verify failed on 55999217664 wanted 1153971 found 1157407
parent transid verify failed on 55999217664 wanted 1153971 found 1157407
Ignoring transid failure
ERROR: child eb corrupted: parent bytenr=67354624 item=365 parent level=1 child bytenr=55999217664 child level=1
ERROR: failed to read block groups: Input/output error
ERROR: cannot open file system