NetBSD Problem Report #59956
From www@netbsd.org Sun Feb 1 20:53:07 2026
Return-Path: <www@netbsd.org>
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)
key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256
client-signature RSA-PSS (2048 bits) client-digest SHA256)
(Client CN "mail.netbsd.org", Issuer "R13" (verified OK))
by mollari.NetBSD.org (Postfix) with ESMTPS id 4F3771A923D
for <gnats-bugs@gnats.NetBSD.org>; Sun, 1 Feb 2026 20:53:07 +0000 (UTC)
Message-Id: <20260201205306.6B78B1A923E@mollari.NetBSD.org>
Date: Sun, 1 Feb 2026 20:53:06 +0000 (UTC)
From: campbell+netbsd@mumble.net
Reply-To: campbell+netbsd@mumble.net
To: gnats-bugs@NetBSD.org
Subject: gpt(8): show human-readable units
X-Send-Pr-Version: www-1.0
X-From4GNATS: "campbell+netbsd@mumble.net via gnats" <gnats-admin@NetBSD.org>
>Number: 59956
>Category: bin
>Synopsis: gpt(8): show human-readable units
>Confidential: no
>Severity: serious
>Priority: medium
>Responsible: kre
>State: feedback
>Class: sw-bug
>Submitter-Id: net
>Arrival-Date: Sun Feb 01 20:55:00 +0000 2026
>Closed-Date:
>Last-Modified: Wed Feb 11 14:33:30 +0000 2026
>Originator: Taylor R Campbell
>Release: current, 11, 10, 9, ...
>Organization:
The NetGPT Unitation
>Environment:
>Description:
# gpt show sd2
start size index contents
0 1 PMBR (active)
1 1 Pri GPT header
2 32 Pri GPT table
34 2014 Unused
2048 2881536 1 GPT part - NetBSD FFSv1/FFSv2
2883584 262144 2 GPT part - NetBSD swap
3145728 1515520 3 GPT part - NetBSD FFSv1/FFSv2
4661248 262144 4 GPT part - NetBSD FFSv1/FFSv2
4923392 55705600 Unused
Would be nice if this could show units of KiB/MiB/GiB/TiB.
>How-To-Repeat:
gpt show diskN
>Fix:
Yes, please!
>Release-Note:
>Audit-Trail:
Responsible-Changed-From-To: bin-bug-people->kre
Responsible-Changed-By: kre@NetBSD.org
Responsible-Changed-When: Mon, 02 Feb 2026 20:10:05 +0000
Responsible-Changed-Why:
I will make this happen. I have some other
(minor) changes to gpt uncommitted as well,
may as well take care of it all together.
From: Robert Elz <kre@munnari.OZ.AU>
To: gnats-bugs@netbsd.org, netbsd-bugs@netbsd.org
Cc:
Subject: Re: bin/59956: gpt(8): show human-readable units
Date: Tue, 03 Feb 2026 15:36:00 +0700
I have this working now in a fashion which looks OK to me
(note that the code always printed (a degree of) humanized
numbers when used as show -a, or show -[ib] arg, it is only
the simple "show" case (to print the entire GPT table) where
it never did.)
Nevertheless I have made some changes to the others as well,
though when I play more I might limit some of that to verbose
mode (gpt -v show ...).
No doc on the changes yet of course, but that will come.
A example, one table, shown 3 ways (the last is the traditional version):
jacaranda$ ./gpt show -Ah ld1 # 'A' for "approximately"
start size index contents
0 512B PMBR
512B 512B Pri GPT header
1.0K 16K Pri GPT table
17K 1.0M Unused
1.0M 255M 1 GPT part - EFI System
256M 5.7G 2 GPT part - NetBSD FFSv1/FFSv2
6.0G 1.0T 4 GPT part - NetBSD RAIDFrame component
1.0T 992K Unused
1.0T 769G 5 GPT part - NetBSD ccd component
1.8T 64G 3 GPT part - NetBSD swap
1.8T 16K Sec GPT table
1.8T 512B Sec GPT header
jacaranda$ ./gpt show -h ld1
start size index contents
0 512B PMBR
512B 512B Pri GPT header
1K 16K Pri GPT table
17K 1007K Unused
1M 255M 1 GPT part - EFI System
256M 5G 767M 992K 2 GPT part - NetBSD FFSv1/FFSv2
5G 1023M 992K 1T 32K 4 GPT part - NetBSD RAIDFrame component
1T 6G 992K Unused
1T 6G 992K 769G 269M 32K 5 GPT part - NetBSD ccd component
1T 775G 270M 63G 771M 71K 512B 3 GPT part - NetBSD swap
1T 839G 17M 71K 512B 16K Sec GPT table
1T 839G 17M 87K 512B 512B Sec GPT header
jacaranda$ ./gpt show ld1
start size index contents
0 1 PMBR
1 1 Pri GPT header
2 32 Pri GPT table
34 2014 Unused
2048 522240 1 GPT part - EFI System
524288 12058560 2 GPT part - NetBSD FFSv1/FFSv2
12582848 2147483712 4 GPT part - NetBSD RAIDFrame component
2160066560 1984 Unused
2160068544 1613260864 5 GPT part - NetBSD ccd component
3773329408 133699727 3 GPT part - NetBSD swap
3907029135 32 Sec GPT table
3907029167 1 Sec GPT header
And just in case idiocy is desired - decimal GB (etc):
jacaranda$ ./gpt show -AH ld1
start size index contents
0 512B PMBR
512B 512B Pri GPT header
1.0k 16k Pri GPT table
17k 1.0M Unused
1.0M 267M 1 GPT part - EFI System
268M 6.2G 2 GPT part - NetBSD FFSv1/FFSv2
6.4G 1.1T 4 GPT part - NetBSD RAIDFrame component
1.1T 1.0M Unused
1.1T 826G 5 GPT part - NetBSD ccd component
1.9T 68G 3 GPT part - NetBSD swap
2.0T 16k Sec GPT table
2.0T 512B Sec GPT header
(Yes, that's a "2TB" M.2 NVME).
Comments welcome (the other options, -l, -u, even -x to a degree (not with -A)
all still work of course).
kre
From: Rob Whitlock <rwhitlock22@gmail.com>
To: gnats-bugs@netbsd.org
Cc:
Subject: Re: bin/59956: gpt(8): show human-readable units
Date: Tue, 3 Feb 2026 13:36:16 -0500
> On Feb 1, 2026, at 3:55 PM, campbell+netbsd@mumble.net via gnats =
<gnats-admin@NetBSD.org> wrote:
> # gpt show sd2
> start size index contents
> 0 1 PMBR (active)
> 1 1 Pri GPT header
> 2 32 Pri GPT table
> 34 2014 Unused
> 2048 2881536 1 GPT part - NetBSD FFSv1/FFSv2
> 2883584 262144 2 GPT part - NetBSD swap
> 3145728 1515520 3 GPT part - NetBSD FFSv1/FFSv2
> 4661248 262144 4 GPT part - NetBSD FFSv1/FFSv2
> 4923392 55705600 Unused
>=20
> Would be nice if this could show units of KiB/MiB/GiB/TiB.
>> How-To-Repeat:
> gpt show diskN
>> Fix:
> Yes, please!
Human readable sizes are available when you add the -a option to gpt =
show.=
From: Robert Elz <kre@munnari.OZ.AU>
To: gnats-bugs@netbsd.org
Cc:
Subject: Re: bin/59956: gpt(8): show human-readable units
Date: Wed, 04 Feb 2026 09:31:22 +0700
Date: Tue, 3 Feb 2026 18:40:01 +0000 (UTC)
From: "Rob Whitlock via gnats" <gnats-admin@NetBSD.org>
Message-ID: <20260203184001.6F4981A923E@mollari.NetBSD.org>
| Human readable sizes are available when you add the -a option to gpt
| show.
Yes, I know, that's what I meant when I said:
(note that the code always printed (a degree of) humanized
numbers when used as show -a, or show -[ib] arg, it is only
the simple "show" case (to print the entire GPT table) where
it never did.)
though with -a it is only the size, not the start block (and even then,
the human readable version is buried in the output, rather than in the
size column). With -i or -b (just show 1 partition) human readable
versions are obvious already, using the same filesystem as used for the
examples in the previous message:
jacaranda$ gpt show -i 1 ld1
Details for index 1:
Start: 2048 (1M)
Size: 522240 (255M)
Type: efi (c12a7328-f81f-11d2-ba4b-00a0c93ec93b)
GUID: 2065f874-8e2c-4475-a4b1-e8e5e2de54dc
Label: NetBSD_EFI_1
Attributes: None
All this is also why, in my previous message, I only gave examples for
the simple "show" case (none of -a -i -b used), as that's the case I
assume that Taylor intended to be able to change - that's the example that
is in the PR which requests "if this could show ...", so that's what
I have concentrated upon. Currently the -i/-b (same thing, different
way to select the partition) output is unchanged, and with -a the only
real useful change I have made is to properly align the data column, the
existing code "just knows" how wide the start/size/index columns will be,
and when it is wrong, things like:
Attributes: None
34539643788 9216000 19 GPT part - NetBSD FFSv1/FFSv2
Type: ffs
TypeID: 49f48d5a-b10e-11dc-b99b-0019d1879648
GUID: c15437e4-5b80-476f-8b0a-d6ba6b84789a
Size: 4500 M
appeared (this from a different, bigger, filesystem).
That I have corrected, it will now be:
Attributes: None
34539643788 9216000 19 GPT part - NetBSD FFSv1/FFSv2
Type: ffs
TypeID: 49f48d5a-b10e-11dc-b99b-0019d1879648
GUID: c15437e4-5b80-476f-8b0a-d6ba6b84789a
Size: 4500 M (4718592000)
The extra number in () in the Size: line is the partition size in bytes.
Then with -h added, it has more precise human readable data added:
Attributes: None
34539643788 9216000 19 GPT part - NetBSD FFSv1/FFSv2
Type: ffs
TypeID: 49f48d5a-b10e-11dc-b99b-0019d1879648
GUID: c15437e4-5b80-476f-8b0a-d6ba6b84789a
Size: 4500 M (4718592000) = 4G 404M
though I actually doubt that will see much use. Whether the start/size
columns in -a output should be modified, I haven't decided, but I suspect
probably not (they could be, that would be easy to do now.)
Opinions remain welcome - now is the best time to request something different
(ie: before I write doc!)
kre
From: Rob Whitlock <rwhitlock22@gmail.com>
To: gnats-bugs@netbsd.org
Cc:
Subject: Re: bin/59956: gpt(8): show human-readable units
Date: Wed, 4 Feb 2026 10:05:35 -0500
> On Feb 3, 2026, at 9:35 PM, Robert Elz via gnats =
<gnats-admin@NetBSD.org> wrote:
>=20
> The following reply was made to PR bin/59956; it has been noted by =
GNATS.
>=20
> From: Robert Elz <kre@munnari.OZ.AU>
> To: gnats-bugs@netbsd.org
> Cc:=20
> Subject: Re: bin/59956: gpt(8): show human-readable units
> Date: Wed, 04 Feb 2026 09:31:22 +0700
>=20
> Date: Tue, 3 Feb 2026 18:40:01 +0000 (UTC)
> From: "Rob Whitlock via gnats" <gnats-admin@NetBSD.org>
> Message-ID: <20260203184001.6F4981A923E@mollari.NetBSD.org>
>=20
> | Human readable sizes are available when you add the -a option to =
gpt
> | show.
>=20
> Yes, I know, that's what I meant when I said:
>=20
> (note that the code always printed (a degree of) humanized
> numbers when used as show -a, or show -[ib] arg, it is only
> the simple "show" case (to print the entire GPT table) where
> it never did.)
Right, I=E2=80=99m not sure how I missed that.
[snip]
> Opinions remain welcome - now is the best time to request something =
different
> (ie: before I write doc!)
The only thing I can think of is to perhaps keep it parseable by fields, =
so
1T 775G 270M 63G 771M 71K 512B 3 GPT part - NetBSD swap
would be something like
1T,775G,270M 63G,771M,71K,512B 3 GPT part - NetBSD swap
or whatever the appropriate separator is for the current locale.
> kre
>=20
From: Martin Husemann <martin@duskware.de>
To: gnats-bugs@netbsd.org
Cc: kre@netbsd.org, campbell+netbsd@mumble.net
Subject: Re: bin/59956: gpt(8): show human-readable units
Date: Wed, 4 Feb 2026 16:26:23 +0100
Please do not change output format w/o another switch (or add a switch
to keep the old output format).
Or probably even better: add a switch to get easily readable output
with a new switch and I'll adapt sysinst to use the new switch and
format.
Sysinst parses the output of:
gpt.c: if (collect(T_OUTPUT, &textbuf, "gpt -r show -a %s 2>/dev/null", dev)
and
gpt.c: "gpt -r show -b %" PRIu64 " %s 2>/dev/null", start, disk) < 1)
All other gpt(8) invocations only care about exit status (and the output
is ignored/discarded).
Martin
From: Robert Elz <kre@munnari.OZ.AU>
To: gnats-bugs@netbsd.org
Cc:
Subject: Re: bin/59956: gpt(8): show human-readable units
Date: Wed, 04 Feb 2026 23:14:43 +0700
Date: Wed, 4 Feb 2026 15:10:02 +0000 (UTC)
From: "Rob Whitlock via gnats" <gnats-admin@NetBSD.org>
Message-ID: <20260204151002.0DB501A923E@mollari.NetBSD.org>
| The only thing I can think of is to perhaps keep it parseable by fields,
Ah, no, not this:
| so
| 1T 775G 270M 63G 771M 71K 512B 3 GPT part - NetBSD swap
That's supposed to be (at least kind of) human readable, parsing something
designed for humans when there's a more machine readable form available
(with just the plain block numbers) would be just bizarre. See the reply
I will send to Martin's message soon after this for more on parseable versions.
| would be something like
|
| 1T,775G,270M 63G,771M,71K,512B 3 GPT part - NetBSD swap
|
| or whatever the appropriate separator is for the current locale.
There's nothing locale related in this (and for this I am not sure
how there really could be). I actually started with a '+' between the
fields (actually, the first version, due to a bug, simply had them
all run together, like
1T775G270M
but that's definitely not human readable), the version with '+'
looked ugly as well
1T+775G+270M
I considered using '_' (but didn't try that one), when spaces seemed
like a reasonable choice. There is exactly one instance of the selected
character in the source, so changing it (or making it conditional in
some way) is trivial.
But do aim for better human readability, along with retaining the accuracy
(the -A which simply gives the humanize_number(3) result is an alternative
when all you care about is getting an idea of the layout, and no secific
details).
Anything which anyone things will make it more readable, for people, not
machines, I'm certainly willing to consider.
kre
From: Robert Elz <kre@munnari.OZ.AU>
To: Martin Husemann <martin@duskware.de>
Cc: gnats-bugs@netbsd.org, campbell+netbsd@mumble.net
Subject: Re: bin/59956: gpt(8): show human-readable units
Date: Wed, 04 Feb 2026 23:46:13 +0700
Date: Wed, 4 Feb 2026 16:26:23 +0100
From: Martin Husemann <martin@duskware.de>
Message-ID: <aYNlH8DW0HQp-wH-@big-apple.aprisoft.de>
| Please do not change output format w/o another switch (or add a switch
| to keep the old output format).
At the minute that's more or less what happens, there were just a few
minor (unswitched) differences (if you're relying upon the exact number
of spaces in the show -a output that would be an issue, but I hope things
haven't gotten that horrid - it already varied anyway, the code already
calculates the widths of the start and size columns). Apart from that
one the other minor addition I made (without a switch) can easily be undone.
But:
| Or probably even better: add a switch to get easily readable output
| with a new switch and I'll adapt sysinst to use the new switch and
| format.
I agree, that would be better. Tell me what, in an ideal world, you'd
like the format to be (no need for every detail, just what general form
would be easiest to parse) and I will add a switch to generate that format.
Anything (not requiring data to be invented) is possible there, including
supplying a list of fields that you want the values of, so there's less
junk that you don't need - including headers of course) and/or having the
output in a key=value format or something, with whatever separators make
sense, anything can be done (this kind of output is simple to generate,
it is making it "look nice" for people that causes difficulty).
| Sysinst parses the output of:
|
| gpt.c: if (collect(T_OUTPUT, &textbuf, "gpt -r show -a %s 2>/dev/null", dev)
I will take a look at where that is done, and see if what has currently
changed will affect it, just in case something better doesn't appear, and
either undo my change, or send you a patch for sysinst which will handle
things either way (there's just a little info added, nothing removed).
| gpt.c: "gpt -r show -b %" PRIu64 " %s 2>/dev/null", start, disk) < 1)
That one has currently not changed at all, its output is simple enough
that I couldn't see anything useful to modify in that.
jacaranda$ ./gpt show -b 524288 ld1
Details for index 2:
Start: 524288 (256M)
Size: 12058560 (6G)
Type: ffs (49f48d5a-b10e-11dc-b99b-0019d1879648)
GUID: d4dbbda3-2ee0-4975-a083-c6bea3ada9cb
Label: Backup_Root
Attributes: None
The main modifications have been to "gpt show" when -A -h or -H are used,
and none of -a -b or -i. I don't believe a simple "gpt show device"
has altered at all (regardless of -g -l -u -x which all just do the same
as before).
| All other gpt(8) invocations only care about exit status (and the output
| is ignored/discarded).
Good - aside from the changes to show, the main alteration has been in
some of the error messages -- including not generating 2 messages when
one would do. The old way:
jacaranda$ gpt show /
gpt: /: Cannot get sector size (Inappropriate ioctl for device)
gpt: /: No GPT found (Inappropriate ioctl for device)
and the new:
jacaranda$ ./gpt show /
gpt: /: Not a device or plain file (Block device required)
The "Block device required" is wrong, but something from errno
is always printed for that error, and that's the closest one I
could find to being rational, if anyone has better EXXXX suggestion
which will generate a better message, please, let me know. (note
that errno==0 results in worse output). Perhaps I should change
that to avoid using errno at all:
jacaranda$ ./gpt show /
gpt: /: Not a device or plain file
Yes, that is better. I'll look and see which other errors (I
suspect there are a few) are including errno when they have no
reason to do that.
I can't see that bothering sysint though, I doubt you are likely
to be handing gpt directories, fifos, ... as the "device" to work
with. The exit status is unchanged of course.
kre
From: Martin Husemann <martin@duskware.de>
To: Robert Elz <kre@munnari.OZ.AU>
Cc: gnats-bugs@netbsd.org, campbell+netbsd@mumble.net
Subject: Re: bin/59956: gpt(8): show human-readable units
Date: Wed, 4 Feb 2026 18:32:42 +0100
On Wed, Feb 04, 2026 at 11:46:13PM +0700, Robert Elz wrote:
> I agree, that would be better. Tell me what, in an ideal world, you'd
> like the format to be (no need for every detail, just what general form
> would be easiest to parse) and I will add a switch to generate that format.
Something very close to the -b format would be fine for -a + new magic
machine readable switch (plus: make -b use the identical format if the
new switch is given too).
Like (artificial example, partly derived from your -b output and random
other things added from a GPT I had handy):
Start: 0
Size: 1
Type: PMBR
Start: 1
Size: 1
Type: Pri GPT header
GUID: d1199eac-a57b-4fc8-be13-3bcac7f46bac
Start: 2
Size: 32
Type: Pri GPT table
Index: 1
Start: 64
Size: 943718400
Type: ffs
TypeID: 49f48d5a-b10e-11dc-b99b-0019d1879648
GUID: 60d792d8-59f0-454e-a5d3-cb154da4f88a
Label: root
Attributes: None
Index: 2
Start: 524288
Size: 12058560
TypeID: 49f48d5a-b10e-11dc-b99b-0019d1879648
Type: ffs
GUID: d4dbbda3-2ee0-4975-a083-c6bea3ada9cb
Label: Backup_Root
Attributes: None
All fields space or tab separated for use with
while ((tt = strsep(&t, " \t")) != NULL)
and the values in "Attributes:" comma+space separated for use like
while ((n = strsep(&val, ", ")) != NULL)
I guess you get the idea.
Martin
From: Robert Elz <kre@munnari.OZ.AU>
To: Martin Husemann <martin@duskware.de>
Cc: gnats-bugs@netbsd.org, campbell+netbsd@mumble.net
Subject: Re: bin/59956: gpt(8): show human-readable units
Date: Thu, 05 Feb 2026 01:36:55 +0700
Date: Wed, 4 Feb 2026 18:32:42 +0100
From: Martin Husemann <martin@duskware.de>
Message-ID: <aYOCuuN0Ok83w01j@big-apple.aprisoft.de>
| Something very close to the -b format would be fine for -a + new magic
| machine readable switch (plus: make -b use the identical format if the
| new switch is given too).
I can do that, should be easy.
The one thing I worry about however is:
| Label: Backup_Root
Labels are just (UTF16 or whatever it is) text strings.
That means they can contain anything, including newlines, etc.
They can certainly contain spaces, though those alone - even leading
spaces, should be no real problem to handle. But I think we need some
kind of encoding for this (to be properly parsable, rather than just
human readable) to deal with newlines, and other similar junk.
Would perhaps vis encoding the label make sense, or perhaps
even (for this purpose) simply encoding the label as a series
of hex values (of however many bits the chars actually are,
with leading 0's suppressed) ?
Everything else should be no problem (though I see no reason for
using tabs anywhere - except in the label if one is present there)
nor more than a single space between fields (and do you really need
both ',' and ' ' between the attribute names ? ... that's one where
I assume the names are easier to deal with than simply printing the
64 bit field in hex). This is not supposed to be pretty, just easy
for code to read and understand.
I will do all this tomorrow sometime (or rather, later today sometime)
and send you (off list to start with) a sample or three, so you can
determine if it will work for you.
kre
From: Martin Husemann <martin@duskware.de>
To: Robert Elz <kre@munnari.OZ.AU>
Cc: gnats-bugs@netbsd.org, campbell+netbsd@mumble.net
Subject: Re: bin/59956: gpt(8): show human-readable units
Date: Wed, 4 Feb 2026 19:44:32 +0100
On Thu, Feb 05, 2026 at 01:36:55AM +0700, Robert Elz wrote:
> The one thing I worry about however is:
>
> | Label: Backup_Root
>
> Labels are just (UTF16 or whatever it is) text strings.
> That means they can contain anything, including newlines, etc.
> They can certainly contain spaces, though those alone - even leading
> spaces, should be no real problem to handle. But I think we need some
> kind of encoding for this (to be properly parsable, rather than just
> human readable) to deal with newlines, and other similar junk.
I would just print all printable characters in the current locale
and ignore all else. If the result does not fit in a WEDGE=... line
in /etc/fstab later, things will break.
If you prefer to encode, indeed vis(1)/vis(3) is quite convenient.
> Everything else should be no problem (though I see no reason for
> using tabs anywhere - except in the label if one is present there)
> nor more than a single space between fields (and do you really need
> both ',' and ' ' between the attribute names ? ... that's one where
> I assume the names are easier to deal with than simply printing the
> 64 bit field in hex). This is not supposed to be pretty, just easy
> for code to read and understand.
No that, is not really needed - just what the exiting code accepts
and trivial to adjust.
Martin
From: kre@munnari.OZ.AU
To: kre@munnari.OZ.AU, martin@duskware.de
Cc: campbell+netbsd@mumble.net, gnats-bugs@netbsd.org
Subject: Re: bin/59956: gpt(8): show human-readable units
Date: Thu, 5 Feb 2026 02:53:30 +0700 (+07)
Date: Wed, 4 Feb 2026 19:44:32 +0100
From: Martin Husemann <martin@duskware.de>
Subject: Re: bin/59956: gpt(8): show human-readable units
| I would just print all printable characters in the current locale
| and ignore all else.
We could do that, if you don't plan on using the name for anything
other than display during install then it should be OK, but if you're
going to ...
| If the result does not fit in a WEDGE=... line
| in /etc/fstab later, things will break.
then that wouldn't work, as the abbreviated wedge name would never
fit. The truly weird ones are unlikely to get used there however,
more likely (except if someone is just attempting to break things)
would be for them to come from some other unknown system with which
NetBSD is sharing a drive. All we'd need to do is ignore them. But
the output cotaining them still needs to be properly parsed.
But even with 100% NetBSD there can be partition names never used
anywhere except in GPT - eg: the partitions used for an autoconfigured
raidframe. That can be set up initially using dkN names, then
just autoconfig itself forever after. The label just says what it
is being used for, more precisely than "some random raid component".
| If you prefer to encode, indeed vis(1)/vis(3) is quite convenient.
My only reservation with those is that I'm not sure how well they work
with wider than 8 bit characters - we can encode the UTF-8 encoding,
which is what I think we mostly operate upon now though I guess.
| No that, is not really needed - just what the exiting code accepts
| and trivial to adjust.
I don't think that should be an issue, no spaces, just commas, between
attributes should be able to be parsed the same way, just the ' '
delimiter won't ever happen.
kre
From: Robert Elz <kre@munnari.OZ.AU>
To: gnats-bugs@netbsd.org
Cc: netbsd-bugs@netbsd.org
Subject: Re: bin/59956: gpt(8): show human-readable units
Date: Tue, 10 Feb 2026 01:31:06 +0700
I guess the ':' in my commit message (which was really planned
to be after the PR number, not before) caused CVS to not send
this commit message to gnats - so I will do it.
From: "Robert Elz" <kre@netbsd.org>
Reply-To: source-changes-d@NetBSD.org
Date: Mon, 9 Feb 2026 17:21:28 +0000
To: source-changes@NetBSD.org
Subject: CVS commit: src/sbin/gpt
Module Name: src
Committed By: kre
Date: Mon Feb 9 17:21:28 UTC 2026
Modified Files:
src/sbin/gpt: gpt.8 show.c
Log Message:
PR: bin/59956 Add human friendly output (and more) to gpt show
Many improvements to the output generated by "gpt show", essentially
all conditioned by new options.
Two that aren't are a fix to alignment of "gpt show -a" for the lines
of data about the partition which follow the line giving the start
block number, size, and partition type. Now the following lines are
correctly aligned, always - this change affects only the number of
spaces before the data.
And second, in that data, the "Size:" line now always shows the size
of the partition in bytes - that was always what was shown in the tools
build (where humanize_number is not available) but is now also shown
(in parentheses in this case) after the human form output in non-tools
builds (the size, in sectors, in the size column is not altered)
Much more is available with new options. First is an option (-p) available
in all 3 output forms (which all existed previously), which generates
precisely defined parsable output, which, once this percolates into all
releases, will be allow gpt(8) to be used as a backend tool to manipulate
the gpt tables in for any front end tool anyone wants to create.
When that is not used, new options -A -H and -h can condition the size/start
fields of the default "gpt show" output, and add some additional information
to the "Size: " data line (not the size column) of "gpt show -a" output, the
"gpt show -[ib] N" output is not modified.
gpt show has also grown a -W width option (and when that is not used, a
- -w alternative for when no other value can be found) for setting the desired
output width (and a little data, generated with the new options above, can be
aligned to the right margin - to defeat that, -W1 works).
The manual page has been updated to document all of the above, the scaling 'K'
allowed for the -s sectorsize general option added in a previous commit,
and many wording, formatting, and random other changes have also been applied.
Most of the "gpt show" output changes should be considered as
exploratory, to see what works, and what people are happy with.
Feel free to test, and comment upon how it seems, or could be
improved.
To generate a diff of this commit:
cvs rdiff -u -r1.86 -r1.87 src/sbin/gpt/gpt.8
cvs rdiff -u -r1.48 -r1.49 src/sbin/gpt/show.c
Please note that diffs are not public domain; they are subject to the
copyright notices on the relevant files.
State-Changed-From-To: open->feedback
State-Changed-By: kre@NetBSD.org
State-Changed-When: Wed, 11 Feb 2026 14:33:30 +0000
State-Changed-Why:
Does what gpt(8) is able to do now meet your needs?
>Unformatted:
(Contact us)
$NetBSD: query-full-pr,v 1.49 2026/05/14 01:52:41 riastradh Exp $
$NetBSD: gnats_config.sh,v 1.10 2026/05/13 22:00:09 riastradh Exp $
Copyright © 1994-2026
The NetBSD Foundation, Inc. ALL RIGHTS RESERVED.
Home