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=
'gpt add' step it does not trigger)<br></div><div><br></div><div>d=
d if=3D/dev/zero bs=3D1m count=3D10 > 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:
(Contact us)
$NetBSD: query-full-pr,v 1.47 2022/09/11 19:34:41 kim Exp $
$NetBSD: gnats_config.sh,v 1.9 2014/08/02 14:16:04 spz Exp $
Copyright © 1994-2023
The NetBSD Foundation, Inc. ALL RIGHTS RESERVED.