NetBSD Problem Report #56300

From kardel@Kardel.name  Tue Jul  6 10:50:00 2021
Return-Path: <kardel@Kardel.name>
Received: from mail.netbsd.org (mail.netbsd.org [199.233.217.200])
	(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits))
	(Client CN "mail.NetBSD.org", Issuer "mail.NetBSD.org CA" (not verified))
	by mollari.NetBSD.org (Postfix) with ESMTPS id CEF4C1A923B
	for <gnats-bugs@gnats.NetBSD.org>; Tue,  6 Jul 2021 10:50:00 +0000 (UTC)
Message-Id: <20210706093134.0F41744B33@Andromeda.Kardel.name>
Date: Tue,  6 Jul 2021 11:31:34 +0200 (CEST)
From: kardel@netbsd.org
Reply-To: kardel@netbsd.org
To: gnats-bugs@NetBSD.org
Subject: gpt useless on gpt labels extending beyond disk size (also affects sysinst)
X-Send-Pr-Version: 3.95

>Number:         56300
>Category:       bin
>Synopsis:       gpt useless on gpt labels extending beyond disk size (also affects sysinst)
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    jnemeth
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Tue Jul 06 10:55:00 +0000 2021
>Last-Modified:  Wed Aug 23 21:55:01 +0000 2023
>Originator:     kardel@netbsd.org
>Release:        NetBSD 9.99.85
>Organization:

>Environment:


System: NetBSD kebne-new 9.99.85 NetBSD 9.99.85 (GENERIC) #4: Tue Jun 29 11:47:28 CEST 2021 kardel@pip:/src/NetBSD/cur/src/obj.amd64/sys/arch/amd64/compile/GENERIC amd64
Architecture: x86_64
Machine: amd64
>Description:
	gpt becomes useless when it hits a gpt label that extends beyond the size of
	the disk. This can be caused by e. g. changing a physical disk with gpt label
	to a virtual disk in a RAID controller. The label stays the same but the size
	decreases (e. g. Dell PERC controllers). After that gpt cannot manipulate the
	label at all due to a hard consistency check. Suppressing error messages 
	also do not prevent the exit at this error message

# gpt show sd2
gpt: /dev/rsd2: map entry doesn't fit media: new start + new size < start + size
(22 + 37d3ffde < 800 + 37e42800)
# gpt destroy sd2
gpt: /dev/rsd2: map entry doesn't fit media: new start + new size < start + size
(22 + 37d3ffde < 800 + 37e42800)
# gpt header sd2
gpt: /dev/rsd2: map entry doesn't fit media: new start + new size < start + size
(22 + 37d3ffde < 800 + 37e42800)

	As sysinst uses also gpt it cannot properly handle diskes wih these labels.
	The kernel does not seem to be that strict and uses the data from the label.

	The workaround is to zap the gpt label with the classic dd method.

	gpt should at least allow destroying these labels. Ideally it should accept
	the label, but refuse to write an inconsistent label. This would allow fixing
	the labels and allow to retain data except for the missing space.

>How-To-Repeat:
	Convert a physical disk on a Dell RAID Controller with a valid gpt label to
	a virtual disk (thus reducing the size but not altering the gpt label).
	Attempt to use that disk with NetBSD and see gpt failing.
>Fix:
	make gpt accept these labels but refuse to write inconsistent labels

>Release-Note:

>Audit-Trail:
From: Martin Husemann <martin@duskware.de>
To: gnats-bugs@netbsd.org
Cc: 
Subject: Re: bin/56300: gpt useless on gpt labels extending beyond disk size
 (also affects sysinst)
Date: Tue, 6 Jul 2021 13:22:23 +0200

 On Tue, Jul 06, 2021 at 10:55:00AM +0000, kardel@netbsd.org wrote:
 > 	gpt becomes useless when it hits a gpt label that extends beyond the size of
 > 	the disk

 Doesn't

 	gpt resizedisk

 work for this case? I think that "resizedisk" and "destroy" should 
 definitively work, but all other commands could be argued to fail for
 good reasons.

 Martin

From: Frank Kardel <kardel@netbsd.org>
To: gnats-bugs@netbsd.org, gnats-admin@netbsd.org, netbsd-bugs@netbsd.org
Cc: 
Subject: Re: bin/56300: gpt useless on gpt labels extending beyond disk size
 (also affects sysinst)
Date: Tue, 6 Jul 2021 13:29:30 +0200

 Sorry, but no.

 gpt resizedisk

 fails the same way as destroy:

 # gpt resizedisk sd2
 gpt: /dev/rsd2: map entry doesn't fit media: new start + new size < start + size
 (22 + 37d3ffde < 800 + 37e42800)
 #

 So at least these two should be fixed.

 Frank


 On 07/06/21 13:25, Martin Husemann wrote:
 > The following reply was made to PR bin/56300; it has been noted by GNATS.
 >
 > From: Martin Husemann <martin@duskware.de>
 > To: gnats-bugs@netbsd.org
 > Cc:
 > Subject: Re: bin/56300: gpt useless on gpt labels extending beyond disk size
 >   (also affects sysinst)
 > Date: Tue, 6 Jul 2021 13:22:23 +0200
 >
 >   On Tue, Jul 06, 2021 at 10:55:00AM +0000, kardel@netbsd.org wrote:
 >   > 	gpt becomes useless when it hits a gpt label that extends beyond the size of
 >   > 	the disk
 >   
 >   Doesn't
 >   
 >   	gpt resizedisk
 >   
 >   work for this case? I think that "resizedisk" and "destroy" should
 >   definitively work, but all other commands could be argued to fail for
 >   good reasons.
 >   
 >   Martin
 >   


Responsible-Changed-From-To: bin-bug-people->jnemeth
Responsible-Changed-By: jnemeth@NetBSD.org
Responsible-Changed-When: Tue, 06 Jul 2021 22:57:21 +0000
Responsible-Changed-Why:
Mine.


From: David Brownlee <abs@absd.org>
To: gnats-bugs@netbsd.org
Cc: gnats-admin@netbsd.org, netbsd-bugs@netbsd.org
Subject: Re: bin/56300: gpt useless on gpt labels extending beyond disk size
 (also affects sysinst)
Date: Sun, 6 Aug 2023 15:15:05 +0100

 --000000000000724fa3060241c642
 Content-Type: text/plain; charset="UTF-8"

 Just hit this when trying to adjust some gpt-in-ccd settings

 Also - easy case to reproduce (without the 'gpt add' step it does not
 trigger)

 dd if=/dev/zero bs=1m count=10 > test.img
 gpt create test.img
 gpt add -t ffs test.img
 dd if=test.img of=smaller.img bs=1m count=9
 gpt destroy smaller.img

 One thought, there could be some kind of force option to bypass the size
 check - possibly by truncating or ignoring oversized entries, which could
 be useful for recovering damaged disk images

 Thanks

 David

 --000000000000724fa3060241c642
 Content-Type: text/html; charset="UTF-8"
 Content-Transfer-Encoding: quoted-printable

 <div dir=3D"ltr"><div>Just hit this when trying to adjust some gpt-in-ccd s=
 ettings</div><div><br></div><div>Also - easy case to reproduce (without the=
  &#39;gpt add&#39; step it does not trigger)<br></div><div><br></div><div>d=
 d if=3D/dev/zero bs=3D1m count=3D10 &gt; test.img</div><div>gpt create test=
 .img</div><div>gpt add -t ffs test.img <br></div><div>dd if=3Dtest.img of=
 =3Dsmaller.img bs=3D1m count=3D9</div><div>gpt destroy smaller.img</div><di=
 v><br></div><div>One thought, there could be some kind of force option to b=
 ypass the size check - possibly by truncating or ignoring oversized entries=
 , which could be useful for recovering damaged disk images</div><div><br></=
 div><div>Thanks</div><div><br></div><div>David<br></div></div>

 --000000000000724fa3060241c642--

From: mlelstv@serpens.de (Michael van Elst)
To: gnats-bugs@netbsd.org
Cc: 
Subject: Re: bin/56300: gpt useless on gpt labels extending beyond disk size (also affects sysinst)
Date: Mon, 7 Aug 2023 09:32:48 -0000 (UTC)

 abs@absd.org (David Brownlee) writes:

 >One thought, there could be some kind of force option to bypass the size
 >check - possibly by truncating or ignoring oversized entries, which could
 >be useful for recovering damaged disk images

 There isn't really a size check, just a "GPT is valid" check, for
 things like 'destroy' some validations are already skipped, but
 apparently not everything.

From: jnemeth@CornerstoneService.ca (John Nemeth)
To: gnats-bugs@netbsd.org, jnemeth@netbsd.org, gnats-admin@netbsd.org,
        netbsd-bugs@netbsd.org, kardel@netbsd.org
Cc: 
Subject: Re: bin/56300: gpt useless on gpt labels extending beyond disk size (also affects sysinst)
Date: Wed, 23 Aug 2023 14:54:36 -0700

 On Aug 6, 14:20, David Brownlee wrote:
 } The following reply was made to PR bin/56300; it has been noted by GNATS.
 } 
 } From: David Brownlee <abs@absd.org>
 } To: gnats-bugs@netbsd.org
 } Subject: Re: bin/56300: gpt useless on gpt labels extending beyond disk size
 }  (also affects sysinst)
 } Date: Sun, 6 Aug 2023 15:15:05 +0100
 } 
 }  Just hit this when trying to adjust some gpt-in-ccd settings
 }  
 }  Also - easy case to reproduce (without the 'gpt add' step it does not
 }  trigger)
 }  
 }  dd if=/dev/zero bs=1m count=10 > test.img
 }  gpt create test.img
 }  gpt add -t ffs test.img
 }  dd if=test.img of=smaller.img bs=1m count=9
 }  gpt destroy smaller.img
 }  
 }  One thought, there could be some kind of force option to bypass the size
 }  check - possibly by truncating or ignoring oversized entries, which could
 }  be useful for recovering damaged disk images

      The problem is that gpt(8) looks like a first year comp-sci
 assignment in linked list manipulation.  The program is all about
 manipulating the list, where the nodes just happen to represent
 disk objects.  It's not very good at handling situations where the
 linked list could get "corrupted".

      I've been thinking about ideas for a new data structure.  My
 first idea involved using bitmasks, but I realized that with the
 size of modern disks that was a no go.  I'm open to ideas.

 }-- End of excerpt from David Brownlee

>Unformatted:

Home	PR Database Search