On Wed, Oct 29, 2025 at 10:06:23PM +0100, Pascal Hambourg wrote: > 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.
I've tried to figure out where this could be going wrong, but am not seeing it. When gpt_alloc is called it sets gpt_disk_data->entry_count to the default. But when gpt_read is called it calls _parse_header, and parse_header sets entry_count from the value it read from the header (gpt->NumberOfPartitionEntries). So as long as ped_disk_new is called the entry_count should be correct and used everywhere. So I'm not sure how you are seeing the behavior you are describing. I do agree that parted has problems with relocated partition tables, I think the first thing to do there is to detect that and raise an exception instead of rewriting it to LBA 2. Brian -- Brian C. Lane (PST8PDT) - weldr.io - lorax - parted - pykickstart
