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

[christos%zoulas.com@localhost (Christos Zoulas)]

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

From: christos%zoulas.com@localhost (Christos Zoulas)
To: 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 09:27:46 -0400

 On Sep 24, 11:20am, clare%csel.org@localhost (clare%csel.org@localhost) wrote:
 -- Subject: bin/51504: gpt(8) cannot create GPT on zeroed(fresh) disk
 
 | 	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...
 
 christos