From <https://www.freebsd.org/cgi/man.cgi?query=gpart&sektion=8&manpath=FreeBSD#EXAMPLES>: > … -F option can be given with destroy to delete all of the partitions > before destroying the partitioning scheme. … From <https://forums.freebsd.org/posts/558256>: … root@mowa219-gjp4-8570p-freebsd:~ # gpart create -s MBR da4 da4 created root@mowa219-gjp4-8570p-freebsd:~ # gpart add -t freebsd da4 da4s1 added root@mowa219-gjp4-8570p-freebsd:~ # gpart create -s BSD da4s1 da4s1 created root@mowa219-gjp4-8570p-freebsd:~ # gpart add -t freebsd-swap da4s1 da4s1a added … root@mowa219-gjp4-8570p-freebsd:~ # gpart destroy -F da4 da4 destroyed root@mowa219-gjp4-8570p-freebsd:~ # gpart create -s MBR da4 da4 created root@mowa219-gjp4-8570p-freebsd:~ # gpart add -t freebsd da4 da4s1 added root@mowa219-gjp4-8570p-freebsd:~ # gpart create -s BSD da4s1 gpart: geom 'da4s1': File exists root@mowa219-gjp4-8570p-freebsd:~ # The existence of da4s1 suggests that prior destruction by gpart was not entirely effective.
Reproducible with md(4) # gpart create -s MBR md0 md0 created # gpart show md0 => 9 262135 md0 MBR (128M) 9 262135 - free - (128M) # ls /dev/md0* /dev/md0 # gpart add -t freebsd md0 md0s1 added # gpart show md0 => 9 262135 md0 MBR (128M) 9 262135 1 freebsd (128M) # ls /dev/md0* /dev/md0 /dev/md0s1 /dev/md0s1a # gpart create -s BSD md0s1 gpart: geom 'md0s1': File exists This doesn't seem like desired behaviour although I am not particularly surprised by it, and I believe it does not contradict the man page. `gpart destroy -F` does delete the partition(s) in the MBR scheme: that is md0s1. At the very least the man page needs to be clear (if we do not change the behaviour).
(In reply to Ed Maste from comment #1) Thanks. Is there scope for an enhancement to gpart, if we compare with what's done by GPT fdisk? sysutils/gdisk GPT fdisk is not intended for use with MBR, however (re: the post in FreeBSD Forums, and other tests by me) its destruction routine does seem to be more effective in a case such as this.
Hmm. So "gpart destroy -F geom" does _not_ actually wipe the partition block, at least if it is a MBR one. Now I think I understand that strange error that I encountered when attempting to create a clone on a (formerly) MBR partitioned USB stick while testing my new Skunk Cloner (https://github.com/SkunkOS/SkunkCloner). If gpart destroy does _not_ work under some configurations, the only work-around to ensure clean partition data then would be to zero-dd the partition table. Honestly, I would rather prefer to be able to use gpart destroy to clear out any old partition data! I don't like having no other choice than to hackingly use dd to clear partition data.
> So "gpart destroy -F geom" does _not_ actually wipe the partition block That's a different from what's being described here, so please add precise details/reproduction steps.