Solved secondary gpt table corrupt recovery suggested

[balanga]

What is the suggested recovery procedure if you get

the secondary GPT table is corrupt or invalid - recovery suggested

I found this link from eight years ago.

Does it still apply?

 

[SirDice]

Is this disk part of a ZFS pool? In that case you need to be careful.

 

[balanga]

Is this disk part of a ZFS pool? In that case you need to be careful.

It's a 320GB GPT disk with 12 partitions:

root@:~ # gpart show ada0
=>       34  625142381  ada0  GPT  (298G) [CORRUPT]
         34       2014        - free -  (1.0M)
       2048  100720640     1  ms-basic-data  (48G)
  100722688      65536     2  ms-basic-data  (32M)
  100788224    1048576     3  freebsd-ufs  (512M)
  101836800   10485760     4  freebsd-ufs  (5.0G)
  112322560    1114760        - free -  (544M)
  113437320   20971520     7  freebsd-ufs  (10G)
  134408840       1400        - free -  (700K)
  134410240   10485760     8  linux-data  (5.0G)
  144896000   20971520     9  linux-data  (10G)
  165867520    2097152    10  linux-data  (1.0G)
  167964672   10485760    11  linux-data  (5.0G)
  178450432  446691976    12  freebsd-ufs  (213G)
  625142408          7        - free -  (3.5K)

root@:~ # fsck /dev/ada0p1
Attempted recovery for standard superblock: failed
Attempted extraction of recovery data from standard superblock: failed
Attempt to find boot zone recovery data.
Finding an alternate superblock failed.
Check for only non-critical errors in standard superblock
Failed, superblock has critical errors
SEARCH FOR ALTERNATE SUPER-BLOCK FAILED. YOU MUST USE THE
-b OPTION TO FSCK TO SPECIFY THE LOCATION OF AN ALTERNATE
SUPER-BLOCK TO SUPPLY NEEDED INFORMATION; SEE fsck_ffs(8)

ffsck_ffs() seems fairly complicated.

I'm aware that the disk may suddenly fail, but I'd like to fix whatever I can.

 

[SirDice]

It's a 320GB GPT disk with 12 partitions:

Ok, in that case it is safe to restore the secondary table; gpart recover /dev/ada0

For some reason the secondary table (stored at the end of disk) is missing, or got corrupted. See the "RECOVERING" section in gpart(8).

fsck_ffs(8) seems fairly complicated.

File system recovery a fairly complicated operation. But why are you trying to use a tool intended for UFS (fsck_ffs(8) is specific to UFS) on, what looks like, a Windows (probably NTFS) data partition? There is a fsck_msdosfs(8) but that's specifically for FAT. Those Windows ms-basic-data partitions are typically NTFS.

 

[balanga]

Ok, in that case it is safe to restore the secondary table; gpart recover /dev/ada0

For some reason the secondary table (stored at the end of disk) is missing, or got corrupted. See the "RECOVERING" section in gpart(8).

Many thanks, that worked.

File system recovery a fairly complicated operation. But why are you trying to use a tool intended for UFS (fsck_ffs(8) is specific to UFS) on, what looks like, a Windows (probably NTFS) data partition? There is a fsck_msdosfs(8) but that's specifically for FAT. Those Windows ms-basic-data partitions are typically NTFS.

My mistake. It was actually an ext4 partition, and I'd forgotten to run the appropriate command. I'll have modify the partition type now that I know how.

Hopefully this post will come up near the top of searches for the topic rather than the link I mentioned in my first post.