recovering from lost partition table: a use case

This happened today and may be of use to other Ubuntu or Debian users with a similar configuration. The disk of a laptop lost its partition table because it was mistaken for a USB key and modified. There was no way to recover the old GPT partition table from the backup because it was not corrupted. The new partition table was both in the GPT partition table and its backup.

The laptop was installed with Ubuntu 16.04 about two years ago and it was assumed to:

  • Have an EFI partition
  • Have a separate boot partition

The partition table is rebuilt to start with a 512MB partition for EFI (type 1) followed by another parition for the rest of the disk. When the second partition table is created using fdisk, it will issue a warning about an ext2 signature: it must be preserved.

Using dumpe2fs on the second partition the actual size of the partition is displayed, for instance:

$ dumpe2fs /dev/nvme0n1p2
...
Block count:              249856
...
Block size:               1024

The partition table is adjusted accordingly, taking into account that filesystem blocks are 1024 bytes and fdisk sectors are 512 bytes (i.e. 249856 * 2 == 499712):

$ fdisk -l /dev/nvme0n1
Device           Start        End   Sectors   Size Type
/dev/nvme0n1p1    2048    1050623   1048576   512M EFI System
/dev/nvme0n1p2 1050624    1550335    499712   244M Linux filesystem

Note: for some reason fdisk adds 1 to the specified number of sectors in some cases. Care must be taken to verify the actual number of sectors allocated to the partition and adjust them accordingly.

The signature of the third partition gives a hint regarding its content. If it is crypto_LUKS, it can be open with cryptsetup luksOpen /dev/nvme0n1p3 root and the device will show under /dev/mapper.