Date: Sun, 25 Dec 2016 17:03:46 -0800 From: perryh@pluto.rain.com (Perry Hutchison) To: freebsd-stable@freebsd.org Subject: bugs in memstick GPT table, and in gpart(8) Message-ID: <58606c72.4VCGEwexwvhtqyXW%perryh@pluto.rain.com> In-Reply-To: <57e87099.y0HRwon108cNG6uj%perryh@pluto.rain.com> References: <57e87099.y0HRwon108cNG6uj%perryh@pluto.rain.com> <57ddefcf.jk4kZ2Kp%2BEcHfcFr%perryh@pluto.rain.com> <57d4c674.bo2VPtTSitHw8Suf%perryh@pluto.rain.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Some months ago:
> I dd'd FreeBSD-10.3-RELEASE-i386-memstick.img to a 4GB flash drive,
> and booted it into single-user mode where it appeared as da0. Then,
> to resize the GPT to the media (to make space for another partition):
>
> # gpart show da0
> # gpart recover da0
> # gpart show da0
>
> which appeared to work ... [but] when I tried to create a 4th
> partition in that free space:
>
> # gpart show da0 # showed 3 partitions and about 3GB of free space
> # gpart add -t freebsd-ufs da0 # reported "da0p4 added"
> # gpart show da0 # showed 4 partitions including the new one, and
> # no free space -- as expected
> # shutdown -r now
>
> a "gpart show da0" after the reboot showed 3 partitions and about
> 3GB of free space, the same as before the "gpart add" operation.
> In other words, the new partition did not survive the reboot.
I finally had time to track down what was going on, and it turns
out that both the 10.3 GPT support, and the construction of the
10.3-RELEASE-i386-memstick, are buggy.
Details:
The 10.3-RELEASE-i386-memstick has the smallest possible GPT table
(one sector), three GPT table entries (boot, rootfs, & swap), and
hdr_entries == 3 in the GPT header. Despite that setting, the
"gpart add" operation did create a fourth table entry -- and the
new entry was (temporarily) available for the system to use (e.g.
I was able to run an apparently-successful newfs on it).
A subsequent hexdump(1) of the GPT table sector showed that the new
entry had even been written to the device. However, after a reboot
(or, likely, any event causing the device to be tasted again), the
hdr_entries setting causes the new, fourth entry to be ignored:
only the three original entries are recognized.
Bugs:
Since the GPT table is always a whole number of sectors, and each
sector has room for four GPT table entries, there's no reason for
hdr_entries not to be a multiple of 4. Whatever constructed the
10.3-RELEASE-i386-memstick image should have rounded it up.
The GPT support in the kernel and in gpart(8) should handle
hdr_entries consistently: either always round it up to a multiple
of four, or always take it at face value. It should not be possible
for gpart(8) to create a partition which will effectively disappear
the next time the provider is tasted.
The willingness of gpart(8) to add a partition exceeding the defined
size of the GPT table is a recent regression (as well as, arguably,
a buffer overrun): Under the same conditions the FreeBSD 8 version
of gpart(8) complained "gpart: index '4': No space left on device".
(The message is wrong -- it should be something like "Partition
table full" -- but apart from the misleading message the situation
seems to have been handled correctly.) Meanwhile even FreeBSD 8's
gpart(8) is less helpful than its predecessor, gpt(8). Trying to
perform this same operation on FreeBSD 6 produces:
# gpt -r show da0
start size index contents
0 1 PMBR
1 1 Pri GPT header
2 1 Pri GPT table
3 32 1 GPT part - 83bd6b9d-7f41-11dc-be0b-001560b84f0f
35 1348832 2 GPT part - FreeBSD UFS/UFS2
1348867 2048 3 GPT part - FreeBSD swap
1350915 6460155
7811070 1 Sec GPT table
7811071 1 Sec GPT header
# gpt add da0
gpt add: da0: error: no available table entries
# gpt add -i 4 da0
gpt add: da0: error: index 4 out of range (3 max)
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?58606c72.4VCGEwexwvhtqyXW%perryh>