GNU bug report logs - #56996
gpt_partition_set_system possible regression

Previous Next

To reply to this bug, email your comments to 56996 AT debbugs.gnu.org.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Mathieu Othacehe <othacehe <at> gnu.org>
To: bug-parted <at> gnu.org
Subject: gpt_partition_set_system possible regression
Date: Fri, 05 Aug 2022 09:14:26 +0200

Hello,

In GNU Guix we are using GNU Parted via Guile-Parted bindings. Upgrading
from Parted 3.4 to Parted 3.5 we discovered a possible regression.

We are creation a new partition on a gpt disk this way:

ped_partition_new (ext4)
ped_partition_set_flag (PED_PARTITION_BIOS_GRUB)
ped_partition_set_system (ext4)

Since 15c49ec04f7eaff014d2e1eddd0aecf4150db63d, ped_partition_set_system
forces the gpt_part_data->type to PARTITION_LINUX_DATA_GUID, whereas it
used to conserve the gpt_part_data->type to PARTITION_BIOS_GRUB_GUID.

This forces us to reverse the ped_partition_set_system and
ped_partition_set_flag call order. Is that expected?

Thanks,

Mathieu

Message #8 received at 56996 <at> debbugs.gnu.org (full text, mbox):

From: "Brian C. Lane" <bcl <at> redhat.com>
To: Mathieu Othacehe <othacehe <at> gnu.org>
Cc: parted-devel <at> lists.alioth.debian.org, 56996 <at> debbugs.gnu.org
Subject: Re: bug#56996: gpt_partition_set_system possible regression
Date: Fri, 5 Aug 2022 11:04:24 -0700

On Fri, Aug 05, 2022 at 09:14:26AM +0200, Mathieu Othacehe wrote:
> 
> Hello,
> 
> In GNU Guix we are using GNU Parted via Guile-Parted bindings. Upgrading
> from Parted 3.4 to Parted 3.5 we discovered a possible regression.
> 
> We are creation a new partition on a gpt disk this way:
> 
> ped_partition_new (ext4)
> ped_partition_set_flag (PED_PARTITION_BIOS_GRUB)
> ped_partition_set_system (ext4)
> 
> Since 15c49ec04f7eaff014d2e1eddd0aecf4150db63d, ped_partition_set_system
> forces the gpt_part_data->type to PARTITION_LINUX_DATA_GUID, whereas it
> used to conserve the gpt_part_data->type to PARTITION_BIOS_GRUB_GUID.
> 
> This forces us to reverse the ped_partition_set_system and
> ped_partition_set_flag call order. Is that expected?

I'm trying to recall why I approved that change. You're right, calling
set_system does set the GUID back to the default for the filesystem.

You shouldn't even need to call set_system in this case, you already set
it with the call to _new(ext4), and set_flag will leave it set as long
as you are turning a flag on. When you turn a flag off it has to figure
out what to fall back to, so in that case it will call set_system to
return to the default for the filesystem or LINUX_DATA if there is no
filesystem set.

I *think* I was considering the previous behavior a bug, we have a test
that had been disabled for years (t3200 which tests the same thing on
msdos) and these changes made it work again.

I'm not entirely sure what to do about this. It's obviously a change in
behavior, but it's a result of a big improvement in the code that I'd
rather not revert. I should have bumped the library version to indicate
this.

I'm cc'ing this to the parted-devel list to get more input on how to go
forward.

Brian

-- 
Brian C. Lane (PST8PDT) - weldr.io - lorax - parted - pykickstart

Message #11 received at submit <at> debbugs.gnu.org (full text, mbox):

From: "Brian C. Lane" <bcl <at> redhat.com>
To: bug-parted <at> gnu.org
Subject: Re: bug#56996: gpt_partition_set_system possible regression
Date: Wed, 10 Aug 2022 09:25:18 -0700

On Fri, Aug 05, 2022 at 09:14:26AM +0200, Mathieu Othacehe wrote:
> 
> Hello,
> 
> In GNU Guix we are using GNU Parted via Guile-Parted bindings. Upgrading
> from Parted 3.4 to Parted 3.5 we discovered a possible regression.
> 
> We are creation a new partition on a gpt disk this way:
> 
> ped_partition_new (ext4)
> ped_partition_set_flag (PED_PARTITION_BIOS_GRUB)
> ped_partition_set_system (ext4)
> 
> Since 15c49ec04f7eaff014d2e1eddd0aecf4150db63d, ped_partition_set_system
> forces the gpt_part_data->type to PARTITION_LINUX_DATA_GUID, whereas it
> used to conserve the gpt_part_data->type to PARTITION_BIOS_GRUB_GUID.
> 
> This forces us to reverse the ped_partition_set_system and
> ped_partition_set_flag call order. Is that expected?

I've proposed this set of patches to fix this, if possible could you
test them out with your application?

https://alioth-lists.debian.net/pipermail/parted-devel/2022-August/005819.html

Thanks,

Brian
-- 
Brian C. Lane (PST8PDT) - weldr.io - lorax - parted - pykickstart

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.