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.