bug#79720: libparted: wrong metadata length with empty GPT partition table

Pascal Hambourg <[email protected]> Tue, 4 Nov 2025 10:59:00 +0100
Newsgroups gmane.comp.gnu.parted.bugs
Organization Plouf !
Message-ID <[email protected]>
On 03/11/2025 à 22:45, Brian C. Lane wrote:
> On Sat, Nov 01, 2025 at 12:00:40AM +0100, Pascal Hambourg wrote:
>>
>> Indeed _parse_header updates entry_count, but then _disk_pop_update_mode
>> (which updates metadata and free space partitions) is called only if the
>> partition table has at least one active partition. Or later when a new
>> partition is created, or the pmbr_boot flag is set.
> 
> Ah, ok. Now it's clear :) Thanks for that.
> 
>> I quickly tested that surrounding the call to type->ops->read with
>> _disk_push_update_mode and _disk_pop_update_mode in ped_disk_new seems to
>> fix the issue:
(...)> This doesn't pass the tests -- gpt_read calls ped_disk_commit_to_dev
> when it needs to fix one of the headers, and that has an assert check on
> update_mode.

Oops, my poor knowledge of parted made me miss that.

> But, while it seems a bit like a kludge, I think we could just do a
> push/pop right after doing the read instead of wrapping it. That at
> least passes the tests and I don't think it would have any unexpected
> side-effects.

You know parted better and I cannot come with another suggestion. Want 
me to submit the trivial patch ?

>> But I am now working on a larger patch which aims to stay in update mode and
>> avoid useless transient metadata and free space partition updates until
>> after reading the partition table.

Never mind, if type->ops->read must not be called while the disk is in 
update mode then this approach cannot work.