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:
- 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.
- 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.