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) _______________________________________________ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"