Date: Tue, 27 Dec 2016 18:48:23 +1100 (EST) From: Ian Smith <smithi@nimnet.asn.au> To: Perry Hutchison <perryh@pluto.rain.com> Cc: marcel@freebsd.org, freebsd-stable@freebsd.org Subject: Re: bugs in memstick GPT table, and in gpart(8) Message-ID: <20161227180352.I26979@sola.nimnet.asn.au> In-Reply-To: <5861e26b.HX9c2TvEoZnz0K2K%perryh@pluto.rain.com> References: <57e87099.y0HRwon108cNG6uj%perryh@pluto.rain.com> <57ddefcf.jk4kZ2Kp%2BEcHfcFr%perryh@pluto.rain.com> <57d4c674.bo2VPtTSitHw8Suf%perryh@pluto.rain.com> <58606c72.4VCGEwexwvhtqyXW%perryh@pluto.rain.com> <20161227012948.K26979@sola.nimnet.asn.au> <5861e26b.HX9c2TvEoZnz0K2K%perryh@pluto.rain.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, 26 Dec 2016 19:39:23 -0800, Perry Hutchison wrote: > Ian Smith <smithi@nimnet.asn.au> wrote: > > On Sun, 25 Dec 2016 17:03:46 -0800, Perry Hutchison wrote: > > > ... > > > 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 ... > > > > > > 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. > > > > That would be mkimg(1). Recall that the 10.3-R amd64 memstick.img still > > (or rather, again?) used the BSD scheme (daXa) rather than GPT, due to a > > some-BIOSes issue. In 11+ both use mkimg, both adding a 1MB 'vestigial' > > swap partition to keep some BIOSes happy (thanks to Glen who pointed me > > to the relevant r265017) > > There is something truly horrifying about a report that "some BIOSes" > require a FreeBSD-swap partition in order to boot. (I could understand > FreeBSD _itself_ insisting on having a swap partition, but the BIOS?) Sorry, my bad paraphrasing; I should have quoted Revision 265017: "loader's GPT support on BIOS does not seem to like the root filesystem being the last filesystem on the disk for some reason when made by this script. Add a vestigial swap partition to allow this to boot with QEMU BIOS." So being a swap partition, rather than any other type, is irrelevant and likely just the easiest to specify empty, as '-p freebsd-swap::1M' While visiting the littlest room, before breakfast and after reading and while pondering yours, it occurred to me that for your stated purpose of adding another partition for packages, you might get away - after using 'gpart recover' to make the rest of your memstick available - with just deleting that 1M swap partition, then adding your new partition? You'd still only have 3 partitions, so gpart should(?) be happy. Worth a try? If that works, it should also work on the amd64 stick with 4 partitions. [..] > > Have you checked this against an 11.0-RELEASE-i386-memstick.img ? > > I hadn't, because I don't generally deal with .0 releases :) > but I just checked and it still has gpt_hdr.hdr_entries == 3. That still seems odd (in both senses of the word :) [.. I may follow up on other stuff later, if sensible .. except: ] > IMO it should either have enforced the limit of 3 -- with an accurate > message (not FreeBSD 8's misleading "No space left on device") -- or > incremented it (that being possible in this case since there was room > to enlarge the table). However ... > > > It didn't even need to allocate another table sector, as going from > > 4 to 5 or more would. > > Allocating another sector would be a _very_ large and risky > operation if, as would usually be the case, the sector needed for > expansion of the primary table is part of an already-created (and, > in this case, not-empty) partition. Yes, that was a totally dumb idea, too late at night. I already knew the first (freebsd-boot) partition started at (the next) LBA 3 .. cheers, Ian
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20161227180352.I26979>