RE: [OE-core] [PATCH v3 01/11] systemd: enable efi support by default

Peter Kjellerstedt
2025-04-16T12:55:04Z

> -----Original Message-----
> From: Mikko Rapeli <mikko.rapeli@linaro.org>
> Sent: den 16 april 2025 08:09
> To: Peter Kjellerstedt <peter.kjellerstedt@axis.com>
> Cc: Adrian Freihofer <adrian.freihofer@gmail.com>; openembedded-core@lists.openembedded.org; mike.looijmans@topic.nl
> Subject: Re: [OE-core] [PATCH v3 01/11] systemd: enable efi support by default
>
> Hi,
>
> On Tue, Apr 15, 2025 at 04:20:50PM +0000, Peter Kjellerstedt wrote:
> > > -----Original Message-----
> > > From: openembedded-core@lists.openembedded.org <openembedded-core@lists.openembedded.org> On Behalf Of Mikko Rapeli via lists.openembedded.org
> > > Sent: den 15 april 2025 11:52
> > > To: Adrian Freihofer <adrian.freihofer@gmail.com>
> > > Cc: openembedded-core@lists.openembedded.org; mike.looijmans@topic.nl
> > > Subject: Re: [OE-core] [PATCH v3 01/11] systemd: enable efi support by default
> > >
> > > Hi,
> > >
> > > On Mon, Apr 14, 2025 at 06:28:13PM +0200, Adrian Freihofer wrote:
> > > > Hi Mikko
> > > >
> > > > Would it be possible to provide some numbers on the impact on the size of
> > > > the binaries and the additional dependencies that could be added to the
> > > > image with or without efi enabled?
> > > > I think the patch would be a very good compromise if the impact is
> > > > negligible, but otherwise the question is probably still valid.
> >
> > I have probably missed something in this very long thread, but what is the
> > reason to force EFI support on us rather than relying on the efi distro
> > feature? We do not use EFI in any of our products and thus do not have it
> > set in DISTRO_FEATURES. If it is suddenly expected that EFI support should
> > be enabled all over the place it just means I will have to go hunting for
> > it to turn it off rather than just relying on the existing distro feature.
>
> Is it ok for Richard to enable "efi" in poky/poky-altcfg DISTRO_FEATURES
> by default?

To me, that sounds like a good idea, given that poky-altcfg is the distro
that has systemd enabled.

>
> It is already enabled in MACHINE_FEATURES for oe-core machines I care
> about.
>
> > >
> > > The impact is small:
> > >
> > > * python3-pyelftools-native is added to build dependencies
> > >
> > > * At runtime the efivars partition is now automatically mounted read-only by
> > > systemd to /sys/firmware/efi/efivars and can be used to query various firmware
> > > and EFI bootloader (grub, systemd-boot) details
> > >
> > > * Since "efi" is now default, other layers can stop enabling it:
> > >
> > > https://git.yoctoproject.org/meta-arm/tree/meta-arm/recipes-core/systemd/systemd-efi.inc
> > > https://git.yoctoproject.org/meta-security/tree/meta-tpm/recipes-core/systemd/systemd_%25.bbappend#n5
> > > https://github.com/Wind-River/meta-secure-core/blob/master/meta-efi-secure-boot/recipes-core/systemd/systemd-efi-secure-boot.inc
> >
> > But isn't the problem here rather that these layers want to force EFI
> > support instead of using, e.g., REQUIRED_DISTRO_FEATURES = "efi"?
>
> These layers want to enable EFI support but don't want to change the
> poky/poky-altcfg distro settings.
>
> In machine features "efi" is already enabled but it was rejeted here to
> use MACHINE_FEATURES in systemd.
>
> So full loop in the discussion...?
>
> Enabling systemd "efi" support by default is a tiny thing which would get
> lost all the other changes and IMO would not impact anyone significantly
> at runtime or at build time. Those who optimize systemd for e.g. non-EFI
> systems should be setting PACKAGECONFIG fully to their liking.
>
> Cheers,
>
> -Mikko
>
> > >
> > > * /usr/lib/systemd/libsystemd-shared-257.so size increases 32 bytes from
> > > 4012152 to 4012184 bytes, 0.0008%
> > >
> > > * systemd package size increase from 9857529 to 10226508, 3.7%, with
> > > added files:
> > >
> > > +drwxr-xr-x root root 4096 ./usr/lib/systemd/boot
> > > +drwxr-xr-x root root 4096 ./usr/lib/systemd/boot/efi
> > > +-rw-r--r-- root root 6144 ./usr/lib/systemd/boot/efi/addonaa64.efi.stub
> > > +-rw-r--r-- root root 101376 ./usr/lib/systemd/boot/efi/linuxaa64.efi.stub
> > > +-rw-r--r-- root root 120832 ./usr/lib/systemd/boot/efi/systemd-bootaa64.efi
> > > +-rwxr-xr-x - - 67656 ./usr/lib/systemd/systemd-bless-boot
> > > +-rwxr-xr-x - - 67456 ./usr/lib/systemd/system-generators/systemd-bless-boot-generator
> > > +lrwxrwxrwx - - 25 ./usr/lib/systemd/system/sockets.target.wants/systemd-bootctl.socket -> ../systemd-bootctl.socket
> > > +lrwxrwxrwx - - 35 ./usr/lib/systemd/system/sysinit.target.wants/systemd-boot-random-seed.service -> ../systemd-boot-random-seed.service
> > > +lrwxrwxrwx - - 34 ./usr/lib/systemd/system/sysinit.target.wants/systemd-hibernate-clear.service -> ../systemd-hibernate-clear.service
> > > +-rw-r--r-- - - 690 ./usr/lib/systemd/system/systemd-bless-boot.service
> > > +-rw-r--r-- - - 532 ./usr/lib/systemd/system/systemd-bootctl@.service
> > > +-rw-r--r-- - - 596 ./usr/lib/systemd/system/systemd-bootctl.socket
> > > +-rw-r--r-- - - 1029 ./usr/lib/systemd/system/systemd-boot-random-seed.service
> > > +-rw-r--r-- - - 733 ./usr/lib/systemd/system/systemd-boot-update.service
> > > +-rw-r--r-- - - 782 ./usr/lib/systemd/system/systemd-hibernate-clear.service
> > > +-rw-r--r-- - - 779 ./usr/lib/tmpfiles.d/20-systemd-stub.conf
> > >
> > > This shows a bug in the config between systemd and systemd-boot, the EFI binaries are
> > > provided by both. Sadly systemd-boot doesn't work so well and doesn't install all
> > > the services etc which systemd does with "efi" and bootloader enabled. Not sure
> > > if the overlap should be fixed or ignored. Using meson to install systemd-boot
> > > binaries does fix deployment of the EFI binaries but does not install the
> > > random-seed etc services. With this workaround to avoid the EFI file duplication
> > > in systemd recipe:
> > >
> > > --- a/meta/recipes-core/systemd/systemd_257.5.bb
> > > +++ b/meta/recipes-core/systemd/systemd_257.5.bb
> > > @@ -149,7 +149,7 @@ PACKAGECONFIG[default-compression-lz4] = "-Dlz4=true -Ddefault-compression=lz4,,
> > > PACKAGECONFIG[default-compression-xz] = "-Dxz=true -Ddefault-compression=xz,,xz"
> > > PACKAGECONFIG[default-compression-zstd] = "-Dzstd=true -Ddefault-compression=zstd,,zstd"
> > > PACKAGECONFIG[dbus] = "-Ddbus=enabled,-Ddbus=disabled,dbus"
> > > -PACKAGECONFIG[efi] = "-Defi=true -Dbootloader=enabled,-Defi=false -Dbootloader=disabled,python3-pyelftools-native"
> > > +PACKAGECONFIG[efi] = "-Defi=true -Dbootloader=disabled,-Defi=false -Dbootloader=disabled,python3-pyelftools-native systemd-boot"
> > >
> > > size without "efi" is 9857529 bytes and with "efi" 9859196, or size increase
> > > of 0.016% which is tiny. To stay closer to systemd upstream, I don't think
> > > removing the duplication is worth the effort for now. systemd-boot
> > > recipe could maybe be replaced by systemd recipe and a systemd-boot binary
> > > package. Otherwise the configurations don't match. FWIW, it tried following
> > > changes to systemd-boot:
> > >
> > > --- a/meta/recipes-core/systemd/systemd-boot_257.5.bb
> > > +++ b/meta/recipes-core/systemd/systemd-boot_257.5.bb
> > > @@ -24,6 +24,7 @@ EOF
> > > MESON_CROSS_FILE:append = " --cross-file ${WORKDIR}/meson-${PN}.cross"
> > >
> > > MESON_TARGET = "systemd-boot"
> > > +MESON_INSTALL_TAGS = "systemd-boot"
> > >
> > > EXTRA_OEMESON += "-Defi=true \
> > > -Dbootloader=true \
> > > @@ -43,7 +44,7 @@ python __anonymous () {
> > > d.setVar("SYSTEMD_BOOT_IMAGE_PREFIX", prefix)
> > > }
> > >
> > > -FILES:${PN} = "${EFI_FILES_PATH}/${SYSTEMD_BOOT_IMAGE}"
> > > +FILES:${PN} = "${EFI_FILES_PATH}/${SYSTEMD_BOOT_IMAGE} ${libdir}"
> > >
> > > RDEPENDS:${PN} += "virtual-systemd-bootconf"
> > >
> > > @@ -53,6 +54,7 @@ COMPATIBLE_HOST = "(aarch64.*|arm.*|x86_64.*|i.86.*|riscv.*)-linux"
> > > COMPATIBLE_HOST:x86-x32 = "null"
> > >
> > > do_install() {
> > > + meson_do_install
> > > install -d ${D}${EFI_FILES_PATH}
> > > install ${B}/src/boot/systemd-boot*.efi ${D}${EFI_FILES_PATH}/${SYSTEMD_BOOT_IMAGE}
> > > }
> > >
> > > Cheers,
> > >
> > > -Mikko
> >
> > //Peter

//Peter