After a hard reset fedora boots into emergency mode

Ask Fedora
1

Hi, I am a not very experienced person in Linux, i have a laptop dualbooting win11 and fedora41 workstation on two separate nvmes, intel and samsung if this matters
and so one time I accidentally booted into linux I hard reset my pc to boot to windows, and some time after i tried to boot into Fedora, i got put into emergency mode:

1.8903691 BIRFS: error (device mmelnlp?) in btrfs_replay_log:2184: errno=-5
IO failure (Failed to recover log tree)

i googled it, and people on the forum recomended doing a check, so I ran

btrfs check --check-data-csum -p /dev/nvme1n1p7
Opening filesystem to check.
Checking filesystem on /dew/nume1nlp?
UUID: 7455b045-73c5-4279-bfdd-96d9ea067500


[1/8] checking log
[1/7] checking root items
(0:00:02 elapsed, 2568838 items checked)
[2/?1 checking extents
(0:00:06 `elapsed, 181170 items checked)
free space info recorded 286 extents. counted 285:00:00 elapsed)
wanted bytes 614400, found 606208 for off 38684499968
cache appears valid but isn't 37611372544
frec space info recorded 370 extents, counted 369
there is no frec space entry for 52643737600-52643758080
cache appears valid but isn't 51570016256
free space info recorded 324 extents, counted 323
there is no free space entry for 54791155712-54791241728
cache appears valid but isn't 53717499904
free space info recorded 400 extents, counted 399
there is no free space entry for 70897352704-70897369088
cache appears valid but isn't 69823627264
free space info recorded 168 extents, counted 167
there is no free space entry for 75192320000-75192336384
cache appears valid but isn't 74118594560
free space info recorded 162 extents, counted 161
there is no frec space entry for 77339811840-77339820032
cache appears valid but isn't 76266078208
free space info recorded 4 extents, counted 3
there is no free space entry for 82707955712-82708529152
cache appears valid but isn't 81634787326
[3/7] checking free space tree
(0:00:00 elapsed, 423 items checked)
[4/?1. checking fs roots
(0:00:09 elapsed, 137419 items. checked)
[5/7] checking csums against data
(0:00:06 elapsed, 184604 items checked)

then a lot of mirror errors

mirror 1 bytenr 530856560610 csum 0x8ede0b6? expected csum 8x1f937774
mirror 1 butenr 538856561736 csum 0xaa6e7Be? expected csum 0xBecd379f
mirror 1 bytenr 538856568832 csum 0x509e46cc expected csum 8x83d6193e
[5/?] checking csums ayainst data
(0:04:21 elapsed, 976854 ftems checked)
ERROR: errors found in csum tree
[6/7] checking root refs
(0:00:00 elapsed, 6 items checked)
18,/81 checking quota groups skipped (not enabled on this FS)
found 382172643328 butes used, error(s) found
total csum bytes: 362B58208
total trec bytes: 2968892672
total fs tree bytes: 7268254720
total extent tree bytes: 255082496
btree space waste butes: 614154132
file data blocks allocated: 3137615085568
referenced 459119195088

And people also recomended doing a brtfs check with repair, but also it is written that you should do it only if you are very sure. I dont know much, so i would appreciate any help and suggestions on what to do. Sorry for any english or formatting errors.

There also may be errors in output since i got the text from a photo of terminal, i dont know any better way to get it here.

2

1000009303
10000093031920×1080 325 KB

1000009306
10000093061920×1080 406 KB

Here are the pictures. Appreciate any help.

3

Chris would be the one to ask about Btrfs file system errors. However, I think he prefers to use Matrix. You might have better luck asking your question in the Btrfs Matrix room here: https://chat.fedoraproject.org/#/room/#btrfs:fedoraproject.org

4

Always best to avoid hard reset as that can cause issue with any OS.
You could have left Fedora to boot then just rebooted from the login screen.

5

Sure i could have but i absolutely didn’t, i understand i shouldn’t have done that. Is there anything I can do though?

6

You need an expert on btrfs and that Chris as Gregory suggested.

7

Thanks, I will try to find them. Is there a way for me to reach them? I am really sorry if I am asking dumb questions but its my first time here.

8

This doesn’t urgently need to be fixed. It’s more important to have backups of anything important than to fix it, so make sure to backup first. The repair is simple and safe but it is irreversible so if something goes wrong.

Boot from a recently imaged USB stick (I’ll always recommend the latest Fedora ISO, any variant is OK).

# btrfs rescue clear-space-cache v1 /dev/nvme1n1p7
# mount -o space_cache=v2 /dev/nvme1n1p7 /mnt
# umount /mnt

If you’re very curious you can confirm v2 (free space tree) is present with:

# btrfs insp dump-s /dev/nvme1n1p7
<snip>
compat_ro_flags         0x3
                        ( FREE_SPACE_TREE |
                          FREE_SPACE_TREE_VALID )

Once you do this one time mount with v2, it’ll set the free space tree feature flag(s) and now every mount after that will automatically use v2.

If you do a btrfs check now it should be clear of the errors in step 2. I’m not sure if this will fix the csum error messages, therefore…

Next, boot normally and do an online scrub. Monitor the scrub with:

# journalctl -fk

And in another shell start the scrub:

# btrfs scrub start /

The journal will show any error messages related to the scrub including the full path to file for any affected files.

Depending on the files affected, you can either replace them with known good backups; or if they’re application data, reinstall the appropriate package. If it’s a flatpak, use flatpak repair

Btrfs by default will not hand over corrupt data to user space. Mount option rescue=idatacsums can help extract such files in case there are no backups. Caution is advised, not to use it persistently.

2 Likes
9

Thank you! Scrub completed without any errors as far as i can tell, and i actually think it was windows who caused the trouble with its unnative btrfs drivers, because the next day it booted just like nothing happened without me doing a repair.