[v3,01/11] systemd: enable efi support by default

For example genericarm64 enables "efi" in MACHINE_FEATURES
and in u-boot. Boot without "efi" in systemd works with
EFI protocols but for example efivars is not mounted at
all so various checks fail in userspace. Fix these by
enabling "efi" support by default to avoid making
it machine specific. Fixes efivars mount to
/sys/firmware/efi/efivars etc.

Signed-off-by: Mikko Rapeli <mikko.rapeli@linaro.org>
---
 meta/recipes-core/systemd/systemd_257.4.bb | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

Hi Mikko

On Fri, 2025-04-04 at 19:29 +0300, Mikko Rapeli via
lists.openembedded.org wrote:
> For example genericarm64 enables "efi" in MACHINE_FEATURES
> and in u-boot. Boot without "efi" in systemd works with
> EFI protocols but for example efivars is not mounted at
> all so various checks fail in userspace. Fix these by
> enabling "efi" support by default to avoid making
> it machine specific. Fixes efivars mount to
> /sys/firmware/efi/efivars etc.

My point is that many OE/Yocto-based embedded products rely on a fully
redundant and power fail-safe firmware update and boot implementation.
So far I have not understood how this could be implemented in a
similarly robust way based on EFI as we have now without EFI-based
boot-up. I would therefore like to see the EFI implementation remain
opt-in until it covers at least the most important use cases for robust
embedded systems. What I primarily miss with EFI is a reference
implementation for an A/B update system without having to rely on a FAT
partition without journaling. Please correct me if I'm missing
something!

Would it make sense to declare poky as an EFI ready reference
distribution by enabling the efi DISTRO_FEATURE there, rather than
starting with making recipes enabling efi unconditionally?

Could something like this in poky.conf work?
DISTRO_FEATURES:append:aarch64 = " efi"
DISTRO_FEATURES:append:riscv64 = " efi"
DISTRO_FEATURES:append:x86-64 = " efi"

Thank you and regards,
Adrian

> 
> Signed-off-by: Mikko Rapeli <mikko.rapeli@linaro.org>
> ---
>  meta/recipes-core/systemd/systemd_257.4.bb | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git a/meta/recipes-core/systemd/systemd_257.4.bb
> b/meta/recipes-core/systemd/systemd_257.4.bb
> index 64fb8fe69a..06e5621398 100644
> --- a/meta/recipes-core/systemd/systemd_257.4.bb
> +++ b/meta/recipes-core/systemd/systemd_257.4.bb
> @@ -68,13 +68,14 @@ PAM_PLUGINS = " \
>  "
>  
>  PACKAGECONFIG ??= " \
> -    ${@bb.utils.filter('DISTRO_FEATURES', 'acl audit apparmor efi
> ldconfig pam pni-names selinux smack polkit seccomp', d)} \
> +    ${@bb.utils.filter('DISTRO_FEATURES', 'acl audit apparmor
> ldconfig pam pni-names selinux smack polkit seccomp', d)} \
>      ${@bb.utils.contains('DISTRO_FEATURES', 'minidebuginfo',
> 'coredump elfutils', '', d)} \
>      ${@bb.utils.contains('DISTRO_FEATURES', 'wifi', 'rfkill', '',
> d)} \
>      ${@bb.utils.contains('DISTRO_FEATURES', 'x11', 'xkbcommon', '',
> d)} \
>      ${@bb.utils.contains('DISTRO_FEATURES', 'sysvinit', 'sysvinit',
> 'link-udev-shared', d)} \
>      backlight \
>      binfmt \
> +    efi \
>      gshadow \
>      hibernate \
>      hostnamed \
> 
> -=-=-=-=-=-=-=-=-=-=-=-
> Links: You receive all messages sent to this group.
> View/Reply Online (#214352):
> https://lists.openembedded.org/g/openembedded-core/message/214352
> Mute This Topic: https://lists.openembedded.org/mt/112087523/4454582
> Group Owner: openembedded-core+owner@lists.openembedded.org
> Unsubscribe:
> https://lists.openembedded.org/g/openembedded-core/unsub [
> adrian.freihofer@gmail.com]
> -=-=-=-=-=-=-=-=-=-=-=-
>

Hi,

On Thu, Apr 10, 2025 at 12:16:18PM +0200, Adrian Freihofer wrote:
> Hi Mikko
> 
> On Fri, 2025-04-04 at 19:29 +0300, Mikko Rapeli via
> lists.openembedded.org wrote:
> > For example genericarm64 enables "efi" in MACHINE_FEATURES
> > and in u-boot. Boot without "efi" in systemd works with
> > EFI protocols but for example efivars is not mounted at
> > all so various checks fail in userspace. Fix these by
> > enabling "efi" support by default to avoid making
> > it machine specific. Fixes efivars mount to
> > /sys/firmware/efi/efivars etc.
> 
> My point is that many OE/Yocto-based embedded products rely on a fully
> redundant and power fail-safe firmware update and boot implementation.
> So far I have not understood how this could be implemented in a
> similarly robust way based on EFI as we have now without EFI-based
> boot-up. I would therefore like to see the EFI implementation remain
> opt-in until it covers at least the most important use cases for robust
> embedded systems. What I primarily miss with EFI is a reference
> implementation for an A/B update system without having to rely on a FAT
> partition without journaling. Please correct me if I'm missing
> something!

AFAIK, UEFI firmware update solution is so called "capsule updates".
How UEFI implementations handle this and if they are fail-safe is
up to implementations like u-boot and edk2. AFAIK, the standards
don't say which file system must be used and thus an ext4 could
work too for ESP partition. And note that fail-safe may also depend on HW
features; a block devices may report that write completed but
keep things on internal volatile buffers due to "performance".

This change really has nothing to do with firmware updates and only
enables systemd to mount an ESP partition, read EFI variables etc
by default without binding systemd to MACHINE_FEATURES.

All x86_64 and aarch64 distros do this already. Tiny distros can
disable this and/or avoid using systemd completely.

This really is a very minor detail of default systemd
configuration. Systems without EFI firmware don't break.

> Would it make sense to declare poky as an EFI ready reference
> distribution by enabling the efi DISTRO_FEATURE there, rather than
> starting with making recipes enabling efi unconditionally?

This could be possible, but then a decision would need to be taken
if UEFI support is enabled in poky and/or poky-altcfg distros
and how would non-efi be tested.

> Could something like this in poky.conf work?
> DISTRO_FEATURES:append:aarch64 = " efi"
> DISTRO_FEATURES:append:riscv64 = " efi"
> DISTRO_FEATURES:append:x86-64 = " efi"

Possibly. Why not all architectures?

Do you have examples where e.g. build fails due to
this change?

This change does not add new build dependencies. It
just enables UEFI support in systemd to detect
compatible firmware at runtime and do some basic
things with it.

Cheers,

-Mikko

Hi Adrian

On Thu, 10 Apr 2025 at 14:21, Adrian Freihofer <mikko.rapeli@linaro.org> wrote:
>
> Hi Mikko
>
> On Fri, 2025-04-04 at 19:29 +0300, Mikko Rapeli via
> lists.openembedded.org wrote:
> > For example genericarm64 enables "efi" in MACHINE_FEATURES
> > and in u-boot. Boot without "efi" in systemd works with
> > EFI protocols but for example efivars is not mounted at
> > all so various checks fail in userspace. Fix these by
> > enabling "efi" support by default to avoid making
> > it machine specific. Fixes efivars mount to
> > /sys/firmware/efi/efivars etc.
>
> My point is that many OE/Yocto-based embedded products rely on a fully
> redundant and power fail-safe firmware update and boot implementation.
> So far I have not understood how this could be implemented in a
> similarly robust way based on EFI as we have now without EFI-based
> boot-up.

As far as the firmware updates are concerned there's [0], which is
also implemented in U-Boot.
But even in that case, I am not sure I understand your concerns. What
prevents you from having the existing mechanisms for firmware updates
on a system that boots with EFI?

>  I would therefore like to see the EFI implementation remain
> opt-in until it covers at least the most important use cases for robust
> embedded systems. What I primarily miss with EFI is a reference
> implementation for an A/B update system without having to rely on a FAT
> partition without journaling. Please correct me if I'm missing
> something!

Where does the FAT partition requirement come from?

>
> Would it make sense to declare poky as an EFI ready reference
> distribution by enabling the efi DISTRO_FEATURE there, rather than
> starting with making recipes enabling efi unconditionally?
>
> Could something like this in poky.conf work?
> DISTRO_FEATURES:append:aarch64 = " efi"
> DISTRO_FEATURES:append:riscv64 = " efi"
> DISTRO_FEATURES:append:x86-64 = " efi"

[0] https://github.com/ARM-software/edge-iot-arch-guide/blob/main/source/FWU/MBFW/chapter1-introduction.md

Thanks
/Ilias
>
> Thank you and regards,
> Adrian
>
> >
> > Signed-off-by: Mikko Rapeli <mikko.rapeli@linaro.org>
> > ---
> >  meta/recipes-core/systemd/systemd_257.4.bb | 3 ++-
> >  1 file changed, 2 insertions(+), 1 deletion(-)
> >
> > diff --git a/meta/recipes-core/systemd/systemd_257.4.bb
> > b/meta/recipes-core/systemd/systemd_257.4.bb
> > index 64fb8fe69a..06e5621398 100644
> > --- a/meta/recipes-core/systemd/systemd_257.4.bb
> > +++ b/meta/recipes-core/systemd/systemd_257.4.bb
> > @@ -68,13 +68,14 @@ PAM_PLUGINS = " \
> >  "
> >
> >  PACKAGECONFIG ??= " \
> > -    ${@bb.utils.filter('DISTRO_FEATURES', 'acl audit apparmor efi
> > ldconfig pam pni-names selinux smack polkit seccomp', d)} \
> > +    ${@bb.utils.filter('DISTRO_FEATURES', 'acl audit apparmor
> > ldconfig pam pni-names selinux smack polkit seccomp', d)} \
> >      ${@bb.utils.contains('DISTRO_FEATURES', 'minidebuginfo',
> > 'coredump elfutils', '', d)} \
> >      ${@bb.utils.contains('DISTRO_FEATURES', 'wifi', 'rfkill', '',
> > d)} \
> >      ${@bb.utils.contains('DISTRO_FEATURES', 'x11', 'xkbcommon', '',
> > d)} \
> >      ${@bb.utils.contains('DISTRO_FEATURES', 'sysvinit', 'sysvinit',
> > 'link-udev-shared', d)} \
> >      backlight \
> >      binfmt \
> > +    efi \
> >      gshadow \
> >      hibernate \
> >      hostnamed \
> >
> > 
> >
>

Apologies for the noise, I forgot to add Adrian in CC

On Thu, 10 Apr 2025 at 14:45, Ilias Apalodimas
<ilias.apalodimas@linaro.org> wrote:
>
> Hi Adrian
>
> On Thu, 10 Apr 2025 at 14:21, Adrian Freihofer <mikko.rapeli@linaro.org> wrote:
> >
> > Hi Mikko
> >
> > On Fri, 2025-04-04 at 19:29 +0300, Mikko Rapeli via
> > lists.openembedded.org wrote:
> > > For example genericarm64 enables "efi" in MACHINE_FEATURES
> > > and in u-boot. Boot without "efi" in systemd works with
> > > EFI protocols but for example efivars is not mounted at
> > > all so various checks fail in userspace. Fix these by
> > > enabling "efi" support by default to avoid making
> > > it machine specific. Fixes efivars mount to
> > > /sys/firmware/efi/efivars etc.
> >
> > My point is that many OE/Yocto-based embedded products rely on a fully
> > redundant and power fail-safe firmware update and boot implementation.
> > So far I have not understood how this could be implemented in a
> > similarly robust way based on EFI as we have now without EFI-based
> > boot-up.
>
> As far as the firmware updates are concerned there's [0], which is
> also implemented in U-Boot.
> But even in that case, I am not sure I understand your concerns. What
> prevents you from having the existing mechanisms for firmware updates
> on a system that boots with EFI?
>
> >  I would therefore like to see the EFI implementation remain
> > opt-in until it covers at least the most important use cases for robust
> > embedded systems. What I primarily miss with EFI is a reference
> > implementation for an A/B update system without having to rely on a FAT
> > partition without journaling. Please correct me if I'm missing
> > something!
>
> Where does the FAT partition requirement come from?
>
> >
> > Would it make sense to declare poky as an EFI ready reference
> > distribution by enabling the efi DISTRO_FEATURE there, rather than
> > starting with making recipes enabling efi unconditionally?
> >
> > Could something like this in poky.conf work?
> > DISTRO_FEATURES:append:aarch64 = " efi"
> > DISTRO_FEATURES:append:riscv64 = " efi"
> > DISTRO_FEATURES:append:x86-64 = " efi"
>
> [0] https://github.com/ARM-software/edge-iot-arch-guide/blob/main/source/FWU/MBFW/chapter1-introduction.md
>
> Thanks
> /Ilias
> >
> > Thank you and regards,
> > Adrian
> >
> > >
> > > Signed-off-by: Mikko Rapeli <mikko.rapeli@linaro.org>
> > > ---
> > >  meta/recipes-core/systemd/systemd_257.4.bb | 3 ++-
> > >  1 file changed, 2 insertions(+), 1 deletion(-)
> > >
> > > diff --git a/meta/recipes-core/systemd/systemd_257.4.bb
> > > b/meta/recipes-core/systemd/systemd_257.4.bb
> > > index 64fb8fe69a..06e5621398 100644
> > > --- a/meta/recipes-core/systemd/systemd_257.4.bb
> > > +++ b/meta/recipes-core/systemd/systemd_257.4.bb
> > > @@ -68,13 +68,14 @@ PAM_PLUGINS = " \
> > >  "
> > >
> > >  PACKAGECONFIG ??= " \
> > > -    ${@bb.utils.filter('DISTRO_FEATURES', 'acl audit apparmor efi
> > > ldconfig pam pni-names selinux smack polkit seccomp', d)} \
> > > +    ${@bb.utils.filter('DISTRO_FEATURES', 'acl audit apparmor
> > > ldconfig pam pni-names selinux smack polkit seccomp', d)} \
> > >      ${@bb.utils.contains('DISTRO_FEATURES', 'minidebuginfo',
> > > 'coredump elfutils', '', d)} \
> > >      ${@bb.utils.contains('DISTRO_FEATURES', 'wifi', 'rfkill', '',
> > > d)} \
> > >      ${@bb.utils.contains('DISTRO_FEATURES', 'x11', 'xkbcommon', '',
> > > d)} \
> > >      ${@bb.utils.contains('DISTRO_FEATURES', 'sysvinit', 'sysvinit',
> > > 'link-udev-shared', d)} \
> > >      backlight \
> > >      binfmt \
> > > +    efi \
> > >      gshadow \
> > >      hibernate \
> > >      hostnamed \
> > >
> > > 
> > >
> >

On Thu, 10 Apr 2025 at 13:50, Ilias Apalodimas via
lists.openembedded.org
<ilias.apalodimas=linaro.org@lists.openembedded.org> wrote:
> >  I would therefore like to see the EFI implementation remain
> > opt-in until it covers at least the most important use cases for robust
> > embedded systems. What I primarily miss with EFI is a reference
> > implementation for an A/B update system without having to rely on a FAT
> > partition without journaling. Please correct me if I'm missing
> > something!
>
> Where does the FAT partition requirement come from?

https://uefi.org/sites/default/files/resources/UEFI%202_5.pdf#page=585

This is what one has to use to store that critical bit of info ('A' or
'B'?) and the bootloader code that picks one or the other, reads the
kernel from it, and hands over the boot process. I'd say these are
extremely critical things, and yet FAT design as hopefully everyone's
aware is a 1980s MS DOS relic that is notorious for lack of metadata
robustness and its frequent corruption.

Alex

Hi Alexander

On Thu, 10 Apr 2025 at 15:13, Alexander Kanavin <alex.kanavin@gmail.com> wrote:
>
> On Thu, 10 Apr 2025 at 13:50, Ilias Apalodimas via
> lists.openembedded.org
> <ilias.apalodimas=linaro.org@lists.openembedded.org> wrote:
> > >  I would therefore like to see the EFI implementation remain
> > > opt-in until it covers at least the most important use cases for robust
> > > embedded systems. What I primarily miss with EFI is a reference
> > > implementation for an A/B update system without having to rely on a FAT
> > > partition without journaling. Please correct me if I'm missing
> > > something!
> >
> > Where does the FAT partition requirement come from?
>
> https://uefi.org/sites/default/files/resources/UEFI%202_5.pdf#page=585
>
> This is what one has to use to store that critical bit of info ('A' or
> 'B'?) and the bootloader code that picks one or the other, reads the
> kernel from it, and hands over the boot process. I'd say these are
> extremely critical things, and yet FAT design as hopefully everyone's
> aware is a 1980s MS DOS relic that is notorious for lack of metadata
> robustness and its frequent corruption.

I think you are misinterpreting that. That paragraph says "The file
system supported by the Extensible Firmware Interface is based on FAT"
 -- IOW your *firmware* must support FAT.
It never dictates that the ESP has to be FAT as well. You are free to
format your ESP to whatever FS your board supports. For example, x86
macs use HFS IIRC.

Thanks
/Ilias
>
> Alex

On Thu, 10 Apr 2025 at 14:55, Ilias Apalodimas
<ilias.apalodimas@linaro.org> wrote:
> I think you are misinterpreting that. That paragraph says "The file
> system supported by the Extensible Firmware Interface is based on FAT"
>  -- IOW your *firmware* must support FAT.
> It never dictates that the ESP has to be FAT as well. You are free to
> format your ESP to whatever FS your board supports. For example, x86
> macs use HFS IIRC.

But are there any actual UEFI boards that support anything other than
FAT? Or is everyone taking the path of least resistance and cheapest
R&D costs, implementing only what the spec requires?

Alex

On Thu, 10 Apr 2025 at 17:20, Alexander Kanavin <alex.kanavin@gmail.com> wrote:
>
> On Thu, 10 Apr 2025 at 14:55, Ilias Apalodimas
> <ilias.apalodimas@linaro.org> wrote:
> > I think you are misinterpreting that. That paragraph says "The file
> > system supported by the Extensible Firmware Interface is based on FAT"
> >  -- IOW your *firmware* must support FAT.
> > It never dictates that the ESP has to be FAT as well. You are free to
> > format your ESP to whatever FS your board supports. For example, x86
> > macs use HFS IIRC.
>
> But are there any actual UEFI boards that support anything other than
> FAT? Or is everyone taking the path of least resistance and cheapest
> R&D costs, implementing only what the spec requires?

I am going to assume that by 'boards' we mostly target embedded ones right?
The majority of those work with U-Boot which has a pretty capable EFI
implementation nowadays and supports a variety of filesystems.

P.S: I am pretty sure that EDK2 and servers support more filesystems
than just FAT, but I can double check.

Regards
/Ilias

>
> Alex

On Thu, 10 Apr 2025 at 16:39, Ilias Apalodimas
<ilias.apalodimas@linaro.org> wrote:
> I am going to assume that by 'boards' we mostly target embedded ones right?
> The majority of those work with U-Boot which has a pretty capable EFI
> implementation nowadays and supports a variety of filesystems.
>
> P.S: I am pretty sure that EDK2 and servers support more filesystems
> than just FAT, but I can double check.

We're talking about UEFI firmware, right? The thing that reads the
bootloader from ESP/ on storage and runs it. Is u-boot or ovmf used to
implement that? It's that firmware that I have scepticism about, not
the bootloaders.

Alex

On Thu, 10 Apr 2025 at 17:52, Alexander Kanavin <alex.kanavin@gmail.com> wrote:
>
> On Thu, 10 Apr 2025 at 16:39, Ilias Apalodimas
> <ilias.apalodimas@linaro.org> wrote:
> > I am going to assume that by 'boards' we mostly target embedded ones right?
> > The majority of those work with U-Boot which has a pretty capable EFI
> > implementation nowadays and supports a variety of filesystems.
> >
> > P.S: I am pretty sure that EDK2 and servers support more filesystems
> > than just FAT, but I can double check.
>
> We're talking about UEFI firmware, right? The thing that reads the
> bootloader from ESP/ on storage and runs it.

UEFI is a spec. There are various implementations of the spec. EDKII
is one, U-Boot is another one.

>  Is u-boot or ovmf used to implement that? It's that firmware that I have scepticism about, not
> the bootloaders.

We are conflating things here. OVMF is an EFI implementation for
virtual machines coming from EDKII. U-Boot also implements EFI, you
can boot a kernel directly, or grub or any EFI application you want
with any of these.

/Ilias
>
> Alex

Hi,

First, Sorry for the email address mixup with Adrian, mutt
bounce did unexpected things.

On Thu, Apr 10, 2025 at 04:51:51PM +0200, Alexander Kanavin wrote:
> On Thu, 10 Apr 2025 at 16:39, Ilias Apalodimas
> <ilias.apalodimas@linaro.org> wrote:
> > I am going to assume that by 'boards' we mostly target embedded ones right?
> > The majority of those work with U-Boot which has a pretty capable EFI
> > implementation nowadays and supports a variety of filesystems.
> >
> > P.S: I am pretty sure that EDK2 and servers support more filesystems
> > than just FAT, but I can double check.
> 
> We're talking about UEFI firmware, right? The thing that reads the
> bootloader from ESP/ on storage and runs it. Is u-boot or ovmf used to
> implement that? It's that firmware that I have scepticism about, not
> the bootloaders.

There are multiple levels of bootloaders. From HW to first ones in
CPU SW/firmware, multiple levels inside and implementing UEFI and then
ones using UEFI interfaces to load operating systems.

We're talking about the ones which implement UEFI and edk2 and u-boot are the
most popular ones. ovmf is based on edk2, as are many SoC vendor firmware
implementations. Default qemu builds of u-boot also implement UEFI which we use
in oe-core to boot wic images with an ESP partition which then hosts
grub or systemd-boot OS loaders, config files, kernel, initramfs and/or
UKI binaries.

Hope this helps,

-Mikko

But none of the last few messages answer my question. Can I restate it?

Is there a physical board that can boot from ESP formatted to something
else than FAT?

Alex

On Thu 10. Apr 2025 at 18.51, Ilias Apalodimas via lists.openembedded.org
<ilias.apalodimas=linaro.org@lists.openembedded.org> wrote:

> Apologies for the noise, I forgot to add Adrian in CC
>
> On Thu, 10 Apr 2025 at 14:45, Ilias Apalodimas
> <ilias.apalodimas@linaro.org> wrote:
> >
> > Hi Adrian
> >
> > On Thu, 10 Apr 2025 at 14:21, Adrian Freihofer <mikko.rapeli@linaro.org>
> wrote:
> > >
> > > Hi Mikko
> > >
> > > On Fri, 2025-04-04 at 19:29 +0300, Mikko Rapeli via
> > > lists.openembedded.org wrote:
> > > > For example genericarm64 enables "efi" in MACHINE_FEATURES
> > > > and in u-boot. Boot without "efi" in systemd works with
> > > > EFI protocols but for example efivars is not mounted at
> > > > all so various checks fail in userspace. Fix these by
> > > > enabling "efi" support by default to avoid making
> > > > it machine specific. Fixes efivars mount to
> > > > /sys/firmware/efi/efivars etc.
> > >
> > > My point is that many OE/Yocto-based embedded products rely on a fully
> > > redundant and power fail-safe firmware update and boot implementation.
> > > So far I have not understood how this could be implemented in a
> > > similarly robust way based on EFI as we have now without EFI-based
> > > boot-up.
> >
> > As far as the firmware updates are concerned there's [0], which is
> > also implemented in U-Boot.
> > But even in that case, I am not sure I understand your concerns. What
> > prevents you from having the existing mechanisms for firmware updates
> > on a system that boots with EFI?
> >
> > >  I would therefore like to see the EFI implementation remain
> > > opt-in until it covers at least the most important use cases for robust
> > > embedded systems. What I primarily miss with EFI is a reference
> > > implementation for an A/B update system without having to rely on a FAT
> > > partition without journaling. Please correct me if I'm missing
> > > something!
> >
> > Where does the FAT partition requirement come from?
> >
> > >
> > > Would it make sense to declare poky as an EFI ready reference
> > > distribution by enabling the efi DISTRO_FEATURE there, rather than
> > > starting with making recipes enabling efi unconditionally?
> > >
> > > Could something like this in poky.conf work?
> > > DISTRO_FEATURES:append:aarch64 = " efi"
> > > DISTRO_FEATURES:append:riscv64 = " efi"
> > > DISTRO_FEATURES:append:x86-64 = " efi"
> >
> > [0]
> https://github.com/ARM-software/edge-iot-arch-guide/blob/main/source/FWU/MBFW/chapter1-introduction.md
> >
> > Thanks
> > /Ilias
> > >
> > > Thank you and regards,
> > > Adrian
> > >
> > > >
> > > > Signed-off-by: Mikko Rapeli <mikko.rapeli@linaro.org>
> > > > ---
> > > >  meta/recipes-core/systemd/systemd_257.4.bb | 3 ++-
> > > >  1 file changed, 2 insertions(+), 1 deletion(-)
> > > >
> > > > diff --git a/meta/recipes-core/systemd/systemd_257.4.bb
> > > > b/meta/recipes-core/systemd/systemd_257.4.bb
> > > > index 64fb8fe69a..06e5621398 100644
> > > > --- a/meta/recipes-core/systemd/systemd_257.4.bb
> > > > +++ b/meta/recipes-core/systemd/systemd_257.4.bb
> > > > @@ -68,13 +68,14 @@ PAM_PLUGINS = " \
> > > >  "
> > > >
> > > >  PACKAGECONFIG ??= " \
> > > > -    ${@bb.utils.filter('DISTRO_FEATURES', 'acl audit apparmor efi
> > > > ldconfig pam pni-names selinux smack polkit seccomp', d)} \
> > > > +    ${@bb.utils.filter('DISTRO_FEATURES', 'acl audit apparmor
> > > > ldconfig pam pni-names selinux smack polkit seccomp', d)} \
> > > >      ${@bb.utils.contains('DISTRO_FEATURES', 'minidebuginfo',
> > > > 'coredump elfutils', '', d)} \
> > > >      ${@bb.utils.contains('DISTRO_FEATURES', 'wifi', 'rfkill', '',
> > > > d)} \
> > > >      ${@bb.utils.contains('DISTRO_FEATURES', 'x11', 'xkbcommon', '',
> > > > d)} \
> > > >      ${@bb.utils.contains('DISTRO_FEATURES', 'sysvinit', 'sysvinit',
> > > > 'link-udev-shared', d)} \
> > > >      backlight \
> > > >      binfmt \
> > > > +    efi \
> > > >      gshadow \
> > > >      hibernate \
> > > >      hostnamed \
> > > >
> > > >
> > > >
> > >
>
> -=-=-=-=-=-=-=-=-=-=-=-
> Links: You receive all messages sent to this group.
> View/Reply Online (#214684):
> https://lists.openembedded.org/g/openembedded-core/message/214684
> Mute This Topic: https://lists.openembedded.org/mt/112087523/1686489
> Group Owner: openembedded-core+owner@lists.openembedded.org
> Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [
> alex.kanavin@gmail.com]
> -=-=-=-=-=-=-=-=-=-=-=-
>
>

On Thu, 10 Apr 2025 at 20:45, Alexander Kanavin <alex.kanavin@gmail.com> wrote:
>
> But none of the last few messages answer my question. Can I restate it?

Why? The answer basically says that every board with u-boot or EDKII can



>
> Is there a physical board that can boot from ESP formatted to something else than FAT?
>
> Alex
>
> On Thu 10. Apr 2025 at 18.51, Ilias Apalodimas via lists.openembedded.org <ilias.apalodimas=linaro.org@lists.openembedded.org> wrote:
>>
>> Apologies for the noise, I forgot to add Adrian in CC
>>
>> On Thu, 10 Apr 2025 at 14:45, Ilias Apalodimas
>> <ilias.apalodimas@linaro.org> wrote:
>> >
>> > Hi Adrian
>> >
>> > On Thu, 10 Apr 2025 at 14:21, Adrian Freihofer <mikko.rapeli@linaro.org> wrote:
>> > >
>> > > Hi Mikko
>> > >
>> > > On Fri, 2025-04-04 at 19:29 +0300, Mikko Rapeli via
>> > > lists.openembedded.org wrote:
>> > > > For example genericarm64 enables "efi" in MACHINE_FEATURES
>> > > > and in u-boot. Boot without "efi" in systemd works with
>> > > > EFI protocols but for example efivars is not mounted at
>> > > > all so various checks fail in userspace. Fix these by
>> > > > enabling "efi" support by default to avoid making
>> > > > it machine specific. Fixes efivars mount to
>> > > > /sys/firmware/efi/efivars etc.
>> > >
>> > > My point is that many OE/Yocto-based embedded products rely on a fully
>> > > redundant and power fail-safe firmware update and boot implementation.
>> > > So far I have not understood how this could be implemented in a
>> > > similarly robust way based on EFI as we have now without EFI-based
>> > > boot-up.
>> >
>> > As far as the firmware updates are concerned there's [0], which is
>> > also implemented in U-Boot.
>> > But even in that case, I am not sure I understand your concerns. What
>> > prevents you from having the existing mechanisms for firmware updates
>> > on a system that boots with EFI?
>> >
>> > >  I would therefore like to see the EFI implementation remain
>> > > opt-in until it covers at least the most important use cases for robust
>> > > embedded systems. What I primarily miss with EFI is a reference
>> > > implementation for an A/B update system without having to rely on a FAT
>> > > partition without journaling. Please correct me if I'm missing
>> > > something!
>> >
>> > Where does the FAT partition requirement come from?
>> >
>> > >
>> > > Would it make sense to declare poky as an EFI ready reference
>> > > distribution by enabling the efi DISTRO_FEATURE there, rather than
>> > > starting with making recipes enabling efi unconditionally?
>> > >
>> > > Could something like this in poky.conf work?
>> > > DISTRO_FEATURES:append:aarch64 = " efi"
>> > > DISTRO_FEATURES:append:riscv64 = " efi"
>> > > DISTRO_FEATURES:append:x86-64 = " efi"
>> >
>> > [0] https://github.com/ARM-software/edge-iot-arch-guide/blob/main/source/FWU/MBFW/chapter1-introduction.md
>> >
>> > Thanks
>> > /Ilias
>> > >
>> > > Thank you and regards,
>> > > Adrian
>> > >
>> > > >
>> > > > Signed-off-by: Mikko Rapeli <mikko.rapeli@linaro.org>
>> > > > ---
>> > > >  meta/recipes-core/systemd/systemd_257.4.bb | 3 ++-
>> > > >  1 file changed, 2 insertions(+), 1 deletion(-)
>> > > >
>> > > > diff --git a/meta/recipes-core/systemd/systemd_257.4.bb
>> > > > b/meta/recipes-core/systemd/systemd_257.4.bb
>> > > > index 64fb8fe69a..06e5621398 100644
>> > > > --- a/meta/recipes-core/systemd/systemd_257.4.bb
>> > > > +++ b/meta/recipes-core/systemd/systemd_257.4.bb
>> > > > @@ -68,13 +68,14 @@ PAM_PLUGINS = " \
>> > > >  "
>> > > >
>> > > >  PACKAGECONFIG ??= " \
>> > > > -    ${@bb.utils.filter('DISTRO_FEATURES', 'acl audit apparmor efi
>> > > > ldconfig pam pni-names selinux smack polkit seccomp', d)} \
>> > > > +    ${@bb.utils.filter('DISTRO_FEATURES', 'acl audit apparmor
>> > > > ldconfig pam pni-names selinux smack polkit seccomp', d)} \
>> > > >      ${@bb.utils.contains('DISTRO_FEATURES', 'minidebuginfo',
>> > > > 'coredump elfutils', '', d)} \
>> > > >      ${@bb.utils.contains('DISTRO_FEATURES', 'wifi', 'rfkill', '',
>> > > > d)} \
>> > > >      ${@bb.utils.contains('DISTRO_FEATURES', 'x11', 'xkbcommon', '',
>> > > > d)} \
>> > > >      ${@bb.utils.contains('DISTRO_FEATURES', 'sysvinit', 'sysvinit',
>> > > > 'link-udev-shared', d)} \
>> > > >      backlight \
>> > > >      binfmt \
>> > > > +    efi \
>> > > >      gshadow \
>> > > >      hibernate \
>> > > >      hostnamed \
>> > > >
>> > > >
>> > > >
>> > >
>>
>> 
>>

On Thu, 10 Apr 2025 at 19:48, Ilias Apalodimas
<ilias.apalodimas@linaro.org> wrote:
> > But none of the last few messages answer my question. Can I restate it?
> > Is there a physical board that can boot from ESP formatted to something else than FAT?

> Why? The answer basically says that every board with u-boot or EDKII can

What I'm trying to get to is this: there's no working example (in the
shape of yocto BSP layer for instance) or evidence of anyone having
actually done it, ever. If you look at wic's bootimg-efi plugin, it
hardcodes vfat as partition type with no option for anything else. And
this is then used throughout meta-intel and meta-arm wks files, and
likely copied and tweaked into countless other layers. So it is not
exactly reassuring to hear 'but look at the zoo of filesystems that
u-boot supports'.

If I have a board in front of me (for instance, this Thinkpad X13
laptop from 2021 that I'm typing on right now), can I find out what it
can boot from? How?

Alex

On Thu, 2025-04-10 at 15:12 +0300, Ilias Apalodimas wrote:
> Apologies for the noise, I forgot to add Adrian in CC
> 
> On Thu, 10 Apr 2025 at 14:45, Ilias Apalodimas
> <ilias.apalodimas@linaro.org> wrote:
> > 
> > Hi Adrian
> > 
> > On Thu, 10 Apr 2025 at 14:21, Adrian Freihofer
> > <mikko.rapeli@linaro.org> wrote:
> > > 
> > > Hi Mikko
> > > 
> > > On Fri, 2025-04-04 at 19:29 +0300, Mikko Rapeli via
> > > lists.openembedded.org wrote:
> > > > For example genericarm64 enables "efi" in MACHINE_FEATURES
> > > > and in u-boot. Boot without "efi" in systemd works with
> > > > EFI protocols but for example efivars is not mounted at
> > > > all so various checks fail in userspace. Fix these by
> > > > enabling "efi" support by default to avoid making
> > > > it machine specific. Fixes efivars mount to
> > > > /sys/firmware/efi/efivars etc.
> > > 
> > > My point is that many OE/Yocto-based embedded products rely on a
> > > fully
> > > redundant and power fail-safe firmware update and boot
> > > implementation.
> > > So far I have not understood how this could be implemented in a
> > > similarly robust way based on EFI as we have now without EFI-
> > > based
> > > boot-up.
> > 
> > As far as the firmware updates are concerned there's [0], which is
> > also implemented in U-Boot.
> > But even in that case, I am not sure I understand your concerns.
> > What
> > prevents you from having the existing mechanisms for firmware
> > updates
> > on a system that boots with EFI?

Many thanks for the link. Yes, that basically describes how it should
be. But is there such a thing in reality? The discussion here doesn't
really convince me that EFI is already the proven easy way to build
robust and maintainable embedded systems. I understand why many people
are working towards EFI. But I still see great advantages in simpler
and available (in the sense of power-fail, robust) technologies for
many use cases today.

Anyway, my intention is not to start a controversial discussion about
EFI or SystemReady. My intention is to ensure that building systems
without disadvantages caused by the "EFI by default strategy" remains
possible and ideally also tested. As long as that is the case, I fully
agree with the patch.

> > 
> > >  I would therefore like to see the EFI implementation remain
> > > opt-in until it covers at least the most important use cases for
> > > robust
> > > embedded systems. What I primarily miss with EFI is a reference
> > > implementation for an A/B update system without having to rely on
> > > a FAT
> > > partition without journaling. Please correct me if I'm missing
> > > something!
> > 
> > Where does the FAT partition requirement come from?
> > 
> > > 
> > > Would it make sense to declare poky as an EFI ready reference
> > > distribution by enabling the efi DISTRO_FEATURE there, rather
> > > than
> > > starting with making recipes enabling efi unconditionally?
> > > 
> > > Could something like this in poky.conf work?
> > > DISTRO_FEATURES:append:aarch64 = " efi"
> > > DISTRO_FEATURES:append:riscv64 = " efi"
> > > DISTRO_FEATURES:append:x86-64 = " efi"

I was thinking about making this ARCH specific because:
- Defaulting to the most typical and use cases
- Keep a test matrix on the AB which builds systemd without efi
- ARCH specific is not an issue like MACHINE specific would be
- Having this policy in the distro seams more logical to me than in a
generic package.

But as I said, if the disadvantages of building with efi are negligible
for users without EFI use cases, then even better.

Thank you and regards,
Adrian

> > 
> > [0]
> > https://github.com/ARM-software/edge-iot-arch-guide/blob/main/source/FWU/MBFW/chapter1-introduction.md
> > 
> > Thanks
> > /Ilias
> > > 
> > > Thank you and regards,
> > > Adrian
> > > 
> > > > 
> > > > Signed-off-by: Mikko Rapeli <mikko.rapeli@linaro.org>
> > > > ---
> > > >  meta/recipes-core/systemd/systemd_257.4.bb | 3 ++-
> > > >  1 file changed, 2 insertions(+), 1 deletion(-)
> > > > 
> > > > diff --git a/meta/recipes-core/systemd/systemd_257.4.bb
> > > > b/meta/recipes-core/systemd/systemd_257.4.bb
> > > > index 64fb8fe69a..06e5621398 100644
> > > > --- a/meta/recipes-core/systemd/systemd_257.4.bb
> > > > +++ b/meta/recipes-core/systemd/systemd_257.4.bb
> > > > @@ -68,13 +68,14 @@ PAM_PLUGINS = " \
> > > >  "
> > > > 
> > > >  PACKAGECONFIG ??= " \
> > > > -    ${@bb.utils.filter('DISTRO_FEATURES', 'acl audit apparmor
> > > > efi
> > > > ldconfig pam pni-names selinux smack polkit seccomp', d)} \
> > > > +    ${@bb.utils.filter('DISTRO_FEATURES', 'acl audit apparmor
> > > > ldconfig pam pni-names selinux smack polkit seccomp', d)} \
> > > >      ${@bb.utils.contains('DISTRO_FEATURES', 'minidebuginfo',
> > > > 'coredump elfutils', '', d)} \
> > > >      ${@bb.utils.contains('DISTRO_FEATURES', 'wifi', 'rfkill',
> > > > '',
> > > > d)} \
> > > >      ${@bb.utils.contains('DISTRO_FEATURES', 'x11',
> > > > 'xkbcommon', '',
> > > > d)} \
> > > >      ${@bb.utils.contains('DISTRO_FEATURES', 'sysvinit',
> > > > 'sysvinit',
> > > > 'link-udev-shared', d)} \
> > > >      backlight \
> > > >      binfmt \
> > > > +    efi \
> > > >      gshadow \
> > > >      hibernate \
> > > >      hostnamed \
> > > > 
> > > > -=-=-=-=-=-=-=-=-=-=-=-
> > > > Links: You receive all messages sent to this group.
> > > > View/Reply Online (#214352):
> > > > https://lists.openembedded.org/g/openembedded-core/message/214352
> > > > Mute This Topic:
> > > > https://lists.openembedded.org/mt/112087523/4454582
> > > > Group Owner: openembedded-core+owner@lists.openembedded.org
> > > > Unsubscribe:
> > > > https://lists.openembedded.org/g/openembedded-core/unsub [
> > > > adrian.freihofer@gmail.com]
> > > > -=-=-=-=-=-=-=-=-=-=-=-
> > > > 
> > >

On 04-04-2025 18:29, Mikko Rapeli via lists.openembedded.org wrote:
> For example genericarm64 enables "efi" in MACHINE_FEATURES
> and in u-boot. Boot without "efi" in systemd works with
> EFI protocols but for example efivars is not mounted at
> all so various checks fail in userspace. Fix these by
> enabling "efi" support by default to avoid making
> it machine specific. Fixes efivars mount to
> /sys/firmware/efi/efivars etc.

Looks like all you need to do is include "efi" in your DISTRO_FEATURES for 
your product.

You're offloading your problem onto others. If your patch gets merged, it 
would mean that I would have to devise some way to conditionally remove efi 
from the PACKAGECONFIG again.

I don't know what platforms you're targetting, but many embedded systems don't 
use EFI boot, and some even don't have a block device they could put a FAT 
partition on...

M.


>
> Signed-off-by: Mikko Rapeli <mikko.rapeli@linaro.org>
> ---
>   meta/recipes-core/systemd/systemd_257.4.bb | 3 ++-
>   1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/meta/recipes-core/systemd/systemd_257.4.bb b/meta/recipes-core/systemd/systemd_257.4.bb
> index 64fb8fe69a..06e5621398 100644
> --- a/meta/recipes-core/systemd/systemd_257.4.bb
> +++ b/meta/recipes-core/systemd/systemd_257.4.bb
> @@ -68,13 +68,14 @@ PAM_PLUGINS = " \
>   "
>   
>   PACKAGECONFIG ??= " \
> -    ${@bb.utils.filter('DISTRO_FEATURES', 'acl audit apparmor efi ldconfig pam pni-names selinux smack polkit seccomp', d)} \
> +    ${@bb.utils.filter('DISTRO_FEATURES', 'acl audit apparmor ldconfig pam pni-names selinux smack polkit seccomp', d)} \
>       ${@bb.utils.contains('DISTRO_FEATURES', 'minidebuginfo', 'coredump elfutils', '', d)} \
>       ${@bb.utils.contains('DISTRO_FEATURES', 'wifi', 'rfkill', '', d)} \
>       ${@bb.utils.contains('DISTRO_FEATURES', 'x11', 'xkbcommon', '', d)} \
>       ${@bb.utils.contains('DISTRO_FEATURES', 'sysvinit', 'sysvinit', 'link-udev-shared', d)} \
>       backlight \
>       binfmt \
> +    efi \
>       gshadow \
>       hibernate \
>       hostnamed \
>

Hi Adrian

On Thu, 10 Apr 2025 at 23:53, Adrian Freihofer
<adrian.freihofer@gmail.com> wrote:
>
> On Thu, 2025-04-10 at 15:12 +0300, Ilias Apalodimas wrote:
> > Apologies for the noise, I forgot to add Adrian in CC
> >
> > On Thu, 10 Apr 2025 at 14:45, Ilias Apalodimas
> > <ilias.apalodimas@linaro.org> wrote:
> > >
> > > Hi Adrian
> > >
> > > On Thu, 10 Apr 2025 at 14:21, Adrian Freihofer
> > > <mikko.rapeli@linaro.org> wrote:
> > > >
> > > > Hi Mikko
> > > >
> > > > On Fri, 2025-04-04 at 19:29 +0300, Mikko Rapeli via
> > > > lists.openembedded.org wrote:
> > > > > For example genericarm64 enables "efi" in MACHINE_FEATURES
> > > > > and in u-boot. Boot without "efi" in systemd works with
> > > > > EFI protocols but for example efivars is not mounted at
> > > > > all so various checks fail in userspace. Fix these by
> > > > > enabling "efi" support by default to avoid making
> > > > > it machine specific. Fixes efivars mount to
> > > > > /sys/firmware/efi/efivars etc.
> > > >
> > > > My point is that many OE/Yocto-based embedded products rely on a
> > > > fully
> > > > redundant and power fail-safe firmware update and boot
> > > > implementation.
> > > > So far I have not understood how this could be implemented in a
> > > > similarly robust way based on EFI as we have now without EFI-
> > > > based
> > > > boot-up.
> > >
> > > As far as the firmware updates are concerned there's [0], which is
> > > also implemented in U-Boot.
> > > But even in that case, I am not sure I understand your concerns.
> > > What
> > > prevents you from having the existing mechanisms for firmware
> > > updates
> > > on a system that boots with EFI?
>
> Many thanks for the link.

yw

> Yes, that basically describes how it should
> be. But is there such a thing in reality?

Yes it actually works for some boards in U-Boot and people are
shipping it. I am also discussing with the fwupd maintainers on how to
make it seamless in the future.

The Socionext Synquacer and some ST (stmp32mp1) are the ones I
remember. We definitely want to add more boards.

> The discussion here doesn't
> really convince me that EFI is already the proven easy way to build
> robust and maintainable embedded systems.

Again, I'll limit the discussion in U-Boot -- if there are other EFI
implementations you are worried about, feel free to add them.
UEFI has a weird learning curve, I understand that but it standardizes
a few things that people are struggling with and that's why distros
use it.
I don't know if that's useful for vertical distros -- but the ability
to boot the same OS across many different devices is appealing to some
vendors. It also tries to standardize security and most notably Secure
Boot and measured boot which is  a usual headache.  There's still a
vendor specific bit in there on how to setup your chain of trust, but
once you reach BL33( the efi loader) everything looks identical.
U-Boot nowadays is pretty complete. You can literally install a distro
using its installer either via putting the installer on a disk or
doing it over HTTP.
There are some kernel module requirements for the latter, but AFAIK
debian and the latest fedora42 already support the modules (notably
OF_PMEM).

> I understand why many people
> are working towards EFI. But I still see great advantages in simpler
> and available (in the sense of power-fail, robust) technologies for
> many use cases today.

Fair enough. However, what I am trying to say here is with or without
EFI i am not aware of any limitations. In fact most of the arch
kernels build with EFI support enabled by default.
IOW, no one *forces* you to use capsule updates to update your
firmware or use EFI to boot your system.

>
> Anyway, my intention is not to start a controversial discussion about
> EFI or SystemReady. My intention is to ensure that building systems
> without disadvantages caused by the "EFI by default strategy" remains
> possible and ideally also tested. As long as that is the case, I fully
> agree with the patch.

Understood and as I said, I don't think it will break anything -- and
if it does, we should just fix it because in principle it shouldn't.

>
> > >
> > > >  I would therefore like to see the EFI implementation remain
> > > > opt-in until it covers at least the most important use cases for
> > > > robust
> > > > embedded systems. What I primarily miss with EFI is a reference
> > > > implementation for an A/B update system without having to rely on
> > > > a FAT
> > > > partition without journaling. Please correct me if I'm missing
> > > > something!
> > >
> > > Where does the FAT partition requirement come from?
> > >
> > > >
> > > > Would it make sense to declare poky as an EFI ready reference
> > > > distribution by enabling the efi DISTRO_FEATURE there, rather
> > > > than
> > > > starting with making recipes enabling efi unconditionally?
> > > >
> > > > Could something like this in poky.conf work?
> > > > DISTRO_FEATURES:append:aarch64 = " efi"
> > > > DISTRO_FEATURES:append:riscv64 = " efi"
> > > > DISTRO_FEATURES:append:x86-64 = " efi"
>
> I was thinking about making this ARCH specific because:
> - Defaulting to the most typical and use cases
> - Keep a test matrix on the AB which builds systemd without efi
> - ARCH specific is not an issue like MACHINE specific would be
> - Having this policy in the distro seams more logical to me than in a
> generic package.
>
> But as I said, if the disadvantages of building with efi are negligible
> for users without EFI use cases, then even better.

Agreed.

Thanks
/Ilias
>
> Thank you and regards,
> Adrian
>
> > >
> > > [0]
> > > https://github.com/ARM-software/edge-iot-arch-guide/blob/main/source/FWU/MBFW/chapter1-introduction.md
> > >
> > > Thanks
> > > /Ilias
> > > >
> > > > Thank you and regards,
> > > > Adrian
> > > >
> > > > >
> > > > > Signed-off-by: Mikko Rapeli <mikko.rapeli@linaro.org>
> > > > > ---
> > > > >  meta/recipes-core/systemd/systemd_257.4.bb | 3 ++-
> > > > >  1 file changed, 2 insertions(+), 1 deletion(-)
> > > > >
> > > > > diff --git a/meta/recipes-core/systemd/systemd_257.4.bb
> > > > > b/meta/recipes-core/systemd/systemd_257.4.bb
> > > > > index 64fb8fe69a..06e5621398 100644
> > > > > --- a/meta/recipes-core/systemd/systemd_257.4.bb
> > > > > +++ b/meta/recipes-core/systemd/systemd_257.4.bb
> > > > > @@ -68,13 +68,14 @@ PAM_PLUGINS = " \
> > > > >  "
> > > > >
> > > > >  PACKAGECONFIG ??= " \
> > > > > -    ${@bb.utils.filter('DISTRO_FEATURES', 'acl audit apparmor
> > > > > efi
> > > > > ldconfig pam pni-names selinux smack polkit seccomp', d)} \
> > > > > +    ${@bb.utils.filter('DISTRO_FEATURES', 'acl audit apparmor
> > > > > ldconfig pam pni-names selinux smack polkit seccomp', d)} \
> > > > >      ${@bb.utils.contains('DISTRO_FEATURES', 'minidebuginfo',
> > > > > 'coredump elfutils', '', d)} \
> > > > >      ${@bb.utils.contains('DISTRO_FEATURES', 'wifi', 'rfkill',
> > > > > '',
> > > > > d)} \
> > > > >      ${@bb.utils.contains('DISTRO_FEATURES', 'x11',
> > > > > 'xkbcommon', '',
> > > > > d)} \
> > > > >      ${@bb.utils.contains('DISTRO_FEATURES', 'sysvinit',
> > > > > 'sysvinit',
> > > > > 'link-udev-shared', d)} \
> > > > >      backlight \
> > > > >      binfmt \
> > > > > +    efi \
> > > > >      gshadow \
> > > > >      hibernate \
> > > > >      hostnamed \
> > > > >
> > > > > 
> > > > >
> > > >
>

Hi,

On Fri, Apr 11, 2025 at 10:40:25AM +0200, Mike Looijmans via lists.openembedded.org wrote:
> On 04-04-2025 18:29, Mikko Rapeli via lists.openembedded.org wrote:
> > For example genericarm64 enables "efi" in MACHINE_FEATURES
> > and in u-boot. Boot without "efi" in systemd works with
> > EFI protocols but for example efivars is not mounted at
> > all so various checks fail in userspace. Fix these by
> > enabling "efi" support by default to avoid making
> > it machine specific. Fixes efivars mount to
> > /sys/firmware/efi/efivars etc.
> 
> Looks like all you need to do is include "efi" in your DISTRO_FEATURES for
> your product.

My product is actually oe-core and poky. Machine is genericarm64
which already has "efi" in MACHINE_FEATURES. I help Ross to maintain
this in oe-core/poky. Test target machines include qemu, TI BeaglePlay,
AMD KV260, AMD zcu102, rockpi4b, Synquacer etc. We plan to add
Qualcomm RB5 too but there is currently an issue with genericarm64
serial console there, some kernel driver dependency or module vs
built-in. I hope this gets sorted out soon.

> You're offloading your problem onto others. If your patch gets merged, it
> would mean that I would have to devise some way to conditionally remove efi
> from the PACKAGECONFIG again.

Sorry but sensible defaults are not optimal for everyone. "efi" support
in systemd is in my opionion a good default for oe-core and poky
when systemd is selected as init.

All arm and x86_64 machines in oe-core use qemu with u-boot or edk2/ovmf
in UEFI compatible fashion by default to test things. Yes, systemd
in rootfs will boot without "efi" enabled there but various checks
which rely on EFI interfaces can't be done since efivars is not
mounted.

Richard already rejected making systemd machine specific by
enabling "efi" support via MACHINE_FEATURES. One alternative
could be to enable "efi" in DISTRO_FEATURES for "poky-altcfg"
which enables systemd as init, among other things.

> I don't know what platforms you're targetting, but many embedded systems
> don't use EFI boot, and some even don't have a block device they could put a
> FAT partition on...

I target oe-core and poky defaults. This EFI support does not harm
platforms which don't have EFI firmware. Those configurations can
further optimise the setup including remove EFI support from systemd,
kernel, u-boot/edk2 etc. Many of default machine and distro features
and default packageconfig setups are not optimised for real products.
They are sensible defaults and good starting points. My argument is that
EFI firmware is so common as a default that support for it should
be enabled by default in systemd init of oe-core/poky. Upstream
u-boot defconfigs for all targets enable EFI support by default,
for example.

Cheers,

-Mikko

On Thu, 10 Apr 2025 at 22:19, Alexander Kanavin <alex.kanavin@gmail.com> wrote:
>
> On Thu, 10 Apr 2025 at 19:48, Ilias Apalodimas
> <ilias.apalodimas@linaro.org> wrote:
> > > But none of the last few messages answer my question. Can I restate it?
> > > Is there a physical board that can boot from ESP formatted to something else than FAT?
>
> > Why? The answer basically says that every board with u-boot or EDKII can
>
> What I'm trying to get to is this: there's no working example (in the
> shape of yocto BSP layer for instance) or evidence of anyone having
> actually done it, ever. If you look at wic's bootimg-efi plugin, it
> hardcodes vfat as partition type with no option for anything else. And
> this is then used throughout meta-intel and meta-arm wks files, and
> likely copied and tweaked into countless other layers. So it is not
> exactly reassuring to hear 'but look at the zoo of filesystems that
> u-boot supports'.

All of what you mention here seem to be OE limitations which can be
easily fixed. But that's still completely orthogonal to the current
patchset. I don't see how enabling EFI automatically forces you to
swap around your entire boot or firmware update strategy.

>
> If I have a board in front of me (for instance, this Thinkpad X13
> laptop from 2021 that I'm typing on right now), can I find out what it
> can boot from? How?

Without extra information on how that firmware was compiled or what it
was compiled to support I can't answer that. The easiest thing to do
is check if you can load something from a !FAT filesystem from the
firmware.
/Ilias
>
> Alex

On 11-04-2025 12:45, Mikko Rapeli wrote:
> Hi,
>
> On Fri, Apr 11, 2025 at 10:40:25AM +0200, Mike Looijmans via lists.openembedded.org wrote:
>> On 04-04-2025 18:29, Mikko Rapeli via lists.openembedded.org wrote:
>>> For example genericarm64 enables "efi" in MACHINE_FEATURES
>>> and in u-boot. Boot without "efi" in systemd works with
>>> EFI protocols but for example efivars is not mounted at
>>> all so various checks fail in userspace. Fix these by
>>> enabling "efi" support by default to avoid making
>>> it machine specific. Fixes efivars mount to
>>> /sys/firmware/efi/efivars etc.
>> Looks like all you need to do is include "efi" in your DISTRO_FEATURES for
>> your product.
> My product is actually oe-core and poky. Machine is genericarm64
> which already has "efi" in MACHINE_FEATURES. I help Ross to maintain
> this in oe-core/poky. Test target machines include qemu, TI BeaglePlay,
> AMD KV260, AMD zcu102, rockpi4b, Synquacer etc. We plan to add
> Qualcomm RB5 too but there is currently an issue with genericarm64
> serial console there, some kernel driver dependency or module vs
> built-in. I hope this gets sorted out soon.
>
>> You're offloading your problem onto others. If your patch gets merged, it
>> would mean that I would have to devise some way to conditionally remove efi
>> from the PACKAGECONFIG again.
> Sorry but sensible defaults are not optimal for everyone. "efi" support
> in systemd is in my opionion a good default for oe-core and poky
> when systemd is selected as init.
>
> All arm and x86_64 machines in oe-core use qemu with u-boot or edk2/ovmf
> in UEFI compatible fashion by default to test things. Yes, systemd
> in rootfs will boot without "efi" enabled there but various checks
> which rely on EFI interfaces can't be done since efivars is not
> mounted.

But qemu is not something that you'd find in an actual product...

I feel that defaults should be based on real-life targets. None of the boards 
I worked with so far ever used EFI for booting. And that isn't because of lack 
of variance...


> Richard already rejected making systemd machine specific by
> enabling "efi" support via MACHINE_FEATURES. One alternative
> could be to enable "efi" in DISTRO_FEATURES for "poky-altcfg"
> which enables systemd as init, among other things.

That's perfectly logic. If the systemd config becomes MACHINE specific, 
hundreds of other packages will also become machine specific. So using 
MACHINE_FEATURES in the systemd recipe is a big no no.

>> I don't know what platforms you're targetting, but many embedded systems
>> don't use EFI boot, and some even don't have a block device they could put a
>> FAT partition on...
> I target oe-core and poky defaults. This EFI support does not harm
> platforms which don't have EFI firmware. Those configurations can
> further optimise the setup including remove EFI support from systemd,
> kernel, u-boot/edk2 etc. Many of default machine and distro features
> and default packageconfig setups are not optimised for real products.
> They are sensible defaults and good starting points. My argument is that
> EFI firmware is so common as a default that support for it should
> be enabled by default in systemd init of oe-core/poky. Upstream
> u-boot defconfigs for all targets enable EFI support by default,
> for example.

I don't know what the "efi" config will actually produce in systemd. Ideally, 
one would build systemd with efi support enabled, and then decide when 
composing the image whether to include that or not. Something like adding 
"systemd-efi" to packagegroup-boot or so when MACHINE_FEATURES contains "efi".

M.

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.

Thank you
Adrian



Am Fr., 11. Apr. 2025 um 13:08 Uhr schrieb Mike Looijmans via
lists.openembedded.org <mike.looijmans=topic.nl@lists.openembedded.org>:

> On 11-04-2025 12:45, Mikko Rapeli wrote:
> > Hi,
> >
> > On Fri, Apr 11, 2025 at 10:40:25AM +0200, Mike Looijmans via
> lists.openembedded.org wrote:
> >> On 04-04-2025 18:29, Mikko Rapeli via lists.openembedded.org wrote:
> >>> For example genericarm64 enables "efi" in MACHINE_FEATURES
> >>> and in u-boot. Boot without "efi" in systemd works with
> >>> EFI protocols but for example efivars is not mounted at
> >>> all so various checks fail in userspace. Fix these by
> >>> enabling "efi" support by default to avoid making
> >>> it machine specific. Fixes efivars mount to
> >>> /sys/firmware/efi/efivars etc.
> >> Looks like all you need to do is include "efi" in your DISTRO_FEATURES
> for
> >> your product.
> > My product is actually oe-core and poky. Machine is genericarm64
> > which already has "efi" in MACHINE_FEATURES. I help Ross to maintain
> > this in oe-core/poky. Test target machines include qemu, TI BeaglePlay,
> > AMD KV260, AMD zcu102, rockpi4b, Synquacer etc. We plan to add
> > Qualcomm RB5 too but there is currently an issue with genericarm64
> > serial console there, some kernel driver dependency or module vs
> > built-in. I hope this gets sorted out soon.
> >
> >> You're offloading your problem onto others. If your patch gets merged,
> it
> >> would mean that I would have to devise some way to conditionally remove
> efi
> >> from the PACKAGECONFIG again.
> > Sorry but sensible defaults are not optimal for everyone. "efi" support
> > in systemd is in my opionion a good default for oe-core and poky
> > when systemd is selected as init.
> >
> > All arm and x86_64 machines in oe-core use qemu with u-boot or edk2/ovmf
> > in UEFI compatible fashion by default to test things. Yes, systemd
> > in rootfs will boot without "efi" enabled there but various checks
> > which rely on EFI interfaces can't be done since efivars is not
> > mounted.
>
> But qemu is not something that you'd find in an actual product...
>
> I feel that defaults should be based on real-life targets. None of the
> boards
> I worked with so far ever used EFI for booting. And that isn't because of
> lack
> of variance...
>
>
> > Richard already rejected making systemd machine specific by
> > enabling "efi" support via MACHINE_FEATURES. One alternative
> > could be to enable "efi" in DISTRO_FEATURES for "poky-altcfg"
> > which enables systemd as init, among other things.
>
> That's perfectly logic. If the systemd config becomes MACHINE specific,
> hundreds of other packages will also become machine specific. So using
> MACHINE_FEATURES in the systemd recipe is a big no no.
>
> >> I don't know what platforms you're targetting, but many embedded systems
> >> don't use EFI boot, and some even don't have a block device they could
> put a
> >> FAT partition on...
> > I target oe-core and poky defaults. This EFI support does not harm
> > platforms which don't have EFI firmware. Those configurations can
> > further optimise the setup including remove EFI support from systemd,
> > kernel, u-boot/edk2 etc. Many of default machine and distro features
> > and default packageconfig setups are not optimised for real products.
> > They are sensible defaults and good starting points. My argument is that
> > EFI firmware is so common as a default that support for it should
> > be enabled by default in systemd init of oe-core/poky. Upstream
> > u-boot defconfigs for all targets enable EFI support by default,
> > for example.
>
> I don't know what the "efi" config will actually produce in systemd.
> Ideally,
> one would build systemd with efi support enabled, and then decide when
> composing the image whether to include that or not. Something like adding
> "systemd-efi" to packagegroup-boot or so when MACHINE_FEATURES contains
> "efi".
>
> M.
>
>
>
>
>
> -=-=-=-=-=-=-=-=-=-=-=-
> Links: You receive all messages sent to this group.
> View/Reply Online (#214732):
> https://lists.openembedded.org/g/openembedded-core/message/214732
> Mute This Topic: https://lists.openembedded.org/mt/112087523/4454582
> Group Owner: openembedded-core+owner@lists.openembedded.org
> Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [
> adrian.freihofer@gmail.com]
> -=-=-=-=-=-=-=-=-=-=-=-
>
>

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.

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

 * /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

Mikko Rapeli via lists.openembedded.org <mikko.rapeli=
linaro.org@lists.openembedded.org> escreveu (terça, 15/04/2025 à(s) 10:51):

> 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.
>
> 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
>
>  * /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"
>

With that change I think you can remove ${D}${nonarch_libdir}/systemd/boot
in systemd as it will be provided also by systemd-boot.
This removal of the efi binaries will make the systemd package size mostly
the same.

Jose


>   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
>
> -=-=-=-=-=-=-=-=-=-=-=-
> Links: You receive all messages sent to this group.
> View/Reply Online (#214835):
> https://lists.openembedded.org/g/openembedded-core/message/214835
> Mute This Topic: https://lists.openembedded.org/mt/112087523/5052612
> Group Owner: openembedded-core+owner@lists.openembedded.org
> Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [
> quaresma.jose@gmail.com]
> -=-=-=-=-=-=-=-=-=-=-=-
>
>

> -----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.

> 
> 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"?

> 
>  * /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

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
>

> Op 16 apr 2025, om 08:08 heeft Mikko Rapeli via lists.openembedded.org <mikko.rapeli=linaro.org@lists.openembedded.org> het volgende geschreven:
> 
> 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.

So it sucks to be them, they can't have their cake and eat it as well. If you want 'efi' in your DISTRO_FEATURES, add it to your DISTRO_FEATURES. That is what is so great about OE: you can very easily create your own, optionally derivative, DISTRO.

regards,

Koen

On Wed, 2025-04-16 at 09:08 +0300, Mikko Rapeli wrote:
> 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.

I understand why ARM is pushing for EFI by default.
- For servers, laptops, makers and other use cases, it is important to
provide a stable ABI between the bootloader and the rest of the system.
However, so far this is often just a “nice to have” requirement for
truly industrial-grade, robust, Yocto-based embedded products.
- In the future, features like secure boot or remote attestation will
become much more important for many products. I think EFI (in
combination with a TPM) can be of great help in this area. So it seems
to be less a question of whether EFI will find its way into more
OE/Yocto-based products, but much more a question of when it will find
its way into more OE/Yocto-based products. Maybe it should become the
default as soon as possible.

> 
> > > 
> > >  * /usr/lib/systemd/libsystemd-shared-257.so size increases 32
> > > bytes from
> > >    4012152 to 4012184 bytes, 0.0008%

That looks like a great compromise for EFI built-in by default.

> > > 
> > >  * 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:

It looks to me like more cleanup is needed here before EFI can be
enabled by default. It should be possible to get only the 0.0008% extra
size of the systemd package into an image if systemd is compiled with
EFI support, but the systemd-boot package is not installed into the
image.

There should also be some kind of confirmation from the systemd
community that such a package split is supported by design and will
remain so in the future. At least the Fedora package distribution looks
like this:
https://src.fedoraproject.org/rpms/systemd/blob/rawhide/f/systemd.spec#_560
.

I'm not sure if some tests are needed to check that compiling with efi
but using it without the systemd-boot package actually works. But at
the moment it seems a bit too much like taking risks for non-EFI users.

Thank you for sharing these numbers!
Adrian


> > > 
> > > --- 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
> >

> -----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