Arch Linux

MS1

Member

Registered: 2018-02-02

Posts: 89

Accident - ran e2fsck on crypto_LUKS and now it's dead

By mistake I ran the e2fsck on a crypto_LUKS partition when it wasn't mounted and now I can't unlock. I try to recover it using cryptset because I made a backup of the luksheader but I cant mount it. Is there anything I can do it recover?

# cryptsetup -v --header /root/backup/luksheader-backup.img open /dev/sda2 test
Enter passphrase for /dev/sda2: 
Key slot 1 unlocked.
Command successful.

# mount /dev/mapper/test /mnt/test 
mount: /mnt/test: wrong fs type, bad option, bad superblock on /dev/mapper/test, missing codepage or helper program, or other error.

Slithery

Administrator

From: Norfolk, UK

Registered: 2013-12-01

Posts: 5,776

Re: Accident - ran e2fsck on crypto_LUKS and now it's dead

Welcome to the forums MS1

Have you tried running an fsck on /dev/mapper/test after unlocking?

---

No, it didn't "fix" anything. It just shifted the brokeness one space to the right. - jasonwryan
Closing -- for deletion; Banning -- for muppetry. - jasonwryan

aur - dotfiles

graysky

Wiki Maintainer

From: :wq

Registered: 2008-12-01

Posts: 10,690

Website

Re: Accident - ran e2fsck on crypto_LUKS and now it's dead

Can you run `e2fsck -fv /dev/mapper/test`?  What is the output?

---

CPU-optimized Linux-ck packages @ Repo-ck  • AUR packages • Zsh and other configs

MS1

Member

Registered: 2018-02-02

Posts: 89

Re: Accident - ran e2fsck on crypto_LUKS and now it's dead

I can run it but it fails:

# e2fsck -fv /dev/mapper/test
e2fsck 1.43.8 (1-Jan-2018)
ext2fs_open2: Bad magic number in super-block
e2fsck: Superblock invalid, trying backup blocks...
e2fsck: Bad magic number in super-block while trying to open /dev/mapper/test

The superblock could not be read or does not describe a valid ext2/ext3/ext4
filesystem.  If the device is valid and it really contains an ext2/ext3/ext4
filesystem (and not swap or ufs or something else), then the superblock
is corrupt, and you might try running e2fsck with an alternate superblock:
    e2fsck -b 8193 <device>
 or
    e2fsck -b 32768 <device>

# e2fsck -b 8193 /dev/mapper/test
e2fsck 1.43.8 (1-Jan-2018)
e2fsck: Bad magic number in super-block while trying to open /dev/mapper/test

The superblock could not be read or does not describe a valid ext2/ext3/ext4
filesystem.  If the device is valid and it really contains an ext2/ext3/ext4
filesystem (and not swap or ufs or something else), then the superblock
is corrupt, and you might try running e2fsck with an alternate superblock:
    e2fsck -b 8193 <device>
 or
    e2fsck -b 32768 <device>

# e2fsck -b 32768 /dev/mapper/test
e2fsck 1.43.8 (1-Jan-2018)
e2fsck: Bad magic number in super-block while trying to open /dev/mapper/test

The superblock could not be read or does not describe a valid ext2/ext3/ext4
filesystem.  If the device is valid and it really contains an ext2/ext3/ext4
filesystem (and not swap or ufs or something else), then the superblock
is corrupt, and you might try running e2fsck with an alternate superblock:
    e2fsck -b 8193 <device>
 or
    e2fsck -b 32768 <device>

graysky

Wiki Maintainer

From: :wq

Registered: 2008-12-01

Posts: 10,690

Website

Re: Accident - ran e2fsck on crypto_LUKS and now it's dead

Wait for someone else with more experience to reply, but I think you're f*cked... backups?

EDIT:  It seems like e2fsck should be smarter than users and NOT run without a -force switch or the like if it's a cryptoluks partition.  It does this when users try to run it on a mounted partition for example.  Perhaps I am missing something.

Last edited by graysky (2018-02-02 22:47:01)

---

CPU-optimized Linux-ck packages @ Repo-ck  • AUR packages • Zsh and other configs

MS1

Member

Registered: 2018-02-02

Posts: 89

Re: Accident - ran e2fsck on crypto_LUKS and now it's dead

Wait for someone else with more experience to reply, but I think you're f*cked... backups?

I hope there is an option because the back up is over a month old.

MS1

Member

Registered: 2018-02-02

Posts: 89

Re: Accident - ran e2fsck on crypto_LUKS and now it's dead

I googling for the answer too but couldn't find one so I did the restore and lost the data. I wish e2fsck would warn users about this

WorMzy

Administrator

From: Scotland

Registered: 2010-06-16

Posts: 12,602

Website

Re: Accident - ran e2fsck on crypto_LUKS and now it's dead

What filesystems (if any) are detected on /dev/mapper/test?

wipefs /dev/mapper/test

What filesystem (if any) should be on it?

---

Sakura:-
Mobo: MSI MAG X570S TORPEDO MAX // Processor: AMD Ryzen 9 5950X @4.9GHz // GFX: AMD Radeon RX 5700 XT // RAM: 32GB (4x 8GB) Corsair DDR4 (@ 3000MHz) // Storage: 1x 3TB HDD, 6x 1TB SSD, 2x 120GB SSD, 1x 275GB M2 SSD

Making lemonade from lemons since 2015.

Elizine

Member

From: United Kingdom

Registered: 2015-10-07

Posts: 39

Website

Re: Accident - ran e2fsck on crypto_LUKS and now it's dead

First check if the disk is partitioned using the following command.

lisa@admingirl:$ lsblk
NAME   MAJ:MIN RM  SIZE RO TYPE MOUNTPOINT
sda      8:0    0   10G  0 disk 
└─sda1   8:1    0   10G  0 part /
sdb      8:16   0    1T  0 disk 
└─sdb1   8:17   0 1024G  0

In the example you can see that sdb is partitioned to sdb1. So instead of mounting the device /dev/sdb mount /dev/sdb1 partition. An example mount command is shown below.

sudo mount /dev/sdb1 /mount/path

---

Cloud Hosting Solutions

frostschutz

Member

Registered: 2013-11-15

Posts: 1,498

Re: Accident - ran e2fsck on crypto_LUKS and now it's dead

I made a backup of the luksheader but I cant mount it.

# cryptsetup -v --header /root/backup/luksheader-backup.img open /dev/sda2 test
Enter passphrase for /dev/sda2: 
Key slot 1 unlocked.
Command successful.

# mount /dev/mapper/test /mnt/test 
mount: /mnt/test: wrong fs type, bad option, bad superblock on /dev/mapper/test, missing codepage or helper program, or other error.

If the LUKS header backup is the correct one, even if the filesystem on it is defective, you should be able to find non-random data in the raw block device (/dev/mapper/test).

So, run strings -w, hexdump -C or photorec or similar tools on it and see if you get anything at all that isn't random noise. If there is nothing - you have the wrong LUKS header. If there is something but way too little, you might have an old LUKS header you used in the past that finds fragments that are in "free space" of a new one.

By mistake I ran the e2fsck on a crypto_LUKS partition when it wasn't mounted and now I can't unlock.

fsck is short for file system crunch kill

On the face of it, it does the right thing:

e2fsck 1.43.9 (8-Feb-2018)
ext2fs_open2: Bad magic number in super-block
e2fsck: Superblock invalid, trying backup blocks...
e2fsck: Bad magic number in super-block while trying to open /dev/loop0

The superblock could not be read or does not describe a valid ext2/ext3/ext4
filesystem.  If the device is valid and it really contains an ext2/ext3/ext4
filesystem (and not swap or ufs or something else), then the superblock
is corrupt, and you might try running e2fsck with an alternate superblock:
    e2fsck -b 8193 <device>
 or
    e2fsck -b 32768 <device>

/dev/loop0 contains a crypto_LUKS file system

A LUKS partition and e2fsck didn't change a single byte of it. Even if you add the force flag, this is safe.

However, the story is different if there was a ext filesystem on the LUKS device before:

e2fsck 1.43.9 (8-Feb-2018)
ext2fs_open2: Bad magic number in super-block
e2fsck: Superblock invalid, trying backup blocks...
Superblock has an invalid journal (inode 8).
Clear<y>? 

fsck starts asking questions, you're fine if you answer no, but screwed when you answer yes. fsck zeroes out LUKS key material, there is no way to recover.

You'd need to know the master key (if the luks container is still open, dmsetup table --showkeys) or a valid backup of the LUKS header.