Bug#1051981: systemd-boot kernel postinst script calls ukify which requires python3

[Christopher Obbard]

Hi Michael,

On Fri, 2023-09-15 at 11:42 +0200, Michael Biebl wrote:
> Am 15.09.23 um 11:06 schrieb Christopher Obbard:
> > Package: src:systemd
> > Version: 254.1-3
> > Severity: important
> > X-Debbugs-Cc: chris.obbard at collabora.com
> > 
> > Dear Maintainer,
> > 
> > Installing a new kernel on a system which uses systemd-boot as the
> > bootloader fails if python3 is not installed. Here's the snippet from apt
> > upgrade:
> > 
> >      /etc/kernel/postinst.d/zz-systemd-boot:
> >      Installing kernel version 6.4.0-4-amd64 in systemd-boot...
> >      /usr/bin/env: ‘python3’: No such file or directory
> >      /usr/lib/kernel/install.d/60-ukify.install failed with exit status 127.
> > 
> > This renders the new kernel unusable as it never actually gets installed
> > in the right place for systemd-boot.
> > 
> > /etc/kernel/postinst.d/zz-systemd-boot calls kernel-install, which in turn
> > calls /usr/lib/kernel/install.d/60-ukify.install which calls /lib/systemd/ukify
> > to attempt to create a unified kernel image. These are both python3 scripts.
> > 
> > To workaround this, I have deleted /usr/lib/kernel/install.d/60-ukify.install
> > as we don't (yet!) create uki images with the ukify utility anyway. When
> > the ukify postinst script _does_ run, it currently just detects the
> > environment variable KERNEL_INSTALL_LAYOUT != "uki" (set from some config
> > files) and exits early, not even creating the uki. So this is opt-in.
> > 
> > /lib/systemd/ukify is shipped in the systemd package along with
> > /usr/lib/kernel/install.d/60-ukify.install, which I think is wrong as
> > systemd package does not have the right dependencies for this script.
> > 
> > 
> > Perhaps we should split the ukify bits into its own package (systemd-ukify)
> > which depends on python3 and should be manually installed? Also this package
> > can then depend on e.g. sbsigntool and other packages to actually manage
> > the signing (but that can be a separate bug!).
> > 
> 
> Having a separate package feels a bit like overkill for 68K
> 
> 52K	/lib/systemd/ukify
> 8,0K	/usr/lib/kernel/install.d/60-ukify.install
> 8,0K	/usr/share/man/man1/ukify.1.gz
> 
> 
> While systemd has a suggests python3, we certainly don't want a hard 
> python3 dependency though.

> A possible middle way could be to implement 
> /usr/lib/kernel/install.d/60-ukify.install in shell, the script seems 
> simple enough.

Thank you for your reply & suggestion. I don't think that overriding this script manually in the Debian package is a good idea
as I think that just diverges from upstream's scripts. Also, just because the script is small I don't think that should 
mean it should be shipped as part of systemd and not its own package. Maybe I am missing some reasoning here?

Since the ukify script is designed to build a unified kernel image and also sign the unified kernel image using e.g.
sbsign, I think it should go into its own package so it can depend on python3 and the required signing tools
and users can manually install it if they want to build ukis. By default users will probably not need to build ukis yet.
Also, Fedora and Arch seem to also package this script separately as systemd-ukify.

I can write a patch to do this, of course, I just would like some clarification on the way forward first.


Thanks!

Chris.