# GPT Rejected - how to wipe for ZFS?



## CelticWhisper (Nov 28, 2015)

I'm setting up a RAIDZ2 pool on a NAS I've built and I have one disk throwing the "GPT Invalid or corrupt" error.  As I understand it, I can use ZFS on raw disks without partitioning and would prefer, if possible, to just remove the partition table on this disk (or all of my disks, for that matter) and let ZFS handle everything.

Either way, I'd prefer not to have a zpool with one disk exhibiting a problem that none of the rest are.  What's the best way to get rid of this error and make sure my disks are uniform so as not to cause problems with ZFS?


----------



## wblock@ (Nov 28, 2015)

Use gpart(8) to destroy the existing partitioning information.  It might be necessary to use recover first.  Then use `gpart destroy` to destroy the now-valid GPT, including the backup table at the end of the disk which was probably the problem.


----------



## phoenix (Dec 1, 2015)

You can also use `zpool labelclear` on each disk to make sure there are no ZFS-related pseudo-GPT tables on it.

And `gpart -F` is useful as a "nuke it from orbit" option.  Combined with the labelclear, you should have "pristine" disks for use with ZFS.

If you really want to make sure the disk is completely clean, you can use `dd if=/dev/zero of=/dev/XXXX bs=1M` to completely zero out every sector of the disk, including any partitioning info at the front and end of the disk.


----------



## ghuber (Mar 21, 2016)

wblock@ said:


> Use gpart(8) to destroy the existing partitioning information.  It might be necessary to use recover first.  Then use `gpart destroy` to destroy the now-valid GPT, including the backup table at the end of the disk which was probably the problem.



That is exactly what I was looking for. Will `gpart destroy -F da3` also work in a live Raid-Z2 array (in principle) or is it better to remove the drive, attach it to another machine kill the GPT table and reattach it to the array?

Will "killing" the GPT table result in resilvering of the drive in the Raid-Z2 array?

Thank you very much!

Georg


----------



## shepper (Mar 21, 2016)

Another option to zap gpt tables: gdisk.
sysutils/gdisk is available as a port and on some linux live cd's


----------



## wblock@ (Mar 21, 2016)

ghuber said:


> That is exactly what I was looking for. Will `gpart destroy -F da3` also work in a live Raid-Z2 array (in principle) or is it better to remove the drive, attach it to another machine kill the GPT table and reattach it to the array?



If the GEOM system will allow it... That will depend on whether the ZFS array is using the GPT provider.  Still potentially dangerous.  I'd trust gpart(8) to only erase the GPT primary and secondary tables, but I'm not sure if that would upset ZFS.  I am pretty sure I would not do this to a disk without making sure it did a resilver, it seems unsafe for the data on that disk otherwise.



> Will "killing" the GPT table result in resilvering of the drive in the Raid-Z2 array?



Maybe.  That could be a good thing, because then at least there would be a known-good copy of information on the modified drive.


----------



## ghuber (Mar 22, 2016)

Hi Warren (?, if you are you the Warren with the How to use FreeBSD with SSD-guide)

Thanks for your answer.

dmesg shows that the GPT table of da3 ist invalid. When I try


```
gpart show da3
```
I just receive "gpart: No such geom: da3". When I try gpart destroy da3, I receive "gpart: arg0 'da3': Invalid argument". Am I doing anything wrong?

Georg


----------



## wblock@ (Mar 22, 2016)

What usually happens is a disk has GPT partitioning, with a table at the start of the disk and the backup table at the end.  Then some other partitioning, usually MBR, is installed without removing the GPT, so a new table overwrites the primary GPT at the start of the disk but leaves the backup table still present at the end.  `gpart recover` can (sometimes) bring back a valid GPT setup, copying the backup GPT to the primary, and then `gpart destroy` can be used to remove both.  This is not guaranteed to leave ZFS data untouched.  Likewise with using dd(1) to overwrite the last 34 (or 35, I forget) blocks of the disk.  `zpool labelclear` will definitely erase the ZFS label that identifies the drive as part of a ZFS array.  I'm not entirely sure it will clear that backup GPT table, though.

(Yes, I have some articles on FreeBSD at http://www.wonkity.com/~wblock/docs/.)


----------



## protocelt (Mar 22, 2016)

wblock@ said:


> zpool labelclear will definitely erase the ZFS label that identifies the drive as part of a ZFS array. I'm not entirely sure it will clear that backup GPT table, though.


 Unless that's changed in the last couple of months, it clears everything. It's what I use to clear a disk that used ZFS when I intend to re-partition it.

Further information: https://lists.freebsd.org/pipermail/freebsd-stable/2013-June/073762.html


----------

