NetBSD Problem Report #51504

From clare@kotori.csel.org  Sat Sep 24 11:17:36 2016
Return-Path: <clare@kotori.csel.org>
Received: from mail.netbsd.org (mail.netbsd.org [199.233.217.200])
	(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
	(Client CN "mail.netbsd.org", Issuer "Postmaster NetBSD.org" (verified OK))
	by mollari.NetBSD.org (Postfix) with ESMTPS id 7423C7A106
	for <gnats-bugs@gnats.NetBSD.org>; Sat, 24 Sep 2016 11:17:36 +0000 (UTC)
Message-Id: <20160924111732.7B1FB3FBE@kotori.csel.org>
Date: Sat, 24 Sep 2016 20:17:32 +0900 (JST)
From: clare@csel.org
Reply-To: clare@csel.org
To: gnats-bugs@NetBSD.org
Subject: gpt(8) cannot create GPT on zeroed(fresh) disk
X-Send-Pr-Version: 3.95

>Number:         51504
>Category:       bin
>Synopsis:       gpt(8) cannot create GPT on zeroed(fresh) disk
>Confidential:   no
>Severity:       critical
>Priority:       high
>Responsible:    bin-bug-people
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Sat Sep 24 11:20:00 +0000 2016
>Last-Modified:  Sat Sep 24 15:40:00 +0000 2016
>Originator:     clare@csel.org
>Release:        NetBSD 7.99.36
>Organization:
	at home
>Environment:
		gpt(8) updated as of today.
		# cd $src/sbin/gpt; make clean; make; make install
System: NetBSD yuzuki.csel.org 7.99.36 NetBSD 7.99.36 (YUZUKI1) #4: Sat Sep 10 22:54:05 JST 2016  clare@yuzuki.csel.org:/export/stage/hack/sys/arch/amd64/compile/YUZUKI1 amd64
Architecture: x86_64
Machine: amd64
>Description:
	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
>Fix:
	Unknown...

>Audit-Trail:
From: christos@zoulas.com (Christos Zoulas)
To: gnats-bugs@NetBSD.org, gnats-admin@netbsd.org, netbsd-bugs@netbsd.org
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 (clare@csel.org) 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

From: John Nemeth <jnemeth@cue.bc.ca>
To: christos@zoulas.com (Christos Zoulas), gnats-bugs@NetBSD.org,
        gnats-admin@netbsd.org, netbsd-bugs@netbsd.org
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

Home	PR Database Search