Arch Linux

zgR3Vr

Member

Registered: 2020-05-18

Posts: 22

[Solved] Accidentally created new partition table on LUKS disk

Hello.
I did something extremely stupid to my LUKS partition, and now I can't mount it anymore.

Just to get it out of the way, yes, I have already made a complete backup of the disk with dd before I tried with any of these commands.

Here is the background story to what I did.
I were in the middle of making some changes with fdisk. Here I unfortunately didn't think when I wrote which drive to modify, which ended up being my root LUKS partition. Just to be clear, that means I selected:

/dev/mapper/rootfs

and NOT a disk. Here fdisk automatically created a new dos partition table (because fdisk didn't recognize the partition table), aaand I accidentally pressed W and wrote the changes.
In panic I rebooted the computer (looking back, I should definitely not have done that), and as I did expect, my computer booted into GRUB, where it asked for my decryption password. I did however not get any further than this. The output I got is the following:

Starting version 248-3-arch
A password is required to access the rootfs volume:
Enter passphrase for /dev/sda2:
ERROR: device 'UUID=xxx-xxx-xxx' not found. Skipping fsck.
mount: /new_root: can't find UUID=xxx-xxx-xxx.
You are now being dropped into an emergency shell.

My boot partition is not encrypted, hence why it is able to boot into GRUB. Here i my partition layout.

nvme0n1  
    nvme0n1p1 (efi)  
    nvme0n1p2 (LUKS partition)

I made an arch live USB, and quickly went to the internet to search for a possible solution to my problem.
At first I thought that I had fucked my LUKS header or something like it. This doesn't seem to be the problem, since I am still able to unlock the partition. I just can't mount it. The output I get is: wrong fs type, bad option, bad superblock on /dev/mapper/rootfs, missing codepage or helper program, or other error.
I have tried to use testdisk to see if I could recover the partition itself (I ran testdisk on /dev/mapper/rootfs). I have tried to scan with Intel/PC partition and EFI/GPT. Here it did find a lot of partitions, but when it finally finishes scanning, I am told that the majority of the linux partitions it finds can't be recovered. The ones I am able to recover is ether damaged or contains nothing.

My question now is if I would be able to get the EXT4 filesystem back on the encrypted drive, together with the files? I tried to run Photorec on the encrypted disk, and here it did indeed find a ton of files. I would just like to be sure that I am not able to recover the EXT4 fs on the disk, before I take the file recovery route.
I have been told that it might be possible to recover the filesystem, if I haven't overwritten it. I just don't know if the DOS partition table fdisk created (and I wrote to disk :/), could have overwritten the filesystem itself.

Does anyone have a good idea I could try out?
Thanks.

Last edited by zgR3Vr (2021-04-15 15:00:30)

damjan

Member

Registered: 2006-05-30

Posts: 452

Re: [Solved] Accidentally created new partition table on LUKS disk

Try fsck.ext4 on the /dev/mapper/rootfs … ideally fdisk should have only destroyed the first 512 bytes of the volume and fsck might recover from it

progandy

Member

Registered: 2012-05-17

Posts: 5,193

Re: [Solved] Accidentally created new partition table on LUKS disk

You could try to find positions for the backup super block like this https://unix.stackexchange.com/a/49574
(A EFI GPT partition table normally has a backup table at the end of the disk as well, so the last blocks may be gone in addition to the first few blocks)

But in the end you should recreate the partition.

Last edited by progandy (2021-04-15 15:06:29)

---

| alias CUTF='LANG=en_XX.UTF-8@POSIX ' |

zgR3Vr

Member

Registered: 2020-05-18

Posts: 22

Re: [Solved] Accidentally created new partition table on LUKS disk

Try fsck.ext4 on the /dev/mapper/rootfs … ideally fdisk should have only destroyed the first 512 bytes of the volume and fsck might recover from it

I am not currently at the computer with the problem, but I have recreated it on another PC, and here it seems like all the files are back after running fsck.ext4 -y /dev/mapper/rootfs.
It did however give a lot of output, saying that inodes contained garbage. That is also why I used -y.

I will report back later today, when I am at the actual problematic computer.

zgR3Vr

Member

Registered: 2020-05-18

Posts: 22

Re: [Solved] Accidentally created new partition table on LUKS disk

You could try to find positions for the backup super block like this https://unix.stackexchange.com/a/49574
(An EFI partition table normally has a backup table at the end of the disk as well, so the last blocks may be gone in addition to the first few blocks)

But in the end you should recreate the partition.

I have tried something like it, but not exactly as they do here. If the idea from damjan doesn't work, I will have a go with this.

zgR3Vr

Member

Registered: 2020-05-18

Posts: 22

Re: [Solved] Accidentally created new partition table on LUKS disk

Try fsck.ext4 on the /dev/mapper/rootfs … ideally fdisk should have only destroyed the first 512 bytes of the volume and fsck might recover from it

You sir, are a literal GODSENT! You have saved my ass from sitting through a cleanup task of the files photorec could recover.
THANK YOU so much!!