Control: tags -1 wontfix Control: close -1 On Sun, 16 Mar 2025 12:44:57 +0000 Simon McVittie <s...@debian.org> wrote: > Package: systemd-ukify > Version: 257.4-3 > Severity: wishlist > Tags: upstream > > systemd-ukify currently supports zstd decompression by using > python3-zstandard, which is a hard dependency; but python3-zstandard > seems to require source changes every time libzstd is upgraded as a > result of having been designed with a vendored libzstd in mind > (#1100475) which makes it more fragile than seems ideal, especially if > the long-term goal is for Debian's boot process to make more use of UKIs > in future. > > Looking at the source of systemd-ukify, it seems like it only makes a > very simple use of this module: import the module, and decompress one > compressed binary blob into an uncompressed byte array in RAM. This > could presumably be done equally well with any implementation of zstd. > > Perhaps it would be worthwhile to have a code path that implements zstd > decompression by using python3-pyzstd (which is somewhat higher- popcon > than python3-zstandard at the moment), or python3-zstd (although that > one is lower-popcon), or by invoking the zstd CLI tool (which is a > Recommends of initramfs-tools-core) via subprocess? That would make it > easier to swap between the implementations if one of them has > problematic properties.
Sadly that's not possible, as python3-pyzstd does not work with compressed kernels, it cannot extract them correctly as it doesn't support stream decompression. That's what it used before, but it never worked. If anybody can fix python3-pyzstd to work with kernel images it can be revisited, but it seems unlikely as upstream explicitly rejected it in the past: https://github.com/sergey-dryabzhinsky/python-zstd/issues/53 This is only a corner case anyway, kernel images should use zboot instead of shipping compressed files, as firmwares cannot handle that anyway. It's only an issue with some Ubuntu architectures other than x86_64.
