Processed: Bug#1093565: partman: changing partition usage may leave the wrong type in partition table

[Debian Bug Tracking System]

Processing commands for cont...@bugs.debian.org:

> tags 1093565 pending
Bug #1093565 [partman-base] partman: changing partition usage may leave the 
wrong type in partition table
Added tag(s) pending.
> thanks
Stopping processing here.

Please contact me if you need assistance.
-- 
1093565: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1093565
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems

Bug#1093565: partman: changing partition usage may leave the wrong type in partition table

[Holger Wansing]

Hi,

Holger Wansing  wrote (Sat, 14 Feb 2026 14:16:34 +0100):
> I have finished testing all of the above except partman-cros and partman-prep.
> For those, I have no hardware or other possibilities for installation, so I 
> cannot test them.
> 
> Is anybody willing to do some testing for those?

With the help from Pascal I managed to test the remaining packages as well,
so I'm done with all now.
I will merge and upload them shortly, if there are no objections.


Holger


-- 
Holger Wansing 
PGP-Fingerprint: 496A C6E8 1442 4B34 8508  3529 59F1 87CA 156E B076

Bug#1093565: partman: changing partition usage may leave the wrong type in partition table

[Holger Wansing]

Hi,

Pascal Hambourg  wrote (Sun, 21 Dec 2025 18:22:59 
+0100):
> On 21/12/2025 at 13:17, Holger Wansing wrote:
> > 
> > My proposal would be, to point to this bug from all the MRs and vice versa,
> > and close the bug, when we are done with all
> MRs opened for affected packages:
> 
> 
> 
> 
> 
> 

Sorry for some delay, my tests took some time, due to some AFK time, because
of personal topics.

I have finished testing all of the above except partman-cros and partman-prep.
For those, I have no hardware or other possibilities for installation, so I 
cannot test them.

Is anybody willing to do some testing for those?


Holger

-- 
Holger Wansing 
PGP-Fingerprint: 496A C6E8 1442 4B34 8508  3529 59F1 87CA 156E B076

Bug#1093565: partman: changing partition usage may leave the wrong type in partition table

[Pascal Hambourg]

On 21/12/2025 at 13:17, Holger Wansing wrote:


My proposal would be, to point to this bug from all the MRs and vice versa,
and close the bug, when we are done with all

MRs opened for affected packages:







In a previous mail I also mentioned partman-auto and 
partman-basicmethods but AFAICS they are not affected by this bug. Using 
SET_FLAG instead of GET_FLAGS+SET_FLAGS would just make their code a bit 
simpler.

Bug#1093565: partman: changing partition usage may leave the wrong type in partition table

[Pascal Hambourg]

On 21/12/2025 at 13:17, Holger Wansing wrote:

Pascal Hambourg  wrote (Sun, 21 Dec 2025 09:40:41 
+0100):


When it it uploaded I will start submitting MRs for other packages which
should use the new SET_FLAG command instead of SET_FLAGS. Only when this
is done the bug will be fixed, so I am not sure how to close this bug.


The perfect solution will most probably be, to clone this bug for every
involved package, but I'm not sure, if it's worth it.


I had the same idea after sending the mail. Also each clone could be 
marked as blocked by the original bug.



You already have the Affects set accordingly, that should be enough.
My proposal would be, to point to this bug from all the MRs and vice versa,
and close the bug, when we are done with all --- if noone corrects me ;-)


We can do this, but then the bug must not be marked as closed in any of 
the related commits or changelogs.

Bug#1093565: partman: changing partition usage may leave the wrong type in partition table

[Holger Wansing]

Hi,

Pascal Hambourg  wrote (Sun, 21 Dec 2025 09:40:41 
+0100):
> Hi Holger,
> 
> On 20/12/2025 à 21:15, Holger Wansing wrote:
> > 
> > No objections so far, so I will merge
> > 
> > then.
> 
> When it it uploaded I will start submitting MRs for other packages which 
> should use the new SET_FLAG command instead of SET_FLAGS. Only when this 

Yes, that allows easy testing of that changings before merging, so that was my 
plan as well.

> is done the bug will be fixed, so I am not sure how to close this bug.

The perfect solution will most probably be, to clone this bug for every
involved package, but I'm not sure, if it's worth it.

You already have the Affects set accordingly, that should be enough.
My proposal would be, to point to this bug from all the MRs and vice versa,
and close the bug, when we are done with all --- if noone corrects me ;-)

> Also, should I add a version dependency in these packages control ?

Yes, that would be good.


Holger


-- 
Holger Wansing 
PGP-Fingerprint: 496A C6E8 1442 4B34 8508  3529 59F1 87CA 156E B076

Bug#1093565: partman: changing partition usage may leave the wrong type in partition table

[Pascal Hambourg]

Hi Holger,

On 20/12/2025 à 21:15, Holger Wansing wrote:


No objections so far, so I will merge

then.


When it it uploaded I will start submitting MRs for other packages which 
should use the new SET_FLAG command instead of SET_FLAGS. Only when this 
is done the bug will be fixed, so I am not sure how to close this bug.


Also, should I add a version dependency in these packages control ?


(and MR!12 can be closed then, right?)


Yes. I will close it.

Bug#1093565: partman: changing partition usage may leave the wrong type in partition table

[Holger Wansing]

Hi,

Holger Wansing  wrote (Sat, 13 Dec 2025 12:12:16 +0100):
> Hi,
> 
> Pascal Hambourg  wrote (Sun, 26 Jan 2025 11:55:23 
> +0100):
> > On 23/01/2025 at 12:45, Pascal Hambourg wrote:
> > > On 20/01/2025 at 00:01, Pascal Hambourg wrote:
> > >>
> > >> Possible mitigations/solutions:
> > > (...)
> > >> 3) Modify parted_server to set only the last type flag when processing 
> > >> a SET_FLAGS command (all scripts send the new flag last).
> > >> Advantage: no need to change affected packages.
> > >> Downsides: changes SET_FLAGS behaviour; needs to be updated whenever 
> > >> libparted supports a new flag.
> > >>
> > >> 4) Modify parted_server to add a new SET_FLAG command which sets a 
> > >> single flag and use it in synchronization scripts.
> > >> Downside: requires a change in all affected packages.
> > >>
> > >> I think solution #3 is the best because it requires changes only in 
> > >> partman-base to fully fix the issue.
> > > 
> > > At least in the short term (for trixie ?). But I think solution #4 would 
> > > be better, simpler and more reliable in the long term without the need 
> > > to classify flags.
> > 
> > And it does not change the SET_FLAGS command behaviour, so no unexpected 
> > side-effect can happen.
> > 
> > > I implemented the SET_FLAG command in parted_server 
> > > and tested it successfully with the "boot" flag.
> > 
> > It does not mark the partition table changed if the flag is unknown, 
> > invalid for the partition or already has the desired state, so no need 
> > to check if the flag is valid nor its current state. When a flag is set 
> > on, conflicting flags are implicitly set off, so no need to explicitly 
> > do it. Just send the command with the desired flag and state.
> > 
> > MR created: 
> > 
> > 
> > The following packages must be updated to take advantage of the new 
> > SET_FLAG command:
> > 
> > partman-auto
> > partman-basicmethods
> > partman-cros
> > partman-efi
> > partman-lvm
> > partman-md
> > partman-newworld
> > partman-partitioning
> > partman-prep
> 
> partman-newworld and partman-prep are no longer in use AFAIK.
> 
> > I have updates ready for each of them. Example: 
> > 
> 
> Any objections against this approach?
> 
> I would merge the above MR for partman-base as the starting point then, if 
> noone objects...


No objections so far, so I will merge 

then.

(and MR!12 can be closed then, right?)


Holger


-- 
Holger Wansing 
PGP-Fingerprint: 496A C6E8 1442 4B34 8508  3529 59F1 87CA 156E B076

Bug#1093565: partman: changing partition usage may leave the wrong type in partition table

[Pascal Hambourg]

On 17/12/2025 at 12:55, Cyril Brulebois wrote:

Pascal Hambourg  (2025-12-17):


I have no idea of how udebs to be included in ISO images are selected...
maybe all udebs available for the architecture are included by default ?


That's the reason behind <20250515030823.lqququzhma44r...@mraw.org>


List archive URL: 




(which you've seen).


My memory is not what it used to be any more. I even forget about some 
of my own works after a few months...



See tools/generate_di_list (in debian-cd.git)
and its looping over Packages files.


Thank you and Steve for the pointers.

Regarding partman-newworld, it is not in the Debian archive any more and 
the git repository has not been updated for quite some time. What is the 
status of such d-i package ? Abandoned ?

Bug#1093565: partman: changing partition usage may leave the wrong type in partition table

[Steve McIntyre]

On Wed, Dec 17, 2025 at 12:38:07PM +0100, Pascal Hambourg wrote:
>On 16/12/2025 at 23:38, Holger Wansing wrote:
>> Pascal Hambourg  wrote (Sat, 13 Dec 2025 13:03:54 
>> +0100):
>> > 
>> > AFAICS partman-prep is still included in ppc64el images, and
>> > grub-installer still looks for a PReP boot partition.
>> 
>> I'm curious how this works, since partman-prep is not mentioned in
>> https://salsa.debian.org/installer-team/debian-installer/-/tree/master/build/config?ref_type=heads
>> but you are right, it's included there.
>
>I have no idea of how udebs to be included in ISO images are selected. I can
>only guess that debian-installer picks udebs to be included in d-i initrds,
>and debian-cd picks udebs to be included in ISO images. However debian-cd
>udeb include lists contain very few packages. Exclude lists are bigger, so
>maybe all udebs available for the architecture are included by default ?

There's code in debian-cd (tools/generate_di_list) which will include
all the extra udebs unless:

1. they are excluded
2. they are kernel driver udebs for older kernel ABIs

-- 
Steve McIntyre, Cambridge, UK.st...@einval.com
Dance like no one's watching. Encrypt like everyone is.
 - @torproject

Bug#1093565: partman: changing partition usage may leave the wrong type in partition table

[Cyril Brulebois]

Pascal Hambourg  (2025-12-17):
> On 16/12/2025 at 23:38, Holger Wansing wrote:
> > Pascal Hambourg  wrote (Sat, 13 Dec 2025 13:03:54 
> > +0100):
> > > 
> > > AFAICS partman-prep is still included in ppc64el images, and
> > > grub-installer still looks for a PReP boot partition.
> > 
> > I'm curious how this works, since partman-prep is not mentioned in
> > https://salsa.debian.org/installer-team/debian-installer/-/tree/master/build/config?ref_type=heads
> > but you are right, it's included there.
> 
> I have no idea of how udebs to be included in ISO images are selected. I can
> only guess that debian-installer picks udebs to be included in d-i initrds,
> and debian-cd picks udebs to be included in ISO images. However debian-cd
> udeb include lists contain very few packages. Exclude lists are bigger, so
> maybe all udebs available for the architecture are included by default ?

That's the reason behind <20250515030823.lqququzhma44r...@mraw.org>
(which you've seen). See tools/generate_di_list (in debian-cd.git)
and its looping over Packages files.


Cheers,
-- 
Cyril Brulebois (k...@debian.org)
D-I release manager -- Release team member -- Freelance Consultant


signature.asc
Description: PGP signature

Bug#1093565: partman: changing partition usage may leave the wrong type in partition table

[Pascal Hambourg]

On 16/12/2025 at 23:38, Holger Wansing wrote:

Pascal Hambourg  wrote (Sat, 13 Dec 2025 13:03:54 
+0100):


AFAICS partman-prep is still included in ppc64el images, and
grub-installer still looks for a PReP boot partition.


I'm curious how this works, since partman-prep is not mentioned in
https://salsa.debian.org/installer-team/debian-installer/-/tree/master/build/config?ref_type=heads
but you are right, it's included there.


I have no idea of how udebs to be included in ISO images are selected. I 
can only guess that debian-installer picks udebs to be included in d-i 
initrds, and debian-cd picks udebs to be included in ISO images. However 
debian-cd udeb include lists contain very few packages. Exclude lists 
are bigger, so maybe all udebs available for the architecture are 
included by default ?

Bug#1093565: partman: changing partition usage may leave the wrong type in partition table

[Holger Wansing]

Hi,

Pascal Hambourg  wrote (Sat, 13 Dec 2025 13:03:54 
+0100):
> Hi Holger,
> 
> On 13/12/2025 at 12:12, Holger Wansing wrote:
> > 
> > partman-newworld and partman-prep are no longer in use AFAIK.
> 
> AFAICS partman-prep is still included in ppc64el images, and 
> grub-installer still looks for a PReP boot partition.

I'm curious how this works, since partman-prep is not mentioned in
https://salsa.debian.org/installer-team/debian-installer/-/tree/master/build/config?ref_type=heads
but you are right, it's included there.


Holger


-- 
Holger Wansing 
PGP-Fingerprint: 496A C6E8 1442 4B34 8508  3529 59F1 87CA 156E B076

Bug#1093565: partman: changing partition usage may leave the wrong type in partition table

[Pascal Hambourg]

Hi Holger,

On 13/12/2025 at 12:12, Holger Wansing wrote:


partman-newworld and partman-prep are no longer in use AFAIK.


AFAICS partman-prep is still included in ppc64el images, and 
grub-installer still looks for a PReP boot partition.


I don't know about partman-newworld, it seems to be an old PowerMac thing.

Bug#1093565: partman: changing partition usage may leave the wrong type in partition table

[Holger Wansing]

Hi,

Pascal Hambourg  wrote (Sun, 26 Jan 2025 11:55:23 
+0100):
> On 23/01/2025 at 12:45, Pascal Hambourg wrote:
> > On 20/01/2025 at 00:01, Pascal Hambourg wrote:
> >>
> >> Possible mitigations/solutions:
> > (...)
> >> 3) Modify parted_server to set only the last type flag when processing 
> >> a SET_FLAGS command (all scripts send the new flag last).
> >> Advantage: no need to change affected packages.
> >> Downsides: changes SET_FLAGS behaviour; needs to be updated whenever 
> >> libparted supports a new flag.
> >>
> >> 4) Modify parted_server to add a new SET_FLAG command which sets a 
> >> single flag and use it in synchronization scripts.
> >> Downside: requires a change in all affected packages.
> >>
> >> I think solution #3 is the best because it requires changes only in 
> >> partman-base to fully fix the issue.
> > 
> > At least in the short term (for trixie ?). But I think solution #4 would 
> > be better, simpler and more reliable in the long term without the need 
> > to classify flags.
> 
> And it does not change the SET_FLAGS command behaviour, so no unexpected 
> side-effect can happen.
> 
> > I implemented the SET_FLAG command in parted_server 
> > and tested it successfully with the "boot" flag.
> 
> It does not mark the partition table changed if the flag is unknown, 
> invalid for the partition or already has the desired state, so no need 
> to check if the flag is valid nor its current state. When a flag is set 
> on, conflicting flags are implicitly set off, so no need to explicitly 
> do it. Just send the command with the desired flag and state.
> 
> MR created: 
> 
> 
> The following packages must be updated to take advantage of the new 
> SET_FLAG command:
> 
> partman-auto
> partman-basicmethods
> partman-cros
> partman-efi
> partman-lvm
> partman-md
> partman-newworld
> partman-partitioning
> partman-prep

partman-newworld and partman-prep are no longer in use AFAIK.

> I have updates ready for each of them. Example: 
> 

Any objections against this approach?

I would merge the above MR for partman-base as the starting point then, if 
noone objects...


Holger


-- 
Holger Wansing 
PGP-Fingerprint: 496A C6E8 1442 4B34 8508  3529 59F1 87CA 156E B076

Bug#1093565: partman: changing partition usage may leave the wrong type in partition table

[Pascal Hambourg]

On 23/01/2025 at 12:45, Pascal Hambourg wrote:

On 20/01/2025 at 00:01, Pascal Hambourg wrote:


Possible mitigations/solutions:

(...)
3) Modify parted_server to set only the last type flag when processing 
a SET_FLAGS command (all scripts send the new flag last).

Advantage: no need to change affected packages.
Downsides: changes SET_FLAGS behaviour; needs to be updated whenever 
libparted supports a new flag.


4) Modify parted_server to add a new SET_FLAG command which sets a 
single flag and use it in synchronization scripts.

Downside: requires a change in all affected packages.

I think solution #3 is the best because it requires changes only in 
partman-base to fully fix the issue.


At least in the short term (for trixie ?). But I think solution #4 would 
be better, simpler and more reliable in the long term without the need 
to classify flags.


And it does not change the SET_FLAGS command behaviour, so no unexpected 
side-effect can happen.


I implemented the SET_FLAG command in parted_server 
and tested it successfully with the "boot" flag.


It does not mark the partition table changed if the flag is unknown, 
invalid for the partition or already has the desired state, so no need 
to check if the flag is valid nor its current state. When a flag is set 
on, conflicting flags are implicitly set off, so no need to explicitly 
do it. Just send the command with the desired flag and state.


MR created: 



The following packages must be updated to take advantage of the new 
SET_FLAG command:


partman-auto
partman-basicmethods
partman-cros
partman-efi
partman-lvm
partman-md
partman-newworld
partman-partitioning
partman-prep

I have updates ready for each of them. Example: 

Bug#1093565: partman: changing partition usage may leave the wrong type in partition table

[Pascal Hambourg]

On 20/01/2025 at 00:01, Pascal Hambourg wrote:


Possible mitigations/solutions:

(...)
3) Modify parted_server to set only the last type flag when processing a 
SET_FLAGS command (all scripts send the new flag last).

Advantage: no need to change affected packages.
Downsides: changes SET_FLAGS behaviour; needs to be updated whenever 
libparted supports a new flag.


4) Modify parted_server to add a new SET_FLAG command which sets a 
single flag and use it in synchronization scripts.

Downside: requires a change in all affected packages.

I think solution #3 is the best because it requires changes only in 
partman-base to fully fix the issue.


At least in the short term (for trixie ?). But I think solution #4 would 
be better, simpler and more reliable in the long term without the need 
to classify flags. I implemented the SET_FLAG command in parted_server 
and tested it successfully with the "boot" flag.

Processed: Re: Bug#1093565: partman: changing partition usage may leave the wrong type in partition table

[Debian Bug Tracking System]

Processing control commands:

> tags -1 patch
Bug #1093565 [partman-base] partman: changing partition usage may leave the 
wrong type in partition table
Added tag(s) patch.

-- 
1093565: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1093565
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems

Bug#1093565: partman: changing partition usage may leave the wrong type in partition table

[Pascal Hambourg]

Control: tags -1 patch

On 20/01/2025 at 00:01, Pascal Hambourg wrote:


3) Modify parted_server to set only the last type flag when processing a 
SET_FLAGS command (all scripts send the new flag last).

Advantage: no need to change affected packages.
Downsides: changes SET_FLAGS behaviour; needs to be updated whenever 
libparted supports a new flag.

(...)
I think solution #3 is the best because it requires changes only in 
partman-base to fully fix the issue. However modifying parted_server 
does not seem easy and my C is rusty


Writing a rough implementation was actually not so hard:

Bug#1093565: partman: changing partition usage may leave the wrong type in partition table

[Pascal Hambourg]

Package: partman-base
Version: 226
Affects: partman-cros partman-efi partman-lvm partman-md 
partman-partitioning partman-prep


Background:

Partman is based on libparted which uses "flags" as an abstraction for 
different kinds of partition properties:

- attribute (boot on msdos, legacy_boot and hidden on gpt...)
- type identifier (esp, lvm, raid...)
- type modifier (hidden and lba on msdos)
- name (root and swap on mac)

Attribute flags can be combined but type flags are exclusive. When 
sending a SET_FLAGS command with multiple type flags to parted_server, 
only the one with the highest priority will be set. Type flag priorities 
are as follows:
linux-home > bls_boot > chromeos_kernel > esp > irst > msftdata > diag > 
atvrecv > bios_grub > msftres > prep > palo, hp-service > lvm > raid > 
swap > boot


When a partition usage ("method") is changed, synchronization scripts 
for each supported method/flag are executed in a fixed order and set or 
remove a type flag on the partition by performing the following actions:

- send GET_FLAGS and read the current flags
- if the script manages the new method, send SET_FLAGS with current 
flags and the managed type flag
- if the script does not manage the new method, send SET_FLAGS with 
current flags except the managed type flag


Current synchronization scripts order (may not exist in all 
architectures): biosgrub_sync_flag cros_sync_flag efi_sync_flag 
lvm_sync_flag prep_sync_flag md_sync_flag


This can lead to unexpected results when changing partition usage.

Problem description:

If the new type flag has a lower priority than the current type flag, 
then it is ignored.
When the script which sets a lower priority type flag is executed before 
the script which removes a higher priority type flag (or no script 
manages it), then the lower priority type flag is not set and the 
resulting partition type does not match the new usage.


It is not only confusing when the partition type is informative only 
(LVM, RAID...) but it can also be troublesome when the partition type 
has a special meaning for platform firmware, boot loaders or operating 
systems (ChromeOS kernel, EFI, BIOS boot, PReP).


Some scripts needlessly remove some low priority flags (lvm, raid, swap) 
when setting another flag but do not remove higher priority flags which 
may still be set (chromeos_kernel, esp, msftdata, bios_grub, msftres...).


Examples:
- gpt: Change a partition usage from "ChromeOS" or "EFI" to "BIOS boot" 
-> bios_grub not set.
- gpt, msdos on powerpc, ppc64, ppc64el: Change a partition usage from 
"PReP" to "RAID" -> raid not set.
- gpt: Change a partition usage from "FAT16", "FAT32" or "NTFS" to "BIOS 
boot", "PReP", "LVM" "RAID" -> msftdata set, new flag not set.
- gpt: Use an existing partition of type "Linux home" or "BLS extended 
boot" as "ChromeOS", "EFI" or "BIOS boot" -> old flag set, new flag not set.
- gpt, msdos: Use an existing partition of type "Linux home", "BLS 
extended boot" or "Microsoft Reserved" as "PReP", "LVM" or "RAID" -> old 
flag set, new flag not set.


Possible mitigations/solutions:

1) Change the execution order of synchronization scripts to match type 
flag priorities so that higher priority flags are removed before low 
priority flags are set: cros_sync_flag efi_sync_flag biosgrub_sync_flag 
prep_sync_flag lvm_sync_flag md_sync_flag.
Downsides: high priority type flags which are not managed by partman 
scripts (linux-home, bls_boot, msftdata, msftres...) still cannot be 
removed; requires a change in some affected packages.


2) Remove type flags (and keep only attribute and modifier flags) before 
setting a type flag in synchronization scripts; the scripts could call a 
new function defined in a common library.
Downsides: requires a change in all affected packages; needs to be 
updated whenever libparted supports a new flag.


3) Modify parted_server to set only the last type flag when processing a 
SET_FLAGS command (all scripts send the new flag last).

Advantage: no need to change affected packages.
Downsides: changes SET_FLAGS behaviour; needs to be updated whenever 
libparted supports a new flag.


4) Modify parted_server to add a new SET_FLAG command which sets a 
single flag and use it in synchronization scripts.

Downside: requires a change in all affected packages.

I think solution #3 is the best because it requires changes only in 
partman-base to fully fix the issue. However modifying parted_server 
does not seem easy and my C is rusty, so I began to work on solution #2. 
Meanwhile, maybe solution #1 could be implemented quickly even if it 
does not fix the issue on existing partitions, at least it fixes the 
issue on partitions created by partman.