Bug 229977 - geom/gpart does not care about GPT size, silently creates partitions that won't be persisted after reboot
Summary: geom/gpart does not care about GPT size, silently creates partitions that won...
Status: New
Alias: None
Product: Base System
Classification: Unclassified
Component: kern (show other bugs)
Version: CURRENT
Hardware: Any Any
: --- Affects Only Me
Assignee: freebsd-geom mailing list
Depends on:
Reported: 2018-07-23 12:03 UTC by Greg V
Modified: 2018-08-07 02:24 UTC (History)
4 users (show)

See Also:


Note You need to log in before you can comment on or make changes to this bug.
Description Greg V 2018-07-23 12:03:01 UTC
So I've been trying to depenguinate a VPS that doesn't allow additional drives to be mounted. pivot_root into a tmpfs on Linux, dd the FreeBSD memstick image onto the disk, reboot into the installer, partition using shell, gpart recover (to move backup GPT to the end), gpart add, zpool create, etc. etc., install, reboot. Oops, no ZFS pools found. Booting into the installer again, and that third GPT partition I created simply does not exist!

Turns out the partition table size is limited to 2 entries.

Linux's gdisk utility is smart: trying to create a partition results in an error: "No table partition entries left".

While geom/gpart did not check the size and just created a partition that actually silently was not saved!!

Using expert mode in gdisk, I resized the partition table from 2 entries to 4 (using 128 results in "Main partition table overlaps the first partition by 31 blocks! Try reducing the partition table size by 124 entries.", but hey, 4 is enough for the VPS.) And everything worked fine.

Other people have stumbled upon this before: https://lists.freebsd.org/pipermail/freebsd-questions/2018-January/280562.html
Comment 1 Emmanuel Vadot freebsd_committer 2018-07-23 17:30:20 UTC
Can you paste output of gpart show at each step ?

GPT can hold way more than 2 partitions.
Comment 2 Rodney W. Grimes freebsd_committer 2018-07-23 17:47:14 UTC
(In reply to Emmanuel Vadot from comment #1)

The key word here is *can*, but part of a gpt header is the number of entries in the gpt, which typically defaults to 128, but can contain other values.

I suspect some tool wrote a gpt header with offset 80 == 2.
Comment 3 Emmanuel Vadot freebsd_committer 2018-07-23 17:49:55 UTC
(In reply to Rodney W. Grimes from comment #2)

Yes, that's what I want to confirm.
I'm gonna have access to a machine there (scaleway) thanks to some friends who work there.
We might not do the right thing when such small gpt table
Comment 4 Greg V 2018-07-23 17:59:38 UTC
(In reply to Rodney W. Grimes from comment #2)

I don't think that's Scaleway specific.

The GPT in question comes from this memstick image:


The memstick is not *intended* to be extended with other partitions, so I guess that's understandable!

On the other hand, it's not like the amount of space a larger GPT takes is of any significance, the installer partition is over 500 megs :D

The actual problem is indeed that gpart is not doing the right thing when running out of available partition table entries.
Comment 5 Emmanuel Vadot freebsd_committer 2018-07-23 18:02:42 UTC
(In reply to Greg V from comment #4)

Oh !!! I didn't understood that you were dealing with the memstick image...
So the memstick is created with mkimg, we can start by changing it so more partition space is allocated.
Then gpart need love too.
Comment 6 Ed Maste freebsd_committer 2018-07-24 14:05:30 UTC
It looks like gpart creates a GPT with a minimum of 128 entries, we probably want to have mkimg do the same. Possibly with a command-line flag to override for cases e.g. where the user is trying to create a minimal-sized image.
Comment 7 yu shan wei 2018-08-03 03:20:41 UTC
(In reply to Ed Maste from comment #6)
I hope gpart can make a small partition table, 3 or 4....
Comment 8 yu shan wei 2018-08-07 02:24:49 UTC
57:CTASSERT(sizeof(struct gpt_ent) == 128);
144:.gps_minent = 128,
470:if (hdr->hdr_entries == 0 || hdr->hdr_entsz < 128 ||
471:(hdr->hdr_entsz & 7) != 0)