Package: parted Version: 3.6 Severity: minor Dear maintainers,
When libparted reads an existing empty GPT partition table, it wrongly creates the main and backup virtual metadata partitions with a length based on GPT_DEFAULT_PARTITION_ENTRIES (128) instead of the actual partition table length based on NumberOfPartitionEntries in the GPT header. Only after an active partition is added (either read from the on-disk partition table or new), the metadata partitions have the correct length.
Looking at libparted/label/gpt.c, it seems that gpt_read() initializes the partition table object with GPT_DEFAULT_PARTITION_ENTRIES and does not trigger an update of metadata and free space after parsing the GPT header but only when partitions are added.
(My use case is with partman, the Debian installer partitioning tool based on libparted. I need to check whether the current GPT metadata would overlap with U-Boot location for Allwinner sunxi SoCs starting at offset 8KiB (sector 16). A GPT partition table with a maximum length of 56 entries can be created with gdisk and ends at sector 15 so is compatible with U-Boot for sunxi. But when the GPT partition table is empty, the reported metadata length is inaccurate.)
As a workaround, is there a simple reliable way using libparted API to update metadata without altering the state of the partition table ?
Otherwise, what is the best place and way to fix this in libparted, in other word make sure metadata and free space are properly updated when the partition table is empty ? IIUC it involves _disk_push_update_mode() and _disk_pop_update_mode() which can be called only in libparted/disk.c.
