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:
<https://salsa.debian.org/installer-team/partman-base/-/merge_requests/13>
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:
<https://salsa.debian.org/pham/partman-partitioning/-/commits/set_flag>
