Control: tags -1 -patch Control: tags -1 pending On Fri, 21 Jun 2024 12:30:25 +0200 Helmut Grohne <hel...@subdivi.de> wrote: > Control: reassign -1 systemd-container,systemd-cryptsetup,systemd- repart > Control: found -1 systemd/256.1-1 > Control: tags -1 + patch > > On Thu, Jun 20, 2024 at 10:58:23AM +0200, Helmut Grohne wrote: > > Package: systemd-container,systemd-cryptsetup,cryptsetup-repart > > Fixed bad package cryptsetup-repart. > > > Let me not go into details of this problem just yet and just install > > this 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. > In 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
signature.asc
Description: This is a digitally signed message part
