SOLVED Restoring corrupted GPT Table?

[Durahl]

Greetings!

Can someone point me in the right direction when it comes to restoring a corrupted GPT Table?
I have practically no knowledge in when it comes to working with the CLI's gpart commands.

What I basically need to know are the commands to both successfully getting rid of the corrupted GPT and then creating a new working GPT for the System to stop nagging me - File recovery isn't an issue - I'm just trying to save the HDD.

The corrupted GPT sits on ata2 ( part of a 6 HDD Z2 ).

I assume that the cause for this lie in a broken SATA Connector so I'm pretty sure this not being a fault of the HDD - Which is brand new to begin with.

 

[Stux]

If you go to "View Disks" in the storage section, can you not just erase the disk?

 

[Durahl]

FreeNAS is offering me to "Wipe" the disk but it's not working as the following progress bar windows keeps on going and further interaction with the System ends in a database is locked situation which is why I'm looking for a more in depth solution that's exceeding my current knowledge.

Code:

[root@freenas ~]# gpart list ada0 
Geom name: ada0 
modified: false  
state: CORRUPT 
fwheads: 16 
fwsectors: 63 
last: 3907029134 
first: 34 
entries: 128 
scheme: GPT 
Consumers: 
1. Name: ada0
Mediasize: 2000398934016 (1.8T)
Sectorsize: 512
Stripesize: 4096
Stripeoffset: 0
Mode: r0w0e0

[root@freenas ~]#

Not really being a Linux / CLI Guy I'm kind of on a slow track when it comes to solving this...

So far I've various FreeNAS' gpart commands like gpart recover /dev/ada0 which returns the state to OK but in the end doesn't work as the system keeps going back to the perpetual progress bar thing whenever I attempt to do something with the Drive.

Meanwhile I've also dabbled into GParted Live ( both GUI and CLI ) doing things like copying the secondary GPT over to the primary GPT - I either didn't do that correct or it didn't help so my only thought would be to either destroying the MBR/GPT entirely and rebuilding it from scratch ( the latter of which I don't know how ) or copying a GPT Table from another, identical HDD, onto the corrupted one ( which I don't know how either as I couldn't find any tutorials ).

Like I said... Rescuing the files isn't my goal so all I'm worrying about right now is getting the brand new, but corrupted, HDD back online.

 

[Mirfster]

"gpart destroy -F <device>" may be the command you are wanting...

Reference this thread.

 

[Durahl]

Like I said, destroying the corrupt GPT isn't exactly the problem - I found plenty ( well... not exactly plenty ) of information regarding that.
The problem I have is restoring the GPT either via copying it from the secondary GPT or by copying a working primary GPT from a not corrupted HDD ( IF that is an option to begin with ).

In the meantime I've been using the following commands in an attempt to copying a working GPT from one HDD ( sda ) to another HDD ( sdb ) and then randomizing it's GUID for them to be recognized as a different HDDs again:
sgdisk --backup=table /dev/sda
sgdisk --load-backup=table /dev/sdb
sgdisk -G /dev/sdb

Didn't get me the results I wanted either...
FreeNAS still complains about the primary GPT being corrupt and the secondary one being used so either copying a GPT from one HDD to another doesn't work or I'm still using the wrong commands.
What's even more annoying is that when using the gpart recover ada0 command I receive the message that a recovery isn't necessary.

Any other ideas?

 

[Mirfster]

Like I said, destroying the corrupt GPT isn't exactly the problem

• You should not have to create any partitions, FreeNAS will do that itself.
  
• So did you simply do the command and wipe the disk?
• Is the disk currently part of any vDev?
• Did you ever try to connect it to a different SATA Port (since you mentioned a broken SATA Connector)?
• What is the output (In CODE Tags please) of zpool status?

 

[Durahl]

*sigh*

I'm terribly sorry for wasting your time... The issue was a hardware related one.
The whole system and everything it's made of is brand spanking new ( well... 2 weeks or so old ) so it being a hardware issue would have been my last thought.

The culprit, as it appears to be, was the Hot-Swap Connection Board for the 6 HDD's of my SilverStone SST-CS01B-HS...
As soon as I took it out of the equation by attaching the HDD's directly to the ASRock C2750D4I's SATA Ports every error I had up till now vanished - File transfer, an indicator if everything works, is now running smooth again.

Can't say I'm pleased about this as I'll obviously not be able to use a feature I paid extra for >_>

Thanks though for sticking with me.