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
Can you paste output of gpart show at each step ? GPT can hold way more than 2 partitions.
(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.
(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
(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: https://download.freebsd.org/ftp/snapshots/arm64/aarch64/ISO-IMAGES/12.0/FreeBSD-12.0-CURRENT-arm64-aarch64-20180719-r336479-mini-memstick.img.xz 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.
(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.
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.
(In reply to Ed Maste from comment #6) I hope gpart can make a small partition table, 3 or 4....
sys/geom/part/g_part_gpt.c: 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) 是不是这几行限制了分区表的大小
At the very least mkimg(1) should round the number of entries to fill the sectors needed.
A commit references this bug: Author: marcel Date: Tue Mar 5 04:15:34 UTC 2019 New revision: 344790 URL: https://svnweb.freebsd.org/changeset/base/344790 Log: Revert revision 254095 In revision 254095, gpt_entries is not set to match the on-disk hdr_entries, but rather is computed based on available space. There are 2 problems with this: 1. The GPT backend respects hdr_entries and only reads and writes that number of partition entries. On top of that, CRC32 is computed over the table that has hdr_entries elements. When the common code works on what is possibly a larger number, the behaviour becomes inconsistent and problematic. In particular, it would be possible to add a new partition that on a reboot isn't there anymore. 2. The calculation of gpt_entries is based on flawed assumptions. The GPT specification does not dictate that sectors are layed out in a particular way that the available space can be determined by looking at LBAs. In practice, implementations do the same thing, because there's no reason to do it any other way. Still, GPT allows certain freedoms that can be exploited in some form or shape if the need arises. PR: 229977 MFC after: 2 weeks Differential Revision: https://reviews.freebsd.org/D19438 Changes: head/sys/geom/part/g_part_gpt.c
Fixing in -CURRENT. Merges to release branches will happen after 2 weeks.
A commit references this bug: Author: marcel Date: Fri Mar 22 23:39:16 UTC 2019 New revision: 345427 URL: https://svnweb.freebsd.org/changeset/base/345427 Log: MFC 344790: Revert revision 254095 In revision 254095, gpt_entries is not set to match the on-disk hdr_entries, but rather is computed based on available space. There are 2 problems with this: 1. The GPT backend respects hdr_entries and only reads and writes that number of partition entries. On top of that, CRC32 is computed over the table that has hdr_entries elements. When the common code works on what is possibly a larger number, the behaviour becomes inconsistent and problematic. In particular, it would be possible to add a new partition that on a reboot isn't there anymore. 2. The calculation of gpt_entries is based on flawed assumptions. The GPT specification does not dictate that sectors are layed out in a particular way that the available space can be determined by looking at LBAs. In practice, implementations do the same thing, because there's no reason to do it any other way. Still, GPT allows certain freedoms that can be exploited in some form or shape if the need arises. PR: 229977 Differential Revision: https://reviews.freebsd.org/D19438 Changes: _U stable/12/ stable/12/sys/geom/part/g_part_gpt.c
A commit references this bug: Author: marcel Date: Sat Mar 23 03:10:24 UTC 2019 New revision: 345434 URL: https://svnweb.freebsd.org/changeset/base/345434 Log: MFC 344790: Revert revision 254095 In revision 254095, gpt_entries is not set to match the on-disk hdr_entries, but rather is computed based on available space. There are 2 problems with this: 1. The GPT backend respects hdr_entries and only reads and writes that number of partition entries. On top of that, CRC32 is computed over the table that has hdr_entries elements. When the common code works on what is possibly a larger number, the behaviour becomes inconsistent and problematic. In particular, it would be possible to add a new partition that on a reboot isn't there anymore. 2. The calculation of gpt_entries is based on flawed assumptions. The GPT specification does not dictate that sectors are layed out in a particular way that the available space can be determined by looking at LBAs. In practice, implementations do the same thing, because there's no reason to do it any other way. Still, GPT allows certain freedoms that can be exploited in some form or shape if the need arises. PR: 229977 Differential Revision: https://reviews.freebsd.org/D19438 Changes: _U stable/11/ stable/11/sys/geom/part/g_part_gpt.c