Recovering lost partition table with TestDisk

Question

So, somehow the partition table on my disk went bananas: at the next boot the system would not start, I got repeatedly kicked in the BIOS and I had no viable boot options. The BIOS still detected the disks properly, so I started a LiveDVD to see what's going on.

So, in the disk with the OS, /dev/sdb, 128GB SSD, there is no partition table. Both gpart and fdisk report it empty. fdisk report the disklabel type to be gpt.

I tried running testdisk, which identifies the partition table type to be Intel (and not EFI GPT). I tried searching for partitions with both types, but only Intel was successful.

So, first question: is Intel partition type a MBR? Why does EFI GPT not work even if the disk label is GPT?

When starting, the tool finds this partition only:

 Disk /dev/sdb - 128 GB / 119 GiB - CHS 15566 255 63
      Partition               Start        End    Size in sectors
1 P EFI GPT                  0   0  2 15566  29 63  250069679

When I run a Quick Search (or even a full search), the tool finds some partitions, and among these there are 5 partitions that make sense:

FAT32                    0  32 33    33  69 36     532480 [SYSTEM]
Linux                   33  69 37   163 207 44    2097152
Linux Swap             163 240 14   931  97 62   12328960
Linux                  931  97 63  9038 187 45  130244608
Linux                 9038 187 46 15565 209  4  104857600

Second question is related to the values displayed: there are 3 values in the start column (e.g. 0 32 33) and 3 in the end column (e.g. 33 69 36), how do I interpret these values?

If I look inside these partitions, using the P: list file command, I can see that

The first partition contains EFI stuff, such as

drwxr-xr-x     0     0         0 31-Jan-2019 19:26 EFI
drwxr-xr-x     0     0         0 13-Mar-2019 18:29 System
-rwxr-xr-x     0     0         0 21-May-2019 10:55 mach_kernel;5ce3af18
-rwxr-xr-x     0     0        34 13-Mar-2019 18:29 mach_kernel
drwxr-xr-x     0     0         0 26-Oct-2018 00:52 8310a92cdfe04b36b5a63736b6419b48

The second partition is the boot partition, contains efi, grub2, vmlinuzs etc. The fourth partition contains home folders and the last one contains the root.

Since I can see the files, I recovered /etc/fstab and /etc/lvm/, which indeed show that the system was configured using LVM.

I am not sure if partitions were extended/logical in some way, I don't even know if that makes sense with GPT and it's not limited to MBR.

Third question, given that testdisk can identify some partitions, I could try to restore the partition table using those values, but what about LVM? What about GPT? How can I restore the previous situation, given that these partitions seem to be properly identified?

Thanks a lot!

EDIT: I throw in the question regarding the extended partitions because apparently I have no way to set them all to primary (this make me think it's MBR) and I would need an extended one, but I am unable to create it.

EDIT 2: Here all the partitions found by an in depth search:

Disk /dev/sdb - 128 GB / 119 GiB - CHS 15566 255 63
     Partition               Start        End    Size in sectors
>* FAT32                    0  32 33    33  69 36     532480 [SYSTEM] *
 P Linux                   33  69 37   163 207 44    2097152 *
 P Linux Swap             163 240 14   931  97 62   12328960 *
 D Linux                  931  97 63  9038 187 45  130244608 *
 D Linux                 4873  98 26 12980 188  8  130244608
 D Linux                 4875  43 33 12982 133 15  130244608
 D Linux                 9038 187 46 15565 209  4  104857600 *
 D FAT12                 9695 133 39  9695 198 39       4096
 D HPFS - NTFS          15502 117 40 15566  19  5    1021952

The partitions with files are 1st (EFI), 2nd (/boot), 4th (/home), 7th (/). I marked with a * at the end of the line the apparently legit partitions.

Edit

I ended up copying the drive with dd, reinstalling the OS and recovering the data by mounting the old partitions in this way.

Answer 1

Before you go any further create (dd) an image of the disk that you can use to restore it if things go badly wrong.

It seems from your post that you have read the TestDisk guide. If not best to read it.

Question 1

Testdisk should identify the available partition types automatically and the fact that it found an INTEL partition is not a worry. You found the partitions, verified the content by examination, they are what you want to recover. Don't forget that testdisk is using the same schema to find your files that it will write to to a repaired partition table. So that all looks good.

Question 2

If you look at the guide you should be able to see that the figures you are interested in are the first figures in the start and finish column. When these are contiguous then the partitions don't have gaps between them and it is likely that they are part of a coherent partition schema. This is good and, again, the fact that testdisk can use the partition table it has created/inferred from the disk to get down to file level is again confidence inspiring.

The only issue that gives me any cause for concern is that the start and end addresses are the same and not consecutive. That said, testdisk should choke if you ask it to write an invalid table.

Question 3 .... should i...?

LVM will not be seen at this level but will be picked up at boot when the repaired OS loads the LVM modules and reads the LVM layout from your resurrected system.

GPT / MBR are just different formats of partition table. Since the one being used by testdisk finds your files it is the one you should use in recovery.

In your position I would proceed and repair the table as per the schema you list safe and confident in knowing that I had prepared an image that I can restore to the original disk and try again if it goes wrong.

If it's any comfort I had a 1TB drive go ping and went through similar pangs deciding what to do. In the end all went well using the default schema selected by testdisk but I had a backup in my hand.....just in case.

If there are a lot of partitions to choose from then I suggest you post the complete output and then you may get some more specific assistance.

Edit

TBH I am a little nonplussed with the 5 partitions/MBR conundrum.

The best I can offer is what I would do in your situation, which is make copies of the image, attempt to recover one more partitions as MBR from each image (by mounting the image in testdisk, not the SSD) and then reconstruct the original disk on new media with a GPT schema. If that works then migrate the whole shebang back to your SSD. You would need to reinstall grub and play with the GUIDs in fstab when you migrate back to make everything mount but that is not rocket science.

The bottom line is that you can try whatever you like on copies of the image without fear. Just keep the original drive and one image safe.