Bug#1092892: partman-efi: Rework EFI partition management

[Pascal Hambourg]

Package: partman-efi
Version: 101
Tags: patch

Dear maintainers,

EFI partition management by partman-efi has some issues.

1) update.d/efi_sync_flag interferes with the "boot" flag management
done by partman-base and partman-partitioning. But on GPT disk label
parted_server makes the "boot" flag reflect the "esp" flag when getting
flags and ignores the "boot" flag when setting flags, and on MSDOS disk
label the "esp" and "boot" flags are independent.

2) update.d/efi_sync_flag does not remove the "esp" flag from an
existing EFI partition when its method is set to another use.

3) Every time init.d/efi is run (e.g. after configuring LVM or RAID or
committing changes), it changes the method to "efi" on any partition
with the "esp" flag set. If the partition was set to "do not use", it is
set to "use as EFI system partition" again. See bugs #034208 #1034812
#1041168.

In order to address these issues I suggest to change the logic:
- Remove interaction with the 'boot' flag management.
- Remove the 'esp' flag on existing and new EFI partitions when the
method is set to another use.
- Remove the 'esp' flag on new EFI partitions when the method is set to
"do not use".
- Preserve automatic recipe or user's choice to not use existing EFI
partitions.

In order to preserve unused existing EFI partitions (which may be used
by other OS):
- Keep the 'esp' flag on existing EFI partitions when the method is set
to "do not use".
- Restore the 'esp' flag on former existing EFI partitions when the
method is set to "do not use".
- Forget about former EFI partitions when committing changes.

Merge request:
<https://salsa.debian.org/installer-team/partman-efi/-/merge_requests/7>

[Holger Wansing]

- Keep the 'esp' flag on existing EFI partitions when the method is set to "do not use".
- Restore the 'esp' flag on former existing EFI partitions when the method is set to "do not use".
- Forget about former EFI partitions when committing changes.

It seems to me that the last two points conflict?


Holger

[Pascal Hambourg]

Post by Holger Wansing

- Keep the 'esp' flag on existing EFI partitions when the method is set to "do not use".
- Restore the 'esp' flag on former existing EFI partitions when the method is set to "do not use".
- Forget about former EFI partitions when committing changes.

It seems to me that the last two points conflict?

Let me try to clarify. An existing EFI partition is an on-disk ESP. A
new EFI partition is an ESP created by the user or by a recipe and not
committed to disk yet, or an on-disk partition of a different type set
to "use as ESP" by the user. A former EFI partition is an on-disk ESP
set to a different type by the user and not committed to disk yet.

The first two points apply before pending changes are committed to disk,
while they can still be reverted. The last point applies when the
changes are committed to disk: then it does not matter any more if a
partition was previously an ESP, now it is definitely not an ESP.

[Holger Wansing]

Hi,

Post by Holger Wansing

- Keep the 'esp' flag on existing EFI partitions when the method is set to "do not use".
- Restore the 'esp' flag on former existing EFI partitions when the method is set to "do not use".
- Forget about former EFI partitions when committing changes.

It seems to me that the last two points conflict?

Let me try to clarify. An existing EFI partition is an on-disk ESP. A new EFI partition is an ESP created by the user or by a recipe and not committed to disk yet, or an on-disk partition of a different type set to "use as ESP" by the user. A former EFI partition is an on-disk ESP set to a different type by the user and not committed to disk yet.
The first two points apply before pending changes are committed to disk, while they can still be reverted. The last point applies when the changes are committed to disk: then it does not matter any more if a partition was previously an ESP, now it is definitely not an ESP.

Ok, but then would a change from point 2 (restore a esp flag) be
thrown away in point 3, in my understanding, or not?
Hmm, maybe with "Forget about ..." you don't mean "Do not commit such changings" ....
That's how I understood it.


Holger

[Pascal Hambourg]

Post by Holger Wansing

Post by Pascal Hambourg

Post by Holger Wansing

- Keep the 'esp' flag on existing EFI partitions when the method is set to "do not use".
- Restore the 'esp' flag on former existing EFI partitions when the method is set to "do not use".
- Forget about former EFI partitions when committing changes.

It seems to me that the last two points conflict?

Let me try to clarify. An existing EFI partition is an on-disk ESP. A
new EFI partition is an ESP created by the user or by a recipe and not
committed to disk yet, or an on-disk partition of a different type set
to "use as ESP" by the user. A former EFI partition is an on-disk ESP
set to a different type by the user and not committed to disk yet.
The first two points apply before pending changes are committed to disk,
while they can still be reverted. The last point applies when the
changes are committed to disk: then it does not matter any more if a
partition was previously an ESP, now it is definitely not an ESP.

Ok, but then would a change from point 2 (restore a esp flag) be
thrown away in point 3, in my understanding, or not?

No. If the esp flag is restored, the partition is fully an ESP again.

Post by Holger Wansing
Hmm, maybe with "Forget about ..." you don't mean "Do not commit such changings"

No, I mean that the partition has been committed to disk with a new type
so partman must act as if the partition never was an ESP.

Consider the following scenarii:

1) Existing on-disk ESP.
User sets the partition "do not use" because they do not want to use it
but still want to keep it as an ESP -> keep the 'esp" flag.

2) Existing on-disk ESP.
User sets the partition "use as BIOS boot" -> set the 'bios_grub' flag
and remove the 'esp' flag but remember the partition was once an ESP.
User changes their mind and sets the partition "do not use" -> restore
the 'esp' flag and remove the 'bios_grub' flag.

3) Existing on-disk ESP.
User sets the partition "use as BIOS boot" -> set the 'bios_grub' flag
and remove the 'esp' flag but remember the partition was once an ESP.
User commits the changes to disk -> the partition is now irreversibly
committed to disk as "BIOS boot" so forget it was once an ESP.

4) New partition or existing non-ESP.
User sets the partition "use as ESP" -> set the 'esp' flag (and remove
the previous type flag).
User sets the partition "do not use" -> remove the 'esp' flag.

5) New partition or existing non-ESP.
User sets the partition "use as ESP" -> set the 'esp' flag (and remove
the previous type flag).
User sets the partition "use as BIOS boot" -> set the 'bios_grub' flag
and remove the 'ESP' flag.
User sets the partition "do no use" -> remove the 'bios_grub' flag (and
do not set the 'esp' flag).

[Debian Bug Tracking System]

Your message dated Fri, 17 Jan 2025 22:37:06 +0000
with message-id <E1tYuxe-002hgr-***@fasolo.debian.org>
and subject line Bug#1092892: fixed in partman-efi 108
has caused the Debian Bug report #1092892,
regarding partman-efi: Rework EFI partition management
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact ***@bugs.debian.org
immediately.)