Restore drive GPT partition table [SOLVED]

[geo_c]

This post will describe how to approach restoring a USB drive with a corrupted GPT, or MBR structure.

The following is a description of the disk failure that prompted me to find a partition table repair method.

The drive:

3.5TB USB EFI hard drive with 4 partitions:

• 1-NTFS (place holder to allow MS windows to see the contents on partition 4)

• 2-ext4 (puppy installation partition containing frugal installs)

• 3-ext4 (linux formatted bulk data partition)

• 4-NTFS (windows formatted bulk data partition mirroring partition 3)

I've been using this drive for a few years to boot puppies off partition #2. I went to check the boot flag and initiated g-parted, but it reported just one 3.5TB empty partition of unallocated space. The reason I ran g-parted was because grub4dos reported that there wasn't a boot flag while doing a frugal install on partition #2. Which seemed unusual.

I ran fdisk in the terminal and got this output:

Code: Select all

The primary GPT table is corrupt, but the backup appears OK, so that will be used.
Disk /dev/sdb: 3.65 TiB, 4000787029504 bytes, 784037167 sectors
Disk model: BUP Portable
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (mininum/optimal): 4096 bytes / 4096 bytes
Disklabel type: gpt
Disk identifier: 5483CBF3-2749-439F-9AD6-08DCBAB79A8D

Device         Start  End  Sectors Size       Type
/dev/sdb1     ---------------------------- EFI System
/dev/sdb2     ---------------------------- 82.5G Linux filesystem
/dev/sdb3     ---------------------------- 1.8T Linux filesystem
/dev/sdb4     ---------------------------- 1.8T Microsoft basic data

note: dashes are fillers for the numeric values I didn't feel like typing

So apparently the partitions, and data were most likely still intact, as the sizes of the partitions and start and end sectors seemed to make sense, but more importantly fdisk reported that the backup GPT table was OK. So there was no guarantee that it could be re-stored, but there was still a chance.

The question was: what should I do next to restore the gpt table?

continued below....

[geo_c]

After a quick internet search, next I ran the terminal command: gdisk -l
and it returned the following:

root# gdisk -l /dev/sdb
GPT fdisk (gdisk) version 1.0.4

Caution: invalid main GPT header, but valid backup; regenerating main header
from backup!

Warning: Invalid CRC on main header data; loaded backup partition table.
Warning! Main and backup partition tables differ! Use the 'c' and 'e' options
on the recovery & transformation menu to examine the two tables.

Warning! Main partition table CRC mismatch! Loaded backup partition table
instead of main partition table!

Warning! One or more CRCs don't match. You should repair the disk!
Main header: ERROR
Backup header: OK
Main partition table: ERROR
Backup partition table: OK

Partition table scan:
MBR: protective
BSD: not present
APM: not present
GPT: damaged

****************************************************************************
Caution: Found protective or hybrid MBR and corrupt GPT. Using GPT, but disk
verification and recovery are STRONGLY recommended.
****************************************************************************
Disk /dev/sdb: 7814037167 sectors, 3.6 TiB
Model: BUP Portable
Sector size (logical/physical): 512/4096 bytes
Disk identifier (GUID): 5483CBF3-2749-439F-9AD6-08DCBAB79A8D
Partition table holds up to 128 entries
Main partition table begins at sector 2 and ends at sector 33
First usable sector is 34, last usable sector is 7814037133
Partitions will be aligned on 2048-sector boundaries
Total free space is 3692 sectors (1.8 MiB)

Number Start (sector) End (sector) Size Code Name
1 2048 1282047 625.0 MiB EF00 head
2 1282048 174338047 82.5 GiB 8300 sysA
3 174338048 3994187775 1.8 TiB 8300 dbox
4 3994187776 7814035455 1.8 TiB 0700 dbox
root#

There appeared to be even more hope of recovery, because both the backup header, and backup GPT table were OK, as can be seen in the middle of the above gdisk output.

At this point with the help of forum members I used the following web page as guide to restoring the disk:https://www.rodsbooks.com/gdisk/repairing.html

The solution was actually quite simple in this case.

• 1st run the command: gdisk /dev/sdb (which produces the above output)

• at the gdisk command prompt enter r to run the repair menu

• next enter the bc command options to load the backup table and header

• Lastly, enter the w command option to write the header and table to disk.

Of course proceed with caution! In this case the corruption was easily corrected by intact backup files. If that were not the case, then rewriting the header and table could cause an irrecoverable situation.

And so my disk is working, and I will be going to the store to find another 3.5TB USB drive to make a backup copy.

[geo_c]

HOORAY! gdisk worked, I've got my partitions back. Thanks everyone especially @wiak for the links

[williams2]

Safest thing would be to mount each partition (read only if possible,) then back up files that you do not want to lose.
You might need another 4T drive to do that.
And it would probably take a long time.

The back up partition table seems to make sense.
Each partition seems to have reasonable start and end numbers.
You could probably fix it and get your partitions back again (without errors.)
(no guaranties that data would not be lost)

I've never had this problem, so I can't recommend a particular approach.
The repair programs in Puppy might be all you need.
Or you might need to download and install an application.

Installing a legacy boot loader on the master boot record would probably write over the gpt partition table.
Or repartitioning a gpt as if it was a dos partition table.
Older versions of Grub4dos could do this.

EDIT:

HOORAY! gdisk worked

Good, I thought fdisk or gdisk or fsck might work, because the partition numbers seemed to make sense.

[geo_c]

@williams2 yes, I simply had to run the r -bc commands to restore the backup GPT header, and restore the backup GPT partition table, and then w to write them to the disk.

I'm always confused about how to boot flag an efi drive. This one was difficult to set up in the past, getting the boot flags right, and doesn't boot on every machine. It's main function is data storage, but I tend to put boot partitions on my data disks just because PUPPY CAN DO THAT! And why not be able to boot my OS when accessing my data? It also serves as a backup for my OS's, because it's an install that mirrors my sda drives, so I backup my pupsaves to it also. I have of a few other drives with duplicate data.

As it is, I haven't tried to see if I can boot from it yet. I can access all the partitions, and that's a good start.

I do have all of this data in other places, but I would have to carefully assemble it one place to duplicate this particular drive. So I may be buying another big drive and doing a copy.

[wiak]

HOORAY! gdisk worked, I've got my partitions back! Thanks everyone who especially @wiak for the links!

Glad to hear that. Well done! Gave me food for thought too - never had that issue but always feared it!

[Clarity]

Hello @geo_c Good to know steps you followed worked.

I ask

• Would you edit your opening post of this thread and show the flow and the steps you took to recovering the partition table of that drive?

If its not too much of a problem, I think that single post updated with your explanation would be useful to many others AND would all be containing in that single post your would edit.

I did have a similar problem with a USB drive last year. The contents of it was incidental so it was no hardship to destroy and rebuild. But that was not the path I should have taken and your efforts shown probably would have instantly solve that phenom.

If you have time, I am sure many others in the future will find this thread of enormous help.

Again, I am glad to see your efforts paid off.

[geo_c]

Hello @geo_c Good to know steps you followed worked.

I ask

• Would you edit your opening post of this thread and show the flow and the steps you took to recovering the partition table of that drive?

Good idea, I'll do that.

[williams2]

I'm always confused about how to boot flag an efi drive. This one was difficult to set up in the past, getting the boot flags right, and doesn't boot on every machine.

The old (legacy) BIOS was very limited.
It does not understand partitions or file systems or boot flags at all.
It can find the MBR (Master Boot Record), that is, the first 512 bytes of the first hard drive.
(Older hard drives used to be made up of 512 byte blocks of data. Newer hard drives now have 4k blocks of data)
Mostly, what the BIOS does, is find the MBR, then copy the code in the MBR to ram,
then the BIOS starts executing the MBR code that is in ram.

At this point, the BIOS has done it's job. It is the tiny (about 460 bytes) MBR program that is executing now.

The tiny MBR code is just smart enough to find the first partition which has the boot flag set.
The BIOS does not try to find a partition that has the boot flag set.
The BIOS finds and executes the MBR code.

The MBR code finds the first partition that has the boot flag set.
If the MBR code does not find a bootable partition, it stops with an error message something like NTLDR not found. (for a WinXP MBR)
If the MBR code finds a partition with the boot flag set,
it copies the code in the first 512 bytes of that partition (the Boot Record) to ram and executes it.
The MBR code has done it's job.

The code in the Boot Record finds the kernel loader and copies it to ram and executes it.
The kernel loader will be something like WinXP's NTLDR, or it could be a Linux boot loader, like syslinux.sys or GRLDR.

So, the BIOS finds and executes the MBR.
The MBR finds and executes the Boot Record of the first bootable partition.
The BR code finds and executes the Win or Linux boot loader.

UEHI is much smarter than BIOS. It understands file systems and partitions.
It can find folders/directories named /boot/ and can find files and folders in /boot/ that it can use to start the operating systems.

I'm not sure if UEHI ignores boot flags or not.
The UEHI does ignore the MBR and the partition Boot Records. (they are mostly filled with zeros on a gpt system)
If you try to install a legacy boot loader to the MBR of a gpt hard drive, it will probably write over the gpt partition table. You could lose most if not all of the data on that drive.

[Phoenix]

UEFI looks for an esp partition to boot off of.

[Clarity]

I purposely corrupted a primary partition table on a USB stick.

The following demonstrates @geo_c's "instructions to repair", from this thread's opening post.

• root# fdisk /dev/sdc # test the primary USB disk

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

  The backup GPT table is corrupt, but the primary appears OK, so that will be used.

  Command (m for help): q

  root#
  root# gdisk -l /dev/sdc # test the primary USB disk using 'gdisk'
  GPT fdisk (gdisk) version 1.0.4

  Warning! Disk size is smaller than the main header indicates! Loading
  secondary header from the last sector of the disk! You should use 'v' to
  verify disk integrity, and perhaps options on the experts' menu to repair
  the disk.
  Caution: invalid backup GPT header, but valid main header; regenerating
  backup header from main header.

  Warning! One or more CRCs don't match. You should repair the disk!
  Main header: OK
  Backup header: ERROR
  Main partition table: OK
  Backup partition table: OK

  Partition table scan:
  MBR: protective
  BSD: not present
  APM: not present
  GPT: damaged

  ****************************************************************************
  Caution: Found protective or hybrid MBR and corrupt GPT. Using GPT, but disk
  verification and recovery are STRONGLY recommended.
  ****************************************************************************
  Disk /dev/sdc: 398297087 sectors, 189.9 GiB
  Model: L200P0
  Sector size (logical/physical): 512/512 bytes
  Disk identifier (GUID): 688CCDDE-9116-4E60-8111-A90241DCCEA5
  Partition table holds up to 128 entries
  Main partition table begins at sector 2 and ends at sector 33
  First usable sector is 34, last usable sector is 398297054
  Partitions will be aligned on 8-sector boundaries
  Total free space is 2021 sectors (1010.5 KiB)

  Number Start (sector) End (sector) Size Code Name
  1 2048 398231511 189.9 GiB 0700 Ventoy
  2 398231512 398297047 32.0 MiB 0700 VTOYEFI
  root#
  root# fdisk /dev/sdd # test the other USB disk

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

  Command (m for help): q

  root#
  root# echo "This sdd USB is OK, while the sdc USB is corrupted"
  This USB is OK, while the sdc USB is corrupted
  root#
  root# root# gdisk /dev/sdc # repair the primary USB disk
  GPT fdisk (gdisk) version 1.0.4

  Warning! Disk size is smaller than the main header indicates! Loading
  secondary header from the last sector of the disk! You should use 'v' to
  verify disk integrity, and perhaps options on the experts' menu to repair
  the disk.
  Caution: invalid backup GPT header, but valid main header; regenerating
  backup header from main header.

  Warning! One or more CRCs don't match. You should repair the disk!
  Main header: OK
  Backup header: ERROR
  Main partition table: OK
  Backup partition table: OK

  Partition table scan:
  MBR: protective
  BSD: not present
  APM: not present
  GPT: damaged

  ****************************************************************************
  Caution: Found protective or hybrid MBR and corrupt GPT. Using GPT, but disk
  verification and recovery are STRONGLY recommended.
  ****************************************************************************

  Command (? for help): r

  Recovery/transformation command (? for help): bc

  Recovery/transformation command (? for help): w
  Caution! Secondary header was placed beyond the disk's limits! Moving the
  header, but other problems may occur!

  Final checks complete. About to write GPT data. THIS WILL OVERWRITE EXISTING PARTITIONS!!

  Do you want to proceed? (Y/N): y
  OK; writing new GUID partition table (GPT) to /dev/sdc.
  Warning: The kernel is still using the old partition table.
  The new table will be used at the next reboot or after you
  run partprobe(8) or kpartx(8)
  The operation has completed successfully.

  root#
  root# gdisk /dev/sdc # status of the primary USB disk
  GPT fdisk (gdisk) version 1.0.4

  Partition table scan:
  MBR: protective
  BSD: not present
  APM: not present
  GPT: present

  Found valid GPT with protective MBR; using GPT.

  Command (? for help): q

  root# reboot # Reboot to complete system update for proper use

Thanks @geo_c.