Revert revision 254095

[marcel]

Summary

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.

[ae]

I have no objection. AFAIR, the main goal of this change was the adding ability to extend number of entries for some tables, that have very little number of partition entries, e.g. 1 or 2.
I think if you revert this change, then you will not able to add new partitions for these tables, even if there are enough space to keep them.

[val_packett.cool]

In D19438#416304, @ae wrote:

I have no objection. AFAIR, the main goal of this change was the adding ability to extend number of entries for some tables, that have very little number of partition entries, e.g. 1 or 2.
I think if you revert this change, then you will not able to add new partitions for these tables, even if there are enough space to keep them.

Yeah, my bug report (bug 229977) was about adding new partitions to a memstick image with 2 partitions. The new partition would get created in memory, but would silently disappear after a reboot (i.e. wouldn't persist), which was extremely surprising and unexpected.