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

mike.looijmans
2025-04-11T11:08:50Z

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.