Re: bin/51504: gpt(8) cannot create GPT on zeroed(fresh) disk

[John Nemeth <jnemeth%cue.bc.ca@localhost>]

The following reply was made to PR bin/51504; it has been noted by GNATS.

From: John Nemeth <jnemeth%cue.bc.ca@localhost>
To: christos%zoulas.com@localhost (Christos Zoulas), gnats-bugs%NetBSD.org@localhost,
        gnats-admin%netbsd.org@localhost, netbsd-bugs%netbsd.org@localhost
Cc: 
Subject: Re: bin/51504: gpt(8) cannot create GPT on zeroed(fresh) disk
Date: Sat, 24 Sep 2016 08:38:27 -0700

 On Sep 24,  9:27am, Christos Zoulas wrote:
 } 
 } | 	gpt(8) cannot create GPT on zeroed(fresh) disk
 } | >How-To-Repeat:
 } | # DISK=/dev/rsd0d
 } | # dd if=/dev/zero of=$DISK bs=1m count=1
 } | 1+0 records in
 } | 1+0 records out
 } | 1048576 bytes transferred in 0.103 secs (10180349 bytes/sec)
 } | # gpt -v create -p 24 $DISK
 } | /dev/rsd0d: mediasize=3000592982016; sectorsize=512; blocks=5860533168
 } | /dev/rsd0d: MBR not found at sector 0
 } | gpt: /dev/rsd0d: Device already contains a GPT
 } | # gpt show $DISK
 } |        start        size  index  contents
 } |            0           1         PMBR
 } |            1  5860533160         Unused
 } |   5860533161           6         Sec GPT table
 } |   5860533167           1         Sec GPT header
 } 
 } That's not a zeroed disk as you can see. Someone created a gpt
 } before, and attempted to destroy it by dd'ing the first blocks.
 } This destroys the primary gpt table but not the secondary one. You
 } can use gpt recover to put it back and then gpt destroy to clean
 } it up completely. Alternatively you can zero the whole disk. I
 } agree that there should be a force command to ignore the secondary
 } gpt...
 
      There already is a force option.  It just needs to be tested
 in a few more spots (or, maybe create a -F option that ignores
 everything).  "gpt destroy" will destroy a disk that only has a
 secondary header (tested).
 
 }-- End of excerpt from Christos Zoulas