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

[Adrian Freihofer <adrian.freihofer@gmail.com>]

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