System suddenly boots up in emergency mode

English Install/Boot/Login
#21

Just a side note. If you want to see dmesg output just run dmesg.
dmesg(1) indicate that dmesg manual is in section 1. of manual (man) and you don’t include (1) in command.

#22

This part suggests that you already have this partition mounted (even if previous mount command failed) so maybe run mount to see where it’s mounted, do umount /dev/nvme0n1p2, run again mount to see if it’s really umounted and then try btrfs check /dev/nvme0n1p2 .

#23

Yes, it was indeed mounted :

/dev/nvme0n1p2 on /run/media/linux/ccf6f517-0782-440a-8ad9-9d4d127ec422 type btrfs (ro,nosuid,nodev,relatime,ssd,discard=async,space_cache,subvolid=267,subvol=/@/.snapshots/1/snapshot)

After umount is was gone and the check returned :

mx1:/home/linux # btrfs check /dev/nvme0n1p2
Opening filesystem to check…
Checking filesystem on /dev/nvme0n1p2
UUID: ccf6f517-0782-440a-8ad9-9d4d127ec422
[1/7] checking root items
[2/7] checking extents
[3/7] checking free space cache
[4/7] checking fs roots
root 263 inode 8009 errors 200, dir isize wrong
root 263 inode 6930299 errors 1, no inode item
unresolved ref dir 8009 index 386062 namelen 22 name ssdfp2806.1.1894486602 filetype 1 errors 5, no dir item, no inode ref
root 263 inode 6930300 errors 1, no inode item
unresolved ref dir 8009 index 386064 namelen 22 name ssdfp2806.1.1894486602 filetype 1 errors 5, no dir item, no inode ref
root 263 inode 6930301 errors 1, no inode item
unresolved ref dir 8009 index 386066 namelen 22 name ssdfp2806.1.1894486602 filetype 1 errors 5, no dir item, no inode ref
root 263 inode 6930302 errors 1, no inode item
unresolved ref dir 8009 index 386068 namelen 22 name ssdfp2806.1.1894486602 filetype 1 errors 5, no dir item, no inode ref
root 263 inode 6930303 errors 1, no inode item
unresolved ref dir 8009 index 386070 namelen 22 name ssdfp2806.1.1894486602 filetype 1 errors 5, no dir item, no inode ref
ERROR: errors found in fs roots
found 62065549312 bytes used, error(s) found
total csum bytes: 57948452
total tree bytes: 1479376896
total fs tree bytes: 1331576832
total extent tree bytes: 66060288
btree space waste bytes: 371196871
file data blocks allocated: 200900907008
referenced 173014536192

performed the rest of the procedure :

mx1:/home/linux # btrfs rescue super-recover /dev/nvme0n1p2
All supers are valid, no need to recover
mx1:/home/linux # btrfs rescue zero-log /dev/nvme0n1p2
Clearing log on /dev/nvme0n1p2, previous log_root 0, level 0
mx1:/home/linux # btrfs rescue chunk-recover /dev/nvme0n1p2
Scanning: DONE in dev0
corrupt node: root=1 block=1577402368 slot=0, corrupt node: root=1 block=1577402368, nritems too large, have 5 expect range [1,0]
Couldn’t read tree root
open with broken chunk error
mx1:/home/

How to proceed ?

#24

With no replies on the former post, i have resorted to the ultimate suggested solution :

linux@mx1:~> su
mx1:/home/linux # btrfs check --repair /dev/nvme0n1p2
enabling repair mode
WARNING:

    Do not use --repair unless you are advised to do so by a developer
    or an experienced user, and then only after having accepted that no
    fsck can successfully repair all types of filesystem corruption. Eg.
    some software or hardware bugs can fatally damage a volume.
    The operation will start in 10 seconds.
    Use Ctrl-C to stop it.

10 9 8 7 6 5 4 3 2 1
Starting repair.
Opening filesystem to check…
Checking filesystem on /dev/nvme0n1p2
UUID: ccf6f517-0782-440a-8ad9-9d4d127ec422
[1/7] checking root items
Fixed 0 roots.
[2/7] checking extents
No device size related problem found
[3/7] checking free space cache
cache and super generation don’t match, space cache will be invalidated
[4/7] checking fs roots
Deleting bad dir index [8009,96,386062] root 263
Deleting bad dir index [8009,96,386064] root 263
Deleting bad dir index [8009,96,386066] root 263
Deleting bad dir index [8009,96,386068] root 263
Deleting bad dir index [8009,96,386070] root 263
[5/7] checking only csums items (without verifying data)
[6/7] checking root refs
[7/7] checking quota groups
check/qgroup-verify.c:547: account_all_refs: BUG_ON ref->num_bytes != num_bytes triggered, value 1
btrfs(+0x55051)[0x555d42e20051]
btrfs(qgroup_verify_all+0x67c)[0x555d42e2138c]
btrfs(+0x8839a)[0x555d42e5339a]
btrfs(main+0x8a)[0x555d42de4eda]
/lib64/libc.so.6(+0x27bb0)[0x7f80366e8bb0]
/lib64/libc.so.6(__libc_start_main+0x8b)[0x7f80366e8c79]
btrfs(_start+0x25)[0x555d42de51f5]
Aborted (core dumped)
mx1:/home/linux #

Not sure this was a succes.
I will try and reboot and post the result later.

#25

Seeing that the repair decided to Abort, we can assume it didn’t complete the repair.

I’ve run a BTRFS repair recently… the machine I used to perform the repair has 64gb RAM.

Whatever machine you’re using to repair … does it have adequate resources, namely memory ??

#26

Still booting into emergency mode after attempted repair. My laptop has 16 gb RAM.

#27

Other members may have other options to share.

Personally, if I were in the situation with same results, I’d run the repair again. :crossed_fingers:

#28

Well, I actually gave up and accept the loss. I replaced the SSD and did a fresh install.
Will try and recover any data later if required. Thank to all for the support.

1 Like