Arch Linux

billboardroomba

Member

Registered: 2023-04-07

Posts: 7

[SOLVED]Mistakenly used fdisk to create and write a new parition table

I have 2 SSD, one 250 GB for Arch Linux (/dev/sda), another is for Windows (/dev/sdb). I also have a bootable flashdrive with a live os (/dev/sdc).

I booted my love os (Debian), and inserted another flashdrive (/dev/sdd) and my objective was to create a new partition table and format this /dev/sdd. However, I mistakenly formatted /dev/sda

sudo fdisk /dev/sda

Welcome to fdisk (util-linux 2.36.1).                                                                                                 
Changes will remain in memory only, until you decide to write them.
Be careful before using the write command.


Command (m for help): g
Created a new GPT disklabel (GUID: 772AF85F-3698-AD47-99A3-BD4469540D49).

Command (m for help): w
The partition table has been altered.
Calling ioctl() to re-read partition table.
Syncing disks.

Now, when I fdisk -l I am getting

Disk /dev/sda: 232.89 GiB, 250059350016 bytes, 488397168 sectors
Disk model: Samsung SSD 850 
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: gpt
Disk identifier: 772AF85F-3698-AD47-99A3-BD4469540D49

/dev/sda had 2 parts. /dev/sda1 for Boot and /dev/sda2 for data (ext4), the latter being LUKS encrypted.

I tried using testdisk but I am facing this issue:

TestDisk 7.1, Data Recovery Utility, July 2019
Christophe GRENIER <grenier@cgsecurity.org>
https://www.cgsecurity.org

Disk /dev/sda - 250 GB / 232 GiB - CHS 30401 255 63

The harddisk (250 GB / 232 GiB) seems too small! (< 748 GB / 697 GiB)
Check the harddisk size: HD jumper settings, BIOS detection...

The following partition can't be recovered:
     Partition               Start        End    Size in sectors
>  Linux filesys. data      1050624 1461854036 1460803413










[ Continue ]
LUKS 2 (Data size unknown), 747 GB / 696 GiB

I would really appreciate if someone can help me as I have some non-backuped files and I want to recover them by any means.

Thank you in advance.

Last edited by billboardroomba (2023-04-07 17:10:16)

frostschutz

Member

Registered: 2013-11-15

Posts: 1,637

Re: [SOLVED]Mistakenly used fdisk to create and write a new parition table

It says LUKS 2, (Data size unknown) makes sense since LUKS [usually] doesn't care about device size. It just takes the size of whatever device you give it. So I'm not sure how Testdisk decides it should be 697 GiB large.

Did you use LUKS 2 at all? If so, I just posted a recovery guide recently over here: https://unix.stackexchange.com/a/741850/30851

It can help you recover both the LUKS 2 header as well as the correct partition offset. If your header is undamaged the offset is all you need and you can ignore the other recovery steps.

If you didn't use LUKS then whatever Testdisk sees here is bogus.

Do you have any logfiles? If you didn't reboot you can check dmesg. It might not record the partition sizes but it would at least tell us how many partitions we're looking for.

If you used MiB alignment you can create a partition at offset 1MiB, see what appears, and derive the partition size and following partitions from there. Works for almost all data... except LUKS which does not record the size. Most other things do.

Just don't create partitions in the MSDOS extended/logical scheme... that does damage data if you create them the wrong way.

Last edited by frostschutz (2023-04-07 14:22:50)

billboardroomba

Member

Registered: 2023-04-07

Posts: 7

Re: [SOLVED]Mistakenly used fdisk to create and write a new parition table

It says LUKS 2, (Data size unknown) makes sense since LUKS [usually] doesn't care about device size. It just takes the size of whatever device you give it. So I'm not sure how Testdisk decides it should be 697 GiB large.

Did you use LUKS 2 at all? If so, I just posted a recovery guide recently over here: https://unix.stackexchange.com/a/741850/30851

It can help you recover both the LUKS 2 header as well as the correct partition offset. If your header is undamaged the offset is all you need and you can ignore the other recovery steps.

If you didn't use LUKS then whatever Testdisk sees here is bogus.

Do you have any logfiles? If you didn't reboot you can check dmesg. It might not record the partition sizes but it would at least tell us how many partitions we're looking for.

If you used MiB alignment you can create a partition at offset 1MiB, see what appears, and derive the partition size and following partitions from there. Works for almost all data... except LUKS which does not record the size. Most other things do.

Just don't create partitions in the MSDOS extended/logical scheme... that does damage data if you create them the wrong way.

Thank you for your prompt reply. This arch installation was done on January this year and I followed the official wiki for installation, so indeed I used LUKS2. I am also puzzled why testdisk is saying that the file is almost 3x the ssd size.

I haven't yet restarted my system yet. Here is the dmesg:

Last edited by billboardroomba (2023-04-11 12:26:07)

frostschutz

Member

Registered: 2013-11-15

Posts: 1,637

Re: [SOLVED]Mistakenly used fdisk to create and write a new parition table

Let's just assume it's MiB aligned then.

You can create a read-only loop device at offset 1 MiB.

losetup --find --show --read-only --offset=$((1024*1024)) /dev/sda

Then check if it's anything like a filesystem.

file -s /dev/loopX

If it's a filesystem you can mount it read-only somewhere, check if it has files, and more importantly check its size (with df, or filesystem specific tool depending on filesystem type. in case of ext2, you'd check tune2fs -l).

Then you can just add the filesystem size to the offset, make another loop device and see if it has your LUKS header. Or you find the LUKS header offset using strings and grep. Either way works.

Once you know the exact offsets, just create new partitions accordingly.

Last edited by frostschutz (2023-04-07 14:31:43)

billboardroomba

Member

Registered: 2023-04-07

Posts: 7

Re: [SOLVED]Mistakenly used fdisk to create and write a new parition table

Let's just assume it's MiB aligned then.

You can create a read-only loop device at offset 1 MiB.

losetup --find --show --read-only --offset=$((1024*1024)) /dev/sda

Then check if it's anything like a filesystem.

file -s /dev/loopX

If it's a filesystem you can mount it read-only somewhere, check if it has files, and more importantly check its size (with df, or filesystem specific tool depending on filesystem type. in case of ext2, you'd check tune2fs -l).

Then you can just add the filesystem size to the offset, make another loop device and see if it has your LUKS header. Or you find the LUKS header offset using strings and grep. Either way works.

Once you know the exact offsets, just create new partitions accordingly.

I received this:

/dev/loop0: DOS/MBR boot sector, code offset 0x58+2, OEM-ID "mkfs.fat", sectors/cluster 8, Media descriptor 0xf8, sectors/track 63, heads 255, hidden sectors 2048, sectors 1046493 (volumes > 32 MB), FAT (32 bit), sectors/FAT 1024, serial number 0x3ed43fea, unlabeled

I am really sorry for my ignorance but I would really appreciate if you can kindly tell me how I can create the new partitions from the offsets. I don't want to redo any errors and make it totally unrecoverable.

Again, I am very sorry for being a complete noob in these matters. I have been using Arch for a couple of years, but had never faced this kind of issue before.

Last edited by billboardroomba (2023-04-07 14:40:39)

frostschutz

Member

Registered: 2013-11-15

Posts: 1,637

Re: [SOLVED]Mistakenly used fdisk to create and write a new parition table

can you run `fsck.fat -nvV /dev/loop0` on it?

Edit: Oh, it says 1046493 sectors... so add those plus MiB alignment until you find a LUKS 2 header, it should be somewhere in this area.

Edit2:

So it's roughly 510 MiB

losetup --find --show --read-only --offset=$((510*1024*1024)) /dev/sda

then check file -s or cryptsetup luksDump if it's LUKS, if not replace 510 with 511, 512, 513, 514, 515, ...

Last edited by frostschutz (2023-04-07 14:56:02)

billboardroomba

Member

Registered: 2023-04-07

Posts: 7

Re: [SOLVED]Mistakenly used fdisk to create and write a new parition table

can you run `fsck.fat -nvV /dev/loop0` on it?

Edit: Oh, it says 1046493 sectors... so add those plus MiB alignment until you find a LUKS 2 header, it should be somewhere in this area.

Edit2:

So it's roughly 510 MiB

losetup --find --show --read-only --offset=$((510*1024*1024)) /dev/sda

then check file -s or cryptsetup luksDump if it's LUKS, if not replace 510 with 511, 512, 513, 514, 515, ...

On 513, I found this:

Up till 512 I was getting

/dev/loop2 is not a valid LUKS device.

Last edited by billboardroomba (2023-04-11 12:26:33)

frostschutz

Member

Registered: 2013-11-15

Posts: 1,637

Re: [SOLVED]Mistakenly used fdisk to create and write a new parition table

OK great. So 1st partition starts at 1 MiB, and 2nd partition at 513 MiB.

You can do it with parted /dev/sda

mklabel gpt
mkpart boot 2048s 1050623s
set 1 esp on
mkpart arch 1050624s 488397134s 
unit mib
print free

something like that

Turns out Testdisk did find the correct offset earlier, no idea why it complained about the device size though.

billboardroomba

Member

Registered: 2023-04-07

Posts: 7

Re: [SOLVED]Mistakenly used fdisk to create and write a new parition table

OK great. So 1st partition starts at 1 MiB, and 2nd partition at 513 MiB.

You can do it with parted /dev/sda

mklabel gpt
mkpart boot 2048s 1050623s
set 1 esp on
mkpart arch 1050624s 488397134s 
unit mib
print free

something like that

Turns out Testdisk did find the correct offset earlier, no idea why it complained about the device size though.

I received this output from print free

Model: 
Disk /dev/sda: 238475MiB
Sector size (logical/physical): 512B/512B
Partition Table: gpt
Disk Flags: 

Number  Start    End        Size       File system  Name  Flags
        0.02MiB  1.00MiB    0.98MiB    Free Space
 1      1.00MiB  513MiB     512MiB                  boot  boot, esp
 2      513MiB   238475MiB  237962MiB               arch

Is it safe to restart the system now?

Last edited by billboardroomba (2023-04-11 12:26:55)

frostschutz

Member

Registered: 2013-11-15

Posts: 1,637

Re: [SOLVED]Mistakenly used fdisk to create and write a new parition table

Only one way to find out... if it still doesn't work, at most you'll have to fix the bootloader setup. As long as the partition offset is correct now, you should be able to access your data.

The partition size is maxed out in this example. It's usually better to have the [last] partition a few sectors too large than too small, so this is just in case.

If LUKS used 4K sectors this would be a problem since it turns out with an odd number of sectors (not 4K aligned), but according to your luksDump it's 512 byte sector size, so it's fine for now.

Last edited by frostschutz (2023-04-07 15:47:49)

billboardroomba

Member

Registered: 2023-04-07

Posts: 7

Re: [SOLVED]Mistakenly used fdisk to create and write a new parition table

Only one way to find out... if it still doesn't work, at most you'll have to fix the bootloader setup. As long as the partition offset is correct now, you should be able to access your data.

The partition size is maxed out in this example. It's usually better to have the [last] partition a few sectors too large than too small, so this is just in case.

If LUKS used 4K sectors this would be a problem since it turns out with an odd number of sectors (not 4K aligned), but according to your luksDump it's 512 byte sector size, so it's fine for now.

I am trying to manually open it using cryptsetup open but I am receiving this:

sudo cryptsetup open /dev/sda2 mydata
Enter passphrase for /dev/sda2: 
Cannot use device /dev/sda2 which is in use (already mapped or mounted).

frostschutz

Member

Registered: 2013-11-15

Posts: 1,637

Re: [SOLVED]Mistakenly used fdisk to create and write a new parition table

remove the loop devices created earlier (losetup -D)

otherwise check if already open (dmsetup table, lsblk, df -h, ...)

Last edited by frostschutz (2023-04-07 16:29:36)

billboardroomba

Member

Registered: 2023-04-07

Posts: 7

Re: [SOLVED]Mistakenly used fdisk to create and write a new parition table

remove the loop devices created earlier (losetup -D)

otherwise check if already open (dmsetup table, lsblk, df -h, ...)

Thanks a lot for all your help. I was able to backup the data and after changing the UUID in the boot loader, it is booting without any problems. I am currently writing this from the Arch system. Again, thanks a lot! I would have never been able to do any of this without your guidance.

Last edited by billboardroomba (2023-04-07 17:09:31)