Control: tags -1 -patch
Control: tags -1 pending
Post by Helmut GrohneControl: reassign -1 systemd-container,systemd-cryptsetup,systemd-
repart
Post by Helmut GrohneControl: found -1 systemd/256.1-1
Control: tags -1 + patch
Post by Helmut GrohnePackage: systemd-container,systemd-cryptsetup,cryptsetup-repart
Fixed bad package cryptsetup-repart.
Post by Helmut GrohneLet me not go into details of this problem just yet and just
install
Post by Helmut GrohnePost by Helmut Grohnethis bug as a temporary migration blocker. I shall have an update within
three working days, ideally with a patch. Thanks for your patience.
The recurring theme is that systemd moved all of its files from / to
/usr (expected via DEP17) and now moves components from the main systemd
package into systemd-container, systemd-cryptsetup and systemd-
repart.
Post by Helmut GrohneIn all of these cases, affected files may be lost in upgrades from
either bookworm or bookworm-backports to unstable and eventually trixie.
Users upgrading from trixie to sid, will likely not experience loss
unless they skip systemd versions.
There are multiple mitigation techniques available. Upgrading
Breaks+Replaces to Conflicts provides a relatively strong protection as
long as one uses an apt-based package management tool. However, the CTTE
advised that packages relevant to booting a system should also be safe
when installing packages directly with dpkg and in that scenario,
Conflicts are insufficient, because dpkg allows a conflicting package to
be unpacked before the conflicted package is removed to facilitate a
smooth handover. This is only exercised by apt when the relevant
packages employ a mutual conflict, which is not the case here. As such,
I also add temporary diversions that exist from preinst to postinst to
protect the relevant files from loss.
Thank you for the bug report, analysis and patch.
Of the three affected packages, -cryptsetup and -repart are brand new,
were never and will never be in bookworm, not even in backports, so
they are actually unaffected by the potential issue that affects the
Conflicts workaround.
-container does ship in bookworm, but the affected files, the sd-
sysupdate units, did not exist at all in bookworm, as the sub-feature
was only enabled later, and they only shipped in backports, not in
bookworm proper. Moreover, the feature itself is experimental, wasn't
really in a good shape in the backports version, and even in the newer
it cannot actually be used with any Debian infrastructure: we just do
not build and publish any of the image formats it supports. The only
reason it was enabled, was to allow local experiments. It is most
definitely not "boot critical" in any sense of the term. Finally, if it
_is_ actually used, then it would be in an image-based system, that by
definition does not perform package upgrades at all, but exclusively
installs read-only images using A/B schemes or similar, so any system
actually making use of these units would not be affected by such
upgrade issues in the first place, as it would be read-only. Any system
affected by this hypothetical cycle-induce file loss would experience
no issue, as the units would not be in use, by definition, and would
just come back at the next point release update.
Given the likelihood of any impact is minimal, and the magnitude of any
impact is nil, and given that the fix requires a large and expensive to
maintain patch, my conclusion is that the costs are not worth the
benefits, and I am ok with the minimal and localized risk that comes
with just relying on the much simpler Conflicts-based solution, and
will hence opt to use that instead.
Thanks again for the input and the discussion.
--
Kind regards,
Luca Boccassi