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

Mikko Rapeli
2025-04-16T06:09:01Z

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?

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
>