Can't boot from LUKS encrypted btrfs anymore

General system Newbie
1

Hello,
I’m afraid I did a terrible mistake [*] and messed up my LUKS encrypted btrfs:
This is an Artemis installation with last updates from about 2 weeks ago.
I configured hibernation to swapfile.
That’s on a Dell XPS 13 9350, 2TB ssd retrofitted.
Everything (AFAICT) was working fine, till now.
It’s the first time I’m trying btrfs and luks encryption.

First,
on the user side, before booting after entering the passphrase, after the “Slot 0 opened”,
I get “error: unknown filesystem.”
Then I’m left with grub rescue-mode.

Trying to mount the partition on the old system (on which I’m writing this) I get

mount: /media/mz/TEMP: wrong fs type, bad option, bad superblock on /dev/mapper/luks-2d88a6e5-65b9-484d-aef5-633cd1b775c7, missing codepage or helper program, or other error.
upon trying to mount the bad fs.

I tried this with
mount -o ro,usebackuproot /dev/mapper/luks-2d88a6e5-65b9-484d-aef5-633cd1b775c7 /media/me/TEMP/

syslog shows:

Aug 6 10:29:26 e-minor kernel: [ 4286.264663] BTRFS info (device dm-0): flagging fs with big metadata feature
Aug 6 10:29:26 e-minor kernel: [ 4286.264671] BTRFS info (device dm-0): using free space tree
Aug 6 10:29:26 e-minor kernel: [ 4286.264676] BTRFS info (device dm-0): has skinny extents
Aug 6 10:29:26 e-minor kernel: [ 4286.281070] BTRFS error (device dm-0): parent transid verify failed on 334692352 wanted 14761 found 14765
Aug 6 10:29:26 e-minor kernel: [ 4286.281416] BTRFS error (device dm-0): parent transid verify failed on 334692352 wanted 14761 found 14765
Aug 6 10:29:26 e-minor kernel: [ 4286.281436] BTRFS error (device dm-0): failed to read block groups: -5
Aug 6 10:29:26 e-minor kernel: [ 4286.321874] BTRFS error (device dm-0): open_ctree failed

dmesg writes:

[ 2343.327025] BTRFS: device fsid 2d1dc6b4-84ab-4c64-91a0-669b6228c516 devid 1 transid 14761 /dev/dm-0
[ 2343.610293] BTRFS info (device dm-0): flagging fs with big metadata feature
[ 2343.610296] BTRFS info (device dm-0): using free space tree
[ 2343.610297] BTRFS info (device dm-0): has skinny extents
[ 2343.616005] BTRFS error (device dm-0): parent transid verify failed on 334692352 wanted 14761 found 14765
[ 2343.616187] BTRFS error (device dm-0): parent transid verify failed on 334692352 wanted 14761 found 14765
[ 2343.616193] BTRFS error (device dm-0): failed to read block groups: -5
[ 2343.659569] BTRFS error (device dm-0): open_ctree failed

blkid:

/dev/nvme0n1p1: LABEL="NO_LABEL" UUID="2F5D-2584" TYPE="vfat" PARTUUID="6b7d850e-38a4-044a-b526-16d5f1860b57"
/dev/nvme0n1p2: UUID="2d88a6e5-65b9-484d-aef5-633cd1b775c7" TYPE="crypto_LUKS" PARTLABEL="root" PARTUUID="9e456477-7b1c-d84d-99a2-27aa32c90206"
/dev/sda1: UUID="C57C-D866" TYPE="vfat" PARTLABEL="EFI System Partition" PARTUUID="ccf8d7e2-92b9-4eff-8f62-ccb5b8abf35a"
/dev/sda2: UUID="e0e2a28e-3780-4a63-8636-3b712c6d9e23" TYPE="ext4" PARTUUID="4b66127e-1190-4093-9c8e-b77420a735a2"
/dev/sda3: UUID="a68c5bb0-f919-4100-8b8c-870b37c808aa" TYPE="swap" PARTUUID="0d55ec7b-c084-4196-b9fa-1b1bf1bccd12"
/dev/nvme0n1: PTUUID="8ed72cef-dfe2-3244-8975-0157bc9f9e96" PTTYPE="gpt"

lsblk:

NAME        MAJ:MIN RM   SIZE RO TYPE MOUNTPOINT
 sda           8:0    1 460,3G  0 disk
 |-sda1        8:1    1   512M  0 part /boot/efi
 |-sda2        8:2    1 220,7G  0 part /
 `-sda3        8:3    1  17,3G  0 part [SWAP]
 nvme0n1     259:0    0   1,8T  0 disk
 |-nvme0n1p1 259:1    0   300M  0 part
 `-nvme0n1p2 259:2    0   1,8T  0 part

Also:

# cryptsetup status /dev/mapper/luks-2d88a6e5-65b9-484d-aef5-633cd1b775c7
/dev/mapper/luks-2d88a6e5-65b9-484d-aef5-633cd1b775c7 is active.
  type:    LUKS1
  cipher:  aes-xts-plain64
  keysize: 512 bits
  key location: dm-crypt
  device:  /dev/nvme0n1p2
  sector size:  512
  offset:  4096 sectors
  size:    3906406400 sectors
  mode:    read/write

I’m at the point where I’m just able to poke around and fit in missing knowledge, but also being stuck.
What can I do to rescue this partition?

Thank you very much!
Michael.

[*] I do have my old system (Mint 19.3) on a USB stick which I configured as a boot option.
I put EOS into hibernation and booted from the USB stick (some SW still is missing on my EOS installation).
My mistake (I think) started with mounting the EOS btrfs to Mint, exchanging some files, putting Mint to hibernation and trying to continue on EOS.
Now I tried to access an already mounted (encrypted) FS… which did not work.
I’m not sure if/what I’m missing but that’s the picture I have right now.

2

DId you run cryptsetup open first to unlock your luks volume before trying to mount it? Something like sudo cryptsetup open /dev/sdxy luks-2d88a6e5-65b9-484d-aef5-633cd1b775c7

1 Like
3

Thanks for the quick reply!
I did

 ~ # cryptsetup open /dev/mapper/luks-2d88a6e5-65b9-484d-aef5-633cd1b775c7 test
Device /dev/mapper/luks-2d88a6e5-65b9-484d-aef5-633cd1b775c7 doesn't exist or access denied.
 ~ # cryptsetup status test
/dev/mapper/test is inactive.
 ~ # cryptsetup status /dev/mapper/luks-2d88a6e5-65b9-484d-aef5-633cd1b775c7
/dev/mapper/luks-2d88a6e5-65b9-484d-aef5-633cd1b775c7 is active.
  type:    LUKS1
  cipher:  aes-xts-plain64
  keysize: 512 bits
  key location: dm-crypt
  device:  /dev/nvme0n1p2
  sector size:  512
  offset:  4096 sectors
  size:    3906406400 sectors
  mode:    read/write

because that’s where I’m having a hard time with the man page. [*]
Before I did

 ~ # cryptsetup open /dev/nvme0n1p2 luks-2d88a6e5-65b9-484d-aef5-633cd1b775c7     
Enter passphrase for /dev/nvme0n1p2: 
Device luks-2d88a6e5-65b9-484d-aef5-633cd1b775c7 already exists.
 ~ # cryptsetup open /dev/nvme0n1p2 luks-test                                
Enter passphrase for /dev/nvme0n1p2: 
Cannot use device /dev/nvme0n1p2 which is in use (already mapped or mounted).

This is where I’m stuck and can’t get that straight: I think I understood the opened device is the /dev/mapper/some-uuid one?

Thanks, Michael.

[*] man cryptsetup says:

open <device> <name> --type <device_type>

But apparenty the device already is open, supposedly via Nemo, where I got a similar errormsg like in my original posting. So for now I strictly should stick to the commandline not to get things confused.

4

I would reboot and not use nemo to open it first.

Then use:

sudo cryptsetup open /dev/nvme0n1p2 luks-2d88a6e5-65b9-484d-aef5-633cd1b775c7

Then try mounting it with the mount command.

5

ok, I had another thought, so meanwhile I did:

 ~ # cryptsetup close luks-2d88a6e5-65b9-484d-aef5-633cd1b775c7
 ~ # cryptsetup open /dev/nvme0n1p2 luks-test
Enter passphrase for /dev/nvme0n1p2: 
 ~ # mount -o ro,usebackuproot /dev/mapper/luks-test /media/mz/TEMP/
mount: /media/mz/TEMP: wrong fs type, bad option, bad superblock 
on /dev/mapper/luks-test, missing codepage 
or helper program, or other error.
6

(which should be similar to your suggestion)

7

try

sudo btrfs check /dev/mapper/luks-test
8 
 ~ # btrfs check /dev/mapper/luks-test
parent transid verify failed on 334692352 wanted 14761 found 14765
parent transid verify failed on 334692352 wanted 14761 found 14765
parent transid verify failed on 334692352 wanted 14761 found 14765
parent transid verify failed on 334692352 wanted 14761 found 14765
Ignoring transid failure
leaf parent key incorrect 334692352
ERROR: cannot open file system

That’s similar what I saw in syslog & dmesg (through trying to mount via Nemo back then) hence I tried “usebackuproot” with mount.

9

Just had a look with

 ~ # btrfs-find-root /dev/mapper/luks-test
parent transid verify failed on 334692352 wanted 14761 found 14765
parent transid verify failed on 334692352 wanted 14761 found 14765
parent transid verify failed on 334692352 wanted 14761 found 14765
parent transid verify failed on 334692352 wanted 14761 found 14765
Ignoring transid failure
leaf parent key incorrect 334692352
Superblock thinks the generation is 14761
Superblock thinks the level is 0
Found tree root at 444612608 gen 14761 level 0
Well block 347160576(gen: 14768 level: 0) seems good, but 
generation/level doesn't match, want gen: 14761 level: 0
Well block 348192768(gen: 14766 level: 0) seems good, but 
generation/level doesn't match, want gen: 14761 level: 0
Well block 347865088(gen: 14765 level: 0) seems good, but 
generation/level doesn't match, want gen: 14761 level: 0
Well block 418840576(gen: 14758 level: 0) seems good, but 
generation/level doesn't match, want gen: 14761 level: 0
Well block 417120256(gen: 14749 level: 0) seems good, but 
generation/level doesn't match, want gen: 14761 level: 0
Well block 352256000(gen: 14743 level: 0) seems good, but 
generation/level doesn't match, want gen: 14761 level: 0

I’m afraid that’s out of my league now … :flushed:

10

It seems clear your filesystem is corrupt.

I think you might want to share the output of those commands with people with more detailed knowledge of btrfs. There are some commands that are capable of repairing a btrfs filesystem but using them incorrectly can make things even worse. If there is any important data in that filesystem you should definitely get better advice before damaging it further.

1 Like
11

Thanks a lot for your support!
Michael.

12

For the sake of completeness:
After some search across the Net I joined the BTRFS mailing list and some other kind souls looked at it.
The gist is, the FS is wrecked but I can mount it RO to get some of the new data I couldn’t backup to this point.
Then I have to re-format/re-install … :expressionless:
The thread:
https://lore.kernel.org/linux-btrfs/12ad8fa0-a4f6-815d-dcab-1b6efa1c9da8@bluemole.com/
Thanks again, Michael.

2 Likes
13

Sorry your FS is corrupt but getting access to your data is better than not so I am glad you were able to get that at least.

1 Like
14

Yep, but entirely my fault.
ATM btrfs-people are discussing ways to mitigate a mistake like this.
They really stick to their claim this FS is a fast moving (i.e. developing) target!

2 Likes
15

This topic was automatically closed 2 days after the last reply. New replies are no longer allowed.