[PATCH v3 00/11] systemd based initrd and modular kernel support

[PATCH v3 00/11] systemd based initrd and modular kernel support

[Mikko Rapeli]

systemd based initrd supports more security, encryption etc features
than custom shell script ones but oe-core lacks support for it.
Convert core-image-initramfs-boot to create systemd based initrd
if "systemd-initramfs" is set in DISTRO_FEATURES. Includes a test
for this initrd to mount rootfs via Unified Kernel Image uki.py.

Sadly the boot time is really slow, e.g. over 30 seconds with
systemd based initrd. One of the major reasons is the large
amount of kernel modules built into the linux-yocto kernel and
processing of their udev events in userspace. Thus add
kernel-initrd-modules meta package to easily install
subset of all kernel modules to initrd. The subset
supports "mount rootfs from any block device" but
doesn't include graphics, UBS etc support. Without this
generated meta package, initrd recipe needs to manually define
which exact kernel modules to include which breaks if
those modules are built into the kernel. Thus the initrd
becomes machine and kernel config specific and hard to maintain.
With this meta package a generic initrd can be created.

Separate changes to linux-yocto compile a lot more drivers
as modules but they depend on these initrd changes.

v1: https://lists.openembedded.org/g/openembedded-core/message/212832

v2: split initrd size reduction and kernel modules addition
    to separate commits, added packages exclicitly back to fix
    rootfs mount visible as wic selftest failures,
    fixed wic bugs which resulted in broken boot due to missing
    EFI bootloader binaries in some builds, moved
    "systemd: use serial-getty-generator on genericarm64" to separate
    series since it's not strictly needed and goes to a different mailing
    list

v3: enable "efi" support in systemd by default not via MACHINE_FEATURES,
    disable kernel-initrd-modules meta package generation if
    KERNEL_INITRD_MODULES_REGEX is not set at all, keeping
    default KERNEL_INITRD_MODULES_REGEX in classes to support
    external kernel recipes (which could be compatible with default
    images to e.g. run upstream tests), tested (with pmem and
    modular kernel RFC patches sent out separately) using genericarm64
    machine config on:
    qemu u-boot https://ledge.validation.linaro.org/scheduler/job/106701
    qemu edk2 https://ledge.validation.linaro.org/scheduler/job/106703
    AMD zcu102 https://ledge.validation.linaro.org/scheduler/job/106702
    AMD kv260 https://ledge.validation.linaro.org/scheduler/job/106700
    rpi4 https://ledge.validation.linaro.org/scheduler/job/106705

Mikko Rapeli (11):
  systemd: enable efi support by default
  uki.bbclass: drop serial console from kernel command line
  kernel.bbclass: add kernel-initrd-modules meta package
  core-image-initramfs-boot: add option to build systemd based initrd
  core-image-initramfs-boot: don't install RRECOMMENDS to reduce size
  core-image-initramfs-boot: install kernel-initrd-modules by default
  oeqa selftest uki.py: add aarch64/arm test with systemd based initrd
  test_efi_plugin_plain_systemd-boot: don't set console
  image_types_wic.bbclass: capture verbose wic output by default
  wic bootimg-efi.py: fail build if no binaries installed
  image_types_wic.bbclass: depend on grub-efi and systemd-boot on
    aarch64, systemd-boot on arm

 .../test_efi_plugin_plain_systemd-boot.wks    |  2 +-
 meta/classes-recipe/image_types_wic.bbclass   |  4 +-
 .../kernel-module-split.bbclass               | 48 ++++++++++++
 meta/classes-recipe/kernel.bbclass            |  5 +-
 meta/classes-recipe/module.bbclass            | 37 +++++++++
 meta/classes-recipe/uki.bbclass               |  2 +-
 meta/lib/oeqa/selftest/cases/uki.py           | 76 +++++++++++++++++++
 .../images/core-image-initramfs-boot.bb       | 32 +++++++-
 meta/recipes-core/systemd/systemd_257.4.bb    |  3 +-
 scripts/lib/wic/plugins/source/bootimg-efi.py |  3 +
 10 files changed, 203 insertions(+), 9 deletions(-)

-- 
2.43.0

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

[Mikko Rapeli]

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

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

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

[Adrian Freihofer]

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

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

[Mikko Rapeli]

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

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

[Ilias Apalodimas]

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

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

[Ilias Apalodimas]

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

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

[Alexander Kanavin]

[-- Attachment #1: Type: text/plain, Size: 4615 bytes --]

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

[-- Attachment #2: Type: text/html, Size: 7591 bytes --]

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

[Ilias Apalodimas]

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

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

[Alexander Kanavin]

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

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

[Ilias Apalodimas]

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

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

[Adrian Freihofer]

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

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

[Ilias Apalodimas]

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

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

[Alexander Kanavin]

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

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

[Ilias Apalodimas]

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

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

[Alexander Kanavin]

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

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

[Ilias Apalodimas]

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

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

[Alexander Kanavin]

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

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

[Ilias Apalodimas]

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

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

[Mikko Rapeli]

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

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

[Mike Looijmans]

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

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

[Mikko Rapeli]

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

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

[mike.looijmans]

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.

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

[Adrian Freihofer]

[-- Attachment #1: Type: text/plain, Size: 4705 bytes --]

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

[-- Attachment #2: Type: text/html, Size: 6442 bytes --]

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

[Mikko Rapeli]

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

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

[Jose Quaresma]

[-- Attachment #1: Type: text/plain, Size: 6845 bytes --]

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

-- 
Best regards,

José Quaresma

[-- Attachment #2: Type: text/html, Size: 9425 bytes --]

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

[Peter Kjellerstedt]

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

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

[Mikko Rapeli]

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
> 

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

[Koen Kooi]

> 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

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

[Adrian Freihofer]

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

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

[Peter Kjellerstedt]

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

[PATCH v3 02/11] uki.bbclass: drop serial console from kernel command line

[Mikko Rapeli]

The kernel will continue using console from firmware which is
much better on HW when we may not know at build time which
console HW and drivers are available, e.g. like on
genericarm64 machine.

Signed-off-by: Mikko Rapeli <mikko.rapeli@linaro.org>
---
 meta/classes-recipe/uki.bbclass | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meta/classes-recipe/uki.bbclass b/meta/classes-recipe/uki.bbclass
index d9a7fb0e6f..fedff222c6 100644
--- a/meta/classes-recipe/uki.bbclass
+++ b/meta/classes-recipe/uki.bbclass
@@ -81,7 +81,7 @@ UKIFY_CMD ?= "ukify build"
 UKI_CONFIG_FILE ?= "${UNPACKDIR}/uki.conf"
 UKI_FILENAME ?= "uki.efi"
 UKI_KERNEL_FILENAME ?= "${KERNEL_IMAGETYPE}"
-UKI_CMDLINE ?= "rootwait root=LABEL=root console=${KERNEL_CONSOLE}"
+UKI_CMDLINE ?= "rootwait root=LABEL=root"
 # secure boot keys and cert, needs sbsign-tools-native (meta-secure-core)
 #UKI_SB_KEY ?= ""
 #UKI_SB_CERT ?= ""
-- 
2.43.0

[PATCH v3 03/11] kernel.bbclass: add kernel-initrd-modules meta package

[Mikko Rapeli]

At the moment linux-yocto kernels for various architectures
are not very modular and a lot of drivers are built into the kernel
even when they are not needed at runtime. These make the main kernel
binary big and slow to boot. This also impacts udev in userspace
which takes a long time processing events from all these built in drivers,
for example when udev runs in initrd.

Then constructing the initrd is very device and kernel configuration specific.
initrd image needs explicitly define which binary packages to install
to avoid pulling in complex dependencies. A full set of kernel modules
via kernel-modules meta package is too big for initrd and most of the
drivers are not needed for use cases like "just load modules to mount
main rootfs". Then the initrd configuration breaks if kernel driver
is built into the kernel since the binary package doesn't exist.

Introduce kernel-initrd-modules meta package to solve these problems.
The meta package adds dependencies to real kernel modules based on
the kernel module file paths so that it will include several
kernel subsystems and their drivers which are often needed to find
main rootfs from some block device. This works when drivers are built
as modules but does not break if drivers are built into the kernel.

The resulting initrd is also smaller since only a subset of drivers
are needed for "mount the rootfs" usecase. Tested on genericarm64
kernel and qemu and AMD KV260 HW.

Signed-off-by: Mikko Rapeli <mikko.rapeli@linaro.org>
---
 .../kernel-module-split.bbclass               | 48 +++++++++++++++++++
 meta/classes-recipe/kernel.bbclass            |  5 +-
 meta/classes-recipe/module.bbclass            | 37 ++++++++++++++
 3 files changed, 89 insertions(+), 1 deletion(-)

diff --git a/meta/classes-recipe/kernel-module-split.bbclass b/meta/classes-recipe/kernel-module-split.bbclass
index 9487365eb7..101c5cd959 100644
--- a/meta/classes-recipe/kernel-module-split.bbclass
+++ b/meta/classes-recipe/kernel-module-split.bbclass
@@ -42,6 +42,40 @@ KERNEL_MODULE_PACKAGE_PREFIX ?= ""
 KERNEL_MODULE_PACKAGE_SUFFIX ?= "-${KERNEL_VERSION}"
 KERNEL_MODULE_PROVIDE_VIRTUAL ?= "1"
 
+# subset of kernel modules needed in initrd, to e.g. mount rootfs from block device
+KERNEL_INITRD_MODULES_META_PACKAGE ?= "${@ d.getVar("KERNEL_PACKAGE_NAME") or "kernel" }-initrd-modules"
+
+# match regex to path or file name. E.g. include all drivers with files in path /drivers/ata/
+KERNEL_INITRD_MODULES_REGEX ?= "(.*)(\
+/drivers/acpi/|\
+/drivers/ata/|\
+/drivers/block/|\
+/drivers/cdrom/|\
+/drivers/char/hw_random/|\
+/drivers/char/tpm/|\
+/drivers/char/|\
+/drivers/crypto/|\
+/drivers/dax/|\
+/drivers/firmware/arm_scmi/|\
+/drivers/gpu/drm/|\
+/drivers/md/|\
+/drivers/mmc/|\
+/drivers/mtd/|\
+/drivers/nvdimm/|\
+/drivers/nvme/|\
+/drivers/pci/|\
+/drivers/scsi/|\
+/drivers/tee/|\
+/drivers/tty/serial/|\
+/drivers/virtio/|\
+/drivers/watchdog/|\
+/kernel/arch/|\
+/kernel/block/|\
+/kernel/crypto/|\
+/kernel/fs/|\
+/kernel/lib/\
+)(.*)"
+
 python split_kernel_module_packages () {
     import re
 
@@ -183,6 +217,20 @@ python split_kernel_module_packages () {
     modules = do_split_packages(d, root='${nonarch_base_libdir}/modules', file_regex=module_regex, output_pattern=module_pattern, description='%s kernel module', postinst=postinst, postrm=postrm, recursive=True, hook=frob_metadata, extra_depends='%s-%s' % (kernel_package_name, kernel_version))
     if modules:
         d.appendVar('RDEPENDS:' + metapkg, ' '+' '.join(modules))
+
+    initrd_metapkg = d.getVar('KERNEL_INITRD_MODULES_META_PACKAGE') or ""
+    initrd_module_regex = d.getVar('KERNEL_INITRD_MODULES_REGEX') or ""
+    if (initrd_metapkg != "") and (initrd_module_regex != ""):
+        initrd_module_regex = re.compile(initrd_module_regex)
+        initrd_modules = []
+        for module in modules:
+            files = d.getVar('FILES:' + module)
+            m = re.match(initrd_module_regex, files)
+            if m:
+                initrd_modules.append(module)
+
+        if initrd_modules:
+            d.appendVar('RDEPENDS:' + initrd_metapkg, ' '+' '.join(initrd_modules))
 }
 
 do_package[vardeps] += '${@" ".join(map(lambda s: "module_conf_" + s, (d.getVar("KERNEL_MODULE_PROBECONF") or "").split()))}'
diff --git a/meta/classes-recipe/kernel.bbclass b/meta/classes-recipe/kernel.bbclass
index 36ce659762..3dcaebcaed 100644
--- a/meta/classes-recipe/kernel.bbclass
+++ b/meta/classes-recipe/kernel.bbclass
@@ -695,13 +695,14 @@ EXPORT_FUNCTIONS do_compile do_transform_kernel do_transform_bundled_initramfs d
 
 # kernel-base becomes kernel-${KERNEL_VERSION}
 # kernel-image becomes kernel-image-${KERNEL_VERSION}
-PACKAGES = "${KERNEL_PACKAGE_NAME} ${KERNEL_PACKAGE_NAME}-base ${KERNEL_PACKAGE_NAME}-vmlinux ${KERNEL_PACKAGE_NAME}-image ${KERNEL_PACKAGE_NAME}-dev ${KERNEL_PACKAGE_NAME}-modules ${KERNEL_PACKAGE_NAME}-dbg"
+PACKAGES = "${KERNEL_PACKAGE_NAME} ${KERNEL_PACKAGE_NAME}-base ${KERNEL_PACKAGE_NAME}-vmlinux ${KERNEL_PACKAGE_NAME}-image ${KERNEL_PACKAGE_NAME}-dev ${KERNEL_PACKAGE_NAME}-modules ${KERNEL_PACKAGE_NAME}-initrd-modules ${KERNEL_PACKAGE_NAME}-dbg"
 FILES:${PN} = ""
 FILES:${KERNEL_PACKAGE_NAME}-base = "${nonarch_base_libdir}/modules/${KERNEL_VERSION}/modules.order ${nonarch_base_libdir}/modules/${KERNEL_VERSION}/modules.builtin ${nonarch_base_libdir}/modules/${KERNEL_VERSION}/modules.builtin.modinfo"
 FILES:${KERNEL_PACKAGE_NAME}-image = ""
 FILES:${KERNEL_PACKAGE_NAME}-dev = "/${KERNEL_IMAGEDEST}/System.map* /${KERNEL_IMAGEDEST}/Module.symvers* /${KERNEL_IMAGEDEST}/config* ${KERNEL_SRC_PATH} ${nonarch_base_libdir}/modules/${KERNEL_VERSION}/build"
 FILES:${KERNEL_PACKAGE_NAME}-vmlinux = "/${KERNEL_IMAGEDEST}/vmlinux-${KERNEL_VERSION_NAME}"
 FILES:${KERNEL_PACKAGE_NAME}-modules = ""
+FILES:${KERNEL_PACKAGE_NAME}-initrd-modules = ""
 FILES:${KERNEL_PACKAGE_NAME}-dbg = "/usr/lib/debug /usr/src/debug"
 RDEPENDS:${KERNEL_PACKAGE_NAME} = "${KERNEL_PACKAGE_NAME}-base (= ${EXTENDPKGV})"
 # Allow machines to override this dependency if kernel image files are
@@ -716,7 +717,9 @@ ALLOW_EMPTY:${KERNEL_PACKAGE_NAME} = "1"
 ALLOW_EMPTY:${KERNEL_PACKAGE_NAME}-base = "1"
 ALLOW_EMPTY:${KERNEL_PACKAGE_NAME}-image = "1"
 ALLOW_EMPTY:${KERNEL_PACKAGE_NAME}-modules = "1"
+ALLOW_EMPTY:${KERNEL_PACKAGE_NAME}-initrd-modules = "1"
 DESCRIPTION:${KERNEL_PACKAGE_NAME}-modules = "Kernel modules meta package"
+DESCRIPTION:${KERNEL_PACKAGE_NAME}-initrd-modules = "Kernel initrd modules meta package"
 
 pkg_postinst:${KERNEL_PACKAGE_NAME}-base () {
 	if [ ! -e "$D/lib/modules/${KERNEL_VERSION}" ]; then
diff --git a/meta/classes-recipe/module.bbclass b/meta/classes-recipe/module.bbclass
index f2f0b25a2d..51f864f1f9 100644
--- a/meta/classes-recipe/module.bbclass
+++ b/meta/classes-recipe/module.bbclass
@@ -86,3 +86,40 @@ EXPORT_FUNCTIONS do_compile do_install
 KERNEL_MODULES_META_PACKAGE = "${PN}"
 FILES:${PN} = ""
 ALLOW_EMPTY:${PN} = "1"
+
+# subset of kernel modules needed in initrd, to e.g. mount rootfs from block device
+KERNEL_INITRD_MODULES_META_PACKAGE ?= "${@ d.getVar("KERNEL_PACKAGE_NAME") or "kernel" }-initrd-modules"
+
+# match regex to path or file name. E.g. include all drivers with files in path /drivers/ata/
+KERNEL_INITRD_MODULES_REGEX ?= "(.*)(\
+/drivers/acpi/|\
+/drivers/ata/|\
+/drivers/block/|\
+/drivers/cdrom/|\
+/drivers/char/hw_random/|\
+/drivers/char/tpm/|\
+/drivers/char/|\
+/drivers/crypto/|\
+/drivers/dax/|\
+/drivers/firmware/arm_scmi/|\
+/drivers/gpu/drm/|\
+/drivers/md/|\
+/drivers/mmc/|\
+/drivers/mtd/|\
+/drivers/nvdimm/|\
+/drivers/nvme/|\
+/drivers/pci/|\
+/drivers/scsi/|\
+/drivers/tee/|\
+/drivers/tty/serial/|\
+/drivers/virtio/|\
+/drivers/watchdog/|\
+/kernel/arch/|\
+/kernel/block/|\
+/kernel/crypto/|\
+/kernel/fs/|\
+/kernel/lib/\
+)(.*)"
+
+FILES:${PN}-initrd = ""
+ALLOW_EMPTY:${PN}-initrd = "1"
-- 
2.43.0

Re: [OE-core] [PATCH v3 03/11] kernel.bbclass: add kernel-initrd-modules meta package

[Bruce Ashfield]

[-- Attachment #1: Type: text/plain, Size: 10534 bytes --]

On Fri, Apr 4, 2025 at 12:29 PM Mikko Rapeli via lists.openembedded.org
<mikko.rapeli=linaro.org@lists.openembedded.org> wrote:

> At the moment linux-yocto kernels for various architectures
> are not very modular and a lot of drivers are built into the kernel
> even when they are not needed at runtime. These make the main kernel
> binary big and slow to boot. This also impacts udev in userspace
> which takes a long time processing events from all these built in drivers,
> for example when udev runs in initrd.
>
> Then constructing the initrd is very device and kernel configuration
> specific.
> initrd image needs explicitly define which binary packages to install
> to avoid pulling in complex dependencies. A full set of kernel modules
> via kernel-modules meta package is too big for initrd and most of the
> drivers are not needed for use cases like "just load modules to mount
> main rootfs". Then the initrd configuration breaks if kernel driver
> is built into the kernel since the binary package doesn't exist.
>
> Introduce kernel-initrd-modules meta package to solve these problems.
> The meta package adds dependencies to real kernel modules based on
> the kernel module file paths so that it will include several
> kernel subsystems and their drivers which are often needed to find
> main rootfs from some block device. This works when drivers are built
> as modules but does not break if drivers are built into the kernel.
>
> The resulting initrd is also smaller since only a subset of drivers
> are needed for "mount the rootfs" usecase. Tested on genericarm64
> kernel and qemu and AMD KV260 HW.
>
> Signed-off-by: Mikko Rapeli <mikko.rapeli@linaro.org>
> ---
>  .../kernel-module-split.bbclass               | 48 +++++++++++++++++++
>  meta/classes-recipe/kernel.bbclass            |  5 +-
>  meta/classes-recipe/module.bbclass            | 37 ++++++++++++++
>  3 files changed, 89 insertions(+), 1 deletion(-)
>
> diff --git a/meta/classes-recipe/kernel-module-split.bbclass
> b/meta/classes-recipe/kernel-module-split.bbclass
> index 9487365eb7..101c5cd959 100644
> --- a/meta/classes-recipe/kernel-module-split.bbclass
> +++ b/meta/classes-recipe/kernel-module-split.bbclass
> @@ -42,6 +42,40 @@ KERNEL_MODULE_PACKAGE_PREFIX ?= ""
>  KERNEL_MODULE_PACKAGE_SUFFIX ?= "-${KERNEL_VERSION}"
>  KERNEL_MODULE_PROVIDE_VIRTUAL ?= "1"
>
> +# subset of kernel modules needed in initrd, to e.g. mount rootfs from
> block device
> +KERNEL_INITRD_MODULES_META_PACKAGE ?= "${@
> d.getVar("KERNEL_PACKAGE_NAME") or "kernel" }-initrd-modules"
> +
> +# match regex to path or file name. E.g. include all drivers with files
> in path /drivers/ata/
> +KERNEL_INITRD_MODULES_REGEX ?= "(.*)(\
> +/drivers/acpi/|\
> +/drivers/ata/|\
> +/drivers/block/|\
> +/drivers/cdrom/|\
> +/drivers/char/hw_random/|\
> +/drivers/char/tpm/|\
> +/drivers/char/|\
> +/drivers/crypto/|\
> +/drivers/dax/|\
> +/drivers/firmware/arm_scmi/|\
> +/drivers/gpu/drm/|\
> +/drivers/md/|\
> +/drivers/mmc/|\
> +/drivers/mtd/|\
> +/drivers/nvdimm/|\
> +/drivers/nvme/|\
> +/drivers/pci/|\
> +/drivers/scsi/|\
> +/drivers/tee/|\
> +/drivers/tty/serial/|\
> +/drivers/virtio/|\
> +/drivers/watchdog/|\
> +/kernel/arch/|\
> +/kernel/block/|\
> +/kernel/crypto/|\
> +/kernel/fs/|\
> +/kernel/lib/\
> +)(.*)"
> +
>

Apologies for not replying to your reply to my other review, I've had some
unexpected travel
and significant time away from my desk, so I'm running way behind on
everything.

I still don't agree with these values being defined in the base classes.
There's simply too
many kernels and versions out there to make sure this works (and is sane
everywhere)
.. I've lived that for 15 years in supporting the reference kernels.

The reality is that everyone will use the defaults, and never look at them
or otherwise
make sure they are valid for their kernel. We'll end up churning the
values, when really
it is specific to a kernel, a board and even a use case. A kernel recipe is
where all of
those things are explicitly handled, so putting the regex there makes it
very clear that
you need to define something.

There's also still the issue with the repeated set of directories in the
two classes.
To address that, why can't the variable definition be moved to a .inc file ?

With the variables defined in a .inc file, it then becomes very easy for
kernel recipes
to include the .inc and get a default definition .. but we are still
putting the requirement
on them that they explicitly include the file to get the default, versus it
silently being
defined and used in the classes.

Bruce



>  python split_kernel_module_packages () {
>      import re
>
> @@ -183,6 +217,20 @@ python split_kernel_module_packages () {
>      modules = do_split_packages(d, root='${nonarch_base_libdir}/modules',
> file_regex=module_regex, output_pattern=module_pattern, description='%s
> kernel module', postinst=postinst, postrm=postrm, recursive=True,
> hook=frob_metadata, extra_depends='%s-%s' % (kernel_package_name,
> kernel_version))
>      if modules:
>          d.appendVar('RDEPENDS:' + metapkg, ' '+' '.join(modules))
> +
> +    initrd_metapkg = d.getVar('KERNEL_INITRD_MODULES_META_PACKAGE') or ""
> +    initrd_module_regex = d.getVar('KERNEL_INITRD_MODULES_REGEX') or ""
> +    if (initrd_metapkg != "") and (initrd_module_regex != ""):
> +        initrd_module_regex = re.compile(initrd_module_regex)
> +        initrd_modules = []
> +        for module in modules:
> +            files = d.getVar('FILES:' + module)
> +            m = re.match(initrd_module_regex, files)
> +            if m:
> +                initrd_modules.append(module)
> +
> +        if initrd_modules:
> +            d.appendVar('RDEPENDS:' + initrd_metapkg, ' '+'
> '.join(initrd_modules))
>  }
>
>  do_package[vardeps] += '${@" ".join(map(lambda s: "module_conf_" + s,
> (d.getVar("KERNEL_MODULE_PROBECONF") or "").split()))}'
> diff --git a/meta/classes-recipe/kernel.bbclass
> b/meta/classes-recipe/kernel.bbclass
> index 36ce659762..3dcaebcaed 100644
> --- a/meta/classes-recipe/kernel.bbclass
> +++ b/meta/classes-recipe/kernel.bbclass
> @@ -695,13 +695,14 @@ EXPORT_FUNCTIONS do_compile do_transform_kernel
> do_transform_bundled_initramfs d
>
>  # kernel-base becomes kernel-${KERNEL_VERSION}
>  # kernel-image becomes kernel-image-${KERNEL_VERSION}
> -PACKAGES = "${KERNEL_PACKAGE_NAME} ${KERNEL_PACKAGE_NAME}-base
> ${KERNEL_PACKAGE_NAME}-vmlinux ${KERNEL_PACKAGE_NAME}-image
> ${KERNEL_PACKAGE_NAME}-dev ${KERNEL_PACKAGE_NAME}-modules
> ${KERNEL_PACKAGE_NAME}-dbg"
> +PACKAGES = "${KERNEL_PACKAGE_NAME} ${KERNEL_PACKAGE_NAME}-base
> ${KERNEL_PACKAGE_NAME}-vmlinux ${KERNEL_PACKAGE_NAME}-image
> ${KERNEL_PACKAGE_NAME}-dev ${KERNEL_PACKAGE_NAME}-modules
> ${KERNEL_PACKAGE_NAME}-initrd-modules ${KERNEL_PACKAGE_NAME}-dbg"
>  FILES:${PN} = ""
>  FILES:${KERNEL_PACKAGE_NAME}-base =
> "${nonarch_base_libdir}/modules/${KERNEL_VERSION}/modules.order
> ${nonarch_base_libdir}/modules/${KERNEL_VERSION}/modules.builtin
> ${nonarch_base_libdir}/modules/${KERNEL_VERSION}/modules.builtin.modinfo"
>  FILES:${KERNEL_PACKAGE_NAME}-image = ""
>  FILES:${KERNEL_PACKAGE_NAME}-dev = "/${KERNEL_IMAGEDEST}/System.map*
> /${KERNEL_IMAGEDEST}/Module.symvers* /${KERNEL_IMAGEDEST}/config*
> ${KERNEL_SRC_PATH} ${nonarch_base_libdir}/modules/${KERNEL_VERSION}/build"
>  FILES:${KERNEL_PACKAGE_NAME}-vmlinux =
> "/${KERNEL_IMAGEDEST}/vmlinux-${KERNEL_VERSION_NAME}"
>  FILES:${KERNEL_PACKAGE_NAME}-modules = ""
> +FILES:${KERNEL_PACKAGE_NAME}-initrd-modules = ""
>  FILES:${KERNEL_PACKAGE_NAME}-dbg = "/usr/lib/debug /usr/src/debug"
>  RDEPENDS:${KERNEL_PACKAGE_NAME} = "${KERNEL_PACKAGE_NAME}-base (=
> ${EXTENDPKGV})"
>  # Allow machines to override this dependency if kernel image files are
> @@ -716,7 +717,9 @@ ALLOW_EMPTY:${KERNEL_PACKAGE_NAME} = "1"
>  ALLOW_EMPTY:${KERNEL_PACKAGE_NAME}-base = "1"
>  ALLOW_EMPTY:${KERNEL_PACKAGE_NAME}-image = "1"
>  ALLOW_EMPTY:${KERNEL_PACKAGE_NAME}-modules = "1"
> +ALLOW_EMPTY:${KERNEL_PACKAGE_NAME}-initrd-modules = "1"
>  DESCRIPTION:${KERNEL_PACKAGE_NAME}-modules = "Kernel modules meta package"
> +DESCRIPTION:${KERNEL_PACKAGE_NAME}-initrd-modules = "Kernel initrd
> modules meta package"
>
>  pkg_postinst:${KERNEL_PACKAGE_NAME}-base () {
>         if [ ! -e "$D/lib/modules/${KERNEL_VERSION}" ]; then
> diff --git a/meta/classes-recipe/module.bbclass
> b/meta/classes-recipe/module.bbclass
> index f2f0b25a2d..51f864f1f9 100644
> --- a/meta/classes-recipe/module.bbclass
> +++ b/meta/classes-recipe/module.bbclass
> @@ -86,3 +86,40 @@ EXPORT_FUNCTIONS do_compile do_install
>  KERNEL_MODULES_META_PACKAGE = "${PN}"
>  FILES:${PN} = ""
>  ALLOW_EMPTY:${PN} = "1"
> +
> +# subset of kernel modules needed in initrd, to e.g. mount rootfs from
> block device
> +KERNEL_INITRD_MODULES_META_PACKAGE ?= "${@
> d.getVar("KERNEL_PACKAGE_NAME") or "kernel" }-initrd-modules"
> +
> +# match regex to path or file name. E.g. include all drivers with files
> in path /drivers/ata/
> +KERNEL_INITRD_MODULES_REGEX ?= "(.*)(\
> +/drivers/acpi/|\
> +/drivers/ata/|\
> +/drivers/block/|\
> +/drivers/cdrom/|\
> +/drivers/char/hw_random/|\
> +/drivers/char/tpm/|\
> +/drivers/char/|\
> +/drivers/crypto/|\
> +/drivers/dax/|\
> +/drivers/firmware/arm_scmi/|\
> +/drivers/gpu/drm/|\
> +/drivers/md/|\
> +/drivers/mmc/|\
> +/drivers/mtd/|\
> +/drivers/nvdimm/|\
> +/drivers/nvme/|\
> +/drivers/pci/|\
> +/drivers/scsi/|\
> +/drivers/tee/|\
> +/drivers/tty/serial/|\
> +/drivers/virtio/|\
> +/drivers/watchdog/|\
> +/kernel/arch/|\
> +/kernel/block/|\
> +/kernel/crypto/|\
> +/kernel/fs/|\
> +/kernel/lib/\
> +)(.*)"
> +
> +FILES:${PN}-initrd = ""
> +ALLOW_EMPTY:${PN}-initrd = "1"
> --
> 2.43.0
>
>
> -=-=-=-=-=-=-=-=-=-=-=-
> Links: You receive all messages sent to this group.
> View/Reply Online (#214354):
> https://lists.openembedded.org/g/openembedded-core/message/214354
> Mute This Topic: https://lists.openembedded.org/mt/112087526/1050810
> Group Owner: openembedded-core+owner@lists.openembedded.org
> Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [
> bruce.ashfield@gmail.com]
> -=-=-=-=-=-=-=-=-=-=-=-
>
>

-- 
- Thou shalt not follow the NULL pointer, for chaos and madness await thee
at its end
- "Use the force Harry" - Gandalf, Star Trek II

[-- Attachment #2: Type: text/html, Size: 14090 bytes --]

Re: [OE-core] [PATCH v3 03/11] kernel.bbclass: add kernel-initrd-modules meta package

[Richard Purdie]

On Fri, 2025-04-04 at 19:29 +0300, Mikko Rapeli via lists.openembedded.org wrote:
> At the moment linux-yocto kernels for various architectures
> are not very modular and a lot of drivers are built into the kernel
> even when they are not needed at runtime. These make the main kernel
> binary big and slow to boot. This also impacts udev in userspace
> which takes a long time processing events from all these built in drivers,
> for example when udev runs in initrd.
> 
> Then constructing the initrd is very device and kernel configuration specific.
> initrd image needs explicitly define which binary packages to install
> to avoid pulling in complex dependencies. A full set of kernel modules
> via kernel-modules meta package is too big for initrd and most of the
> drivers are not needed for use cases like "just load modules to mount
> main rootfs". Then the initrd configuration breaks if kernel driver
> is built into the kernel since the binary package doesn't exist.
> 
> Introduce kernel-initrd-modules meta package to solve these problems.
> The meta package adds dependencies to real kernel modules based on
> the kernel module file paths so that it will include several
> kernel subsystems and their drivers which are often needed to find
> main rootfs from some block device. This works when drivers are built
> as modules but does not break if drivers are built into the kernel.
> 
> The resulting initrd is also smaller since only a subset of drivers
> are needed for "mount the rootfs" usecase. Tested on genericarm64
> kernel and qemu and AMD KV260 HW.
> 
> Signed-off-by: Mikko Rapeli <mikko.rapeli@linaro.org>
> ---
>  .../kernel-module-split.bbclass               | 48 +++++++++++++++++++
>  meta/classes-recipe/kernel.bbclass            |  5 +-
>  meta/classes-recipe/module.bbclass            | 37 ++++++++++++++
>  3 files changed, 89 insertions(+), 1 deletion(-)
> 
> diff --git a/meta/classes-recipe/kernel-module-split.bbclass b/meta/classes-recipe/kernel-module-split.bbclass
> index 9487365eb7..101c5cd959 100644
> --- a/meta/classes-recipe/kernel-module-split.bbclass
> +++ b/meta/classes-recipe/kernel-module-split.bbclass
> @@ -42,6 +42,40 @@ KERNEL_MODULE_PACKAGE_PREFIX ?= ""
>  KERNEL_MODULE_PACKAGE_SUFFIX ?= "-${KERNEL_VERSION}"
>  KERNEL_MODULE_PROVIDE_VIRTUAL ?= "1"
>  
> +# subset of kernel modules needed in initrd, to e.g. mount rootfs from block device
> +KERNEL_INITRD_MODULES_META_PACKAGE ?= "${@ d.getVar("KERNEL_PACKAGE_NAME") or "kernel" }-initrd-modules"
> +
> +# match regex to path or file name. E.g. include all drivers with files in path /drivers/ata/
> +KERNEL_INITRD_MODULES_REGEX ?= "(.*)(\
> +/drivers/acpi/|\
> +/drivers/ata/|\
> +/drivers/block/|\
> +/drivers/cdrom/|\
> +/drivers/char/hw_random/|\
> +/drivers/char/tpm/|\
> +/drivers/char/|\
> +/drivers/crypto/|\
> +/drivers/dax/|\
> +/drivers/firmware/arm_scmi/|\
> +/drivers/gpu/drm/|\
> +/drivers/md/|\
> +/drivers/mmc/|\
> +/drivers/mtd/|\
> +/drivers/nvdimm/|\
> +/drivers/nvme/|\
> +/drivers/pci/|\
> +/drivers/scsi/|\
> +/drivers/tee/|\
> +/drivers/tty/serial/|\
> +/drivers/virtio/|\
> +/drivers/watchdog/|\
> +/kernel/arch/|\
> +/kernel/block/|\
> +/kernel/crypto/|\
> +/kernel/fs/|\
> +/kernel/lib/\
> +)(.*)"
> +
>  python split_kernel_module_packages () {
>      import re
>  
> @@ -183,6 +217,20 @@ python split_kernel_module_packages () {
>      modules = do_split_packages(d, root='${nonarch_base_libdir}/modules', file_regex=module_regex, output_pattern=module_pattern, description='%s kernel module', postinst=postinst, postrm=postrm, recursive=True, hook=frob_metadata, extra_depends='%s-%s' % (kernel_package_name, kernel_version))
>      if modules:
>          d.appendVar('RDEPENDS:' + metapkg, ' '+' '.join(modules))
> +
> +    initrd_metapkg = d.getVar('KERNEL_INITRD_MODULES_META_PACKAGE') or ""
> +    initrd_module_regex = d.getVar('KERNEL_INITRD_MODULES_REGEX') or ""
> +    if (initrd_metapkg != "") and (initrd_module_regex != ""):
> +        initrd_module_regex = re.compile(initrd_module_regex)
> +        initrd_modules = []
> +        for module in modules:
> +            files = d.getVar('FILES:' + module)
> +            m = re.match(initrd_module_regex, files)
> +            if m:
> +                initrd_modules.append(module)
> +
> +        if initrd_modules:
> +            d.appendVar('RDEPENDS:' + initrd_metapkg, ' '+' '.join(initrd_modules))
>  }
>  
>  do_package[vardeps] += '${@" ".join(map(lambda s: "module_conf_" + s, (d.getVar("KERNEL_MODULE_PROBECONF") or "").split()))}'
> diff --git a/meta/classes-recipe/kernel.bbclass b/meta/classes-recipe/kernel.bbclass
> index 36ce659762..3dcaebcaed 100644
> --- a/meta/classes-recipe/kernel.bbclass
> +++ b/meta/classes-recipe/kernel.bbclass
> @@ -695,13 +695,14 @@ EXPORT_FUNCTIONS do_compile do_transform_kernel do_transform_bundled_initramfs d
>  
>  # kernel-base becomes kernel-${KERNEL_VERSION}
>  # kernel-image becomes kernel-image-${KERNEL_VERSION}
> -PACKAGES = "${KERNEL_PACKAGE_NAME} ${KERNEL_PACKAGE_NAME}-base ${KERNEL_PACKAGE_NAME}-vmlinux ${KERNEL_PACKAGE_NAME}-image ${KERNEL_PACKAGE_NAME}-dev ${KERNEL_PACKAGE_NAME}-modules ${KERNEL_PACKAGE_NAME}-dbg"
> +PACKAGES = "${KERNEL_PACKAGE_NAME} ${KERNEL_PACKAGE_NAME}-base ${KERNEL_PACKAGE_NAME}-vmlinux ${KERNEL_PACKAGE_NAME}-image ${KERNEL_PACKAGE_NAME}-dev ${KERNEL_PACKAGE_NAME}-modules ${KERNEL_PACKAGE_NAME}-initrd-modules ${KERNEL_PACKAGE_NAME}-dbg"
>  FILES:${PN} = ""
>  FILES:${KERNEL_PACKAGE_NAME}-base = "${nonarch_base_libdir}/modules/${KERNEL_VERSION}/modules.order ${nonarch_base_libdir}/modules/${KERNEL_VERSION}/modules.builtin ${nonarch_base_libdir}/modules/${KERNEL_VERSION}/modules.builtin.modinfo"
>  FILES:${KERNEL_PACKAGE_NAME}-image = ""
>  FILES:${KERNEL_PACKAGE_NAME}-dev = "/${KERNEL_IMAGEDEST}/System.map* /${KERNEL_IMAGEDEST}/Module.symvers* /${KERNEL_IMAGEDEST}/config* ${KERNEL_SRC_PATH} ${nonarch_base_libdir}/modules/${KERNEL_VERSION}/build"
>  FILES:${KERNEL_PACKAGE_NAME}-vmlinux = "/${KERNEL_IMAGEDEST}/vmlinux-${KERNEL_VERSION_NAME}"
>  FILES:${KERNEL_PACKAGE_NAME}-modules = ""
> +FILES:${KERNEL_PACKAGE_NAME}-initrd-modules = ""
>  FILES:${KERNEL_PACKAGE_NAME}-dbg = "/usr/lib/debug /usr/src/debug"
>  RDEPENDS:${KERNEL_PACKAGE_NAME} = "${KERNEL_PACKAGE_NAME}-base (= ${EXTENDPKGV})"
>  # Allow machines to override this dependency if kernel image files are
> @@ -716,7 +717,9 @@ ALLOW_EMPTY:${KERNEL_PACKAGE_NAME} = "1"
>  ALLOW_EMPTY:${KERNEL_PACKAGE_NAME}-base = "1"
>  ALLOW_EMPTY:${KERNEL_PACKAGE_NAME}-image = "1"
>  ALLOW_EMPTY:${KERNEL_PACKAGE_NAME}-modules = "1"
> +ALLOW_EMPTY:${KERNEL_PACKAGE_NAME}-initrd-modules = "1"
>  DESCRIPTION:${KERNEL_PACKAGE_NAME}-modules = "Kernel modules meta package"
> +DESCRIPTION:${KERNEL_PACKAGE_NAME}-initrd-modules = "Kernel initrd modules meta package"
>  
>  pkg_postinst:${KERNEL_PACKAGE_NAME}-base () {
>  	if [ ! -e "$D/lib/modules/${KERNEL_VERSION}" ]; then
> diff --git a/meta/classes-recipe/module.bbclass b/meta/classes-recipe/module.bbclass
> index f2f0b25a2d..51f864f1f9 100644
> --- a/meta/classes-recipe/module.bbclass
> +++ b/meta/classes-recipe/module.bbclass
> @@ -86,3 +86,40 @@ EXPORT_FUNCTIONS do_compile do_install
>  KERNEL_MODULES_META_PACKAGE = "${PN}"
>  FILES:${PN} = ""
>  ALLOW_EMPTY:${PN} = "1"
> +
> +# subset of kernel modules needed in initrd, to e.g. mount rootfs from block device
> +KERNEL_INITRD_MODULES_META_PACKAGE ?= "${@ d.getVar("KERNEL_PACKAGE_NAME") or "kernel" }-initrd-modules"
> +
> +# match regex to path or file name. E.g. include all drivers with files in path /drivers/ata/
> +KERNEL_INITRD_MODULES_REGEX ?= "(.*)(\
> +/drivers/acpi/|\
> +/drivers/ata/|\
> +/drivers/block/|\
> +/drivers/cdrom/|\
> +/drivers/char/hw_random/|\
> +/drivers/char/tpm/|\
> +/drivers/char/|\
> +/drivers/crypto/|\
> +/drivers/dax/|\
> +/drivers/firmware/arm_scmi/|\
> +/drivers/gpu/drm/|\
> +/drivers/md/|\
> +/drivers/mmc/|\
> +/drivers/mtd/|\
> +/drivers/nvdimm/|\
> +/drivers/nvme/|\
> +/drivers/pci/|\
> +/drivers/scsi/|\
> +/drivers/tee/|\
> +/drivers/tty/serial/|\
> +/drivers/virtio/|\
> +/drivers/watchdog/|\
> +/kernel/arch/|\
> +/kernel/block/|\
> +/kernel/crypto/|\
> +/kernel/fs/|\
> +/kernel/lib/\
> +)(.*)"
> +
> +FILES:${PN}-initrd = ""
> +ALLOW_EMPTY:${PN}-initrd = "1"

What is the difference between the variable defined in kernel-module-
split.bbclass and this one in module.bbclass? Do we need/want to
separate but seemingly similar definitions?

Cheers,

Richard

Re: [OE-core] [PATCH v3 03/11] kernel.bbclass: add kernel-initrd-modules meta package

[Mikko Rapeli]

Hi,

On Thu, Apr 10, 2025 at 01:42:12PM +0100, Richard Purdie wrote:
> On Fri, 2025-04-04 at 19:29 +0300, Mikko Rapeli via lists.openembedded.org wrote:
> > At the moment linux-yocto kernels for various architectures
> > are not very modular and a lot of drivers are built into the kernel
> > even when they are not needed at runtime. These make the main kernel
> > binary big and slow to boot. This also impacts udev in userspace
> > which takes a long time processing events from all these built in drivers,
> > for example when udev runs in initrd.
> > 
> > Then constructing the initrd is very device and kernel configuration specific.
> > initrd image needs explicitly define which binary packages to install
> > to avoid pulling in complex dependencies. A full set of kernel modules
> > via kernel-modules meta package is too big for initrd and most of the
> > drivers are not needed for use cases like "just load modules to mount
> > main rootfs". Then the initrd configuration breaks if kernel driver
> > is built into the kernel since the binary package doesn't exist.
> > 
> > Introduce kernel-initrd-modules meta package to solve these problems.
> > The meta package adds dependencies to real kernel modules based on
> > the kernel module file paths so that it will include several
> > kernel subsystems and their drivers which are often needed to find
> > main rootfs from some block device. This works when drivers are built
> > as modules but does not break if drivers are built into the kernel.
> > 
> > The resulting initrd is also smaller since only a subset of drivers
> > are needed for "mount the rootfs" usecase. Tested on genericarm64
> > kernel and qemu and AMD KV260 HW.
> > 
> > Signed-off-by: Mikko Rapeli <mikko.rapeli@linaro.org>
> > ---
> > �.../kernel-module-split.bbclass�������������� | 48 +++++++++++++++++++
> > �meta/classes-recipe/kernel.bbclass����������� |� 5 +-
> > �meta/classes-recipe/module.bbclass����������� | 37 ++++++++++++++
> > �3 files changed, 89 insertions(+), 1 deletion(-)
> > 
> > diff --git a/meta/classes-recipe/kernel-module-split.bbclass b/meta/classes-recipe/kernel-module-split.bbclass
> > index 9487365eb7..101c5cd959 100644
> > --- a/meta/classes-recipe/kernel-module-split.bbclass
> > +++ b/meta/classes-recipe/kernel-module-split.bbclass
> > @@ -42,6 +42,40 @@ KERNEL_MODULE_PACKAGE_PREFIX ?= ""
> > �KERNEL_MODULE_PACKAGE_SUFFIX ?= "-${KERNEL_VERSION}"
> > �KERNEL_MODULE_PROVIDE_VIRTUAL ?= "1"
> > �
> > +# subset of kernel modules needed in initrd, to e.g. mount rootfs from block device
> > +KERNEL_INITRD_MODULES_META_PACKAGE ?= "${@ d.getVar("KERNEL_PACKAGE_NAME") or "kernel" }-initrd-modules"
> > +
> > +# match regex to path or file name. E.g. include all drivers with files in path /drivers/ata/
> > +KERNEL_INITRD_MODULES_REGEX ?= "(.*)(\
> > +/drivers/acpi/|\
> > +/drivers/ata/|\
> > +/drivers/block/|\
> > +/drivers/cdrom/|\
> > +/drivers/char/hw_random/|\
> > +/drivers/char/tpm/|\
> > +/drivers/char/|\
> > +/drivers/crypto/|\
> > +/drivers/dax/|\
> > +/drivers/firmware/arm_scmi/|\
> > +/drivers/gpu/drm/|\
> > +/drivers/md/|\
> > +/drivers/mmc/|\
> > +/drivers/mtd/|\
> > +/drivers/nvdimm/|\
> > +/drivers/nvme/|\
> > +/drivers/pci/|\
> > +/drivers/scsi/|\
> > +/drivers/tee/|\
> > +/drivers/tty/serial/|\
> > +/drivers/virtio/|\
> > +/drivers/watchdog/|\
> > +/kernel/arch/|\
> > +/kernel/block/|\
> > +/kernel/crypto/|\
> > +/kernel/fs/|\
> > +/kernel/lib/\
> > +)(.*)"
> > +
> > �python split_kernel_module_packages () {
> > ���� import re
> > �
> > @@ -183,6 +217,20 @@ python split_kernel_module_packages () {
> > ���� modules = do_split_packages(d, root='${nonarch_base_libdir}/modules', file_regex=module_regex, output_pattern=module_pattern, description='%s kernel module', postinst=postinst, postrm=postrm, recursive=True, hook=frob_metadata, extra_depends='%s-%s' % (kernel_package_name, kernel_version))
> > ���� if modules:
> > �������� d.appendVar('RDEPENDS:' + metapkg, ' '+' '.join(modules))
> > +
> > +��� initrd_metapkg = d.getVar('KERNEL_INITRD_MODULES_META_PACKAGE') or ""
> > +��� initrd_module_regex = d.getVar('KERNEL_INITRD_MODULES_REGEX') or ""
> > +��� if (initrd_metapkg != "") and (initrd_module_regex != ""):
> > +������� initrd_module_regex = re.compile(initrd_module_regex)
> > +������� initrd_modules = []
> > +������� for module in modules:
> > +����������� files = d.getVar('FILES:' + module)
> > +����������� m = re.match(initrd_module_regex, files)
> > +����������� if m:
> > +��������������� initrd_modules.append(module)
> > +
> > +������� if initrd_modules:
> > +����������� d.appendVar('RDEPENDS:' + initrd_metapkg, ' '+' '.join(initrd_modules))
> > �}
> > �
> > �do_package[vardeps] += '${@" ".join(map(lambda s: "module_conf_" + s, (d.getVar("KERNEL_MODULE_PROBECONF") or "").split()))}'
> > diff --git a/meta/classes-recipe/kernel.bbclass b/meta/classes-recipe/kernel.bbclass
> > index 36ce659762..3dcaebcaed 100644
> > --- a/meta/classes-recipe/kernel.bbclass
> > +++ b/meta/classes-recipe/kernel.bbclass
> > @@ -695,13 +695,14 @@ EXPORT_FUNCTIONS do_compile do_transform_kernel do_transform_bundled_initramfs d
> > �
> > �# kernel-base becomes kernel-${KERNEL_VERSION}
> > �# kernel-image becomes kernel-image-${KERNEL_VERSION}
> > -PACKAGES = "${KERNEL_PACKAGE_NAME} ${KERNEL_PACKAGE_NAME}-base ${KERNEL_PACKAGE_NAME}-vmlinux ${KERNEL_PACKAGE_NAME}-image ${KERNEL_PACKAGE_NAME}-dev ${KERNEL_PACKAGE_NAME}-modules ${KERNEL_PACKAGE_NAME}-dbg"
> > +PACKAGES = "${KERNEL_PACKAGE_NAME} ${KERNEL_PACKAGE_NAME}-base ${KERNEL_PACKAGE_NAME}-vmlinux ${KERNEL_PACKAGE_NAME}-image ${KERNEL_PACKAGE_NAME}-dev ${KERNEL_PACKAGE_NAME}-modules ${KERNEL_PACKAGE_NAME}-initrd-modules ${KERNEL_PACKAGE_NAME}-dbg"
> > �FILES:${PN} = ""
> > �FILES:${KERNEL_PACKAGE_NAME}-base = "${nonarch_base_libdir}/modules/${KERNEL_VERSION}/modules.order ${nonarch_base_libdir}/modules/${KERNEL_VERSION}/modules.builtin ${nonarch_base_libdir}/modules/${KERNEL_VERSION}/modules.builtin.modinfo"
> > �FILES:${KERNEL_PACKAGE_NAME}-image = ""
> > �FILES:${KERNEL_PACKAGE_NAME}-dev = "/${KERNEL_IMAGEDEST}/System.map* /${KERNEL_IMAGEDEST}/Module.symvers* /${KERNEL_IMAGEDEST}/config* ${KERNEL_SRC_PATH} ${nonarch_base_libdir}/modules/${KERNEL_VERSION}/build"
> > �FILES:${KERNEL_PACKAGE_NAME}-vmlinux = "/${KERNEL_IMAGEDEST}/vmlinux-${KERNEL_VERSION_NAME}"
> > �FILES:${KERNEL_PACKAGE_NAME}-modules = ""
> > +FILES:${KERNEL_PACKAGE_NAME}-initrd-modules = ""
> > �FILES:${KERNEL_PACKAGE_NAME}-dbg = "/usr/lib/debug /usr/src/debug"
> > �RDEPENDS:${KERNEL_PACKAGE_NAME} = "${KERNEL_PACKAGE_NAME}-base (= ${EXTENDPKGV})"
> > �# Allow machines to override this dependency if kernel image files are
> > @@ -716,7 +717,9 @@ ALLOW_EMPTY:${KERNEL_PACKAGE_NAME} = "1"
> > �ALLOW_EMPTY:${KERNEL_PACKAGE_NAME}-base = "1"
> > �ALLOW_EMPTY:${KERNEL_PACKAGE_NAME}-image = "1"
> > �ALLOW_EMPTY:${KERNEL_PACKAGE_NAME}-modules = "1"
> > +ALLOW_EMPTY:${KERNEL_PACKAGE_NAME}-initrd-modules = "1"
> > �DESCRIPTION:${KERNEL_PACKAGE_NAME}-modules = "Kernel modules meta package"
> > +DESCRIPTION:${KERNEL_PACKAGE_NAME}-initrd-modules = "Kernel initrd modules meta package"
> > �
> > �pkg_postinst:${KERNEL_PACKAGE_NAME}-base () {
> > �	if [ ! -e "$D/lib/modules/${KERNEL_VERSION}" ]; then
> > diff --git a/meta/classes-recipe/module.bbclass b/meta/classes-recipe/module.bbclass
> > index f2f0b25a2d..51f864f1f9 100644
> > --- a/meta/classes-recipe/module.bbclass
> > +++ b/meta/classes-recipe/module.bbclass
> > @@ -86,3 +86,40 @@ EXPORT_FUNCTIONS do_compile do_install
> > �KERNEL_MODULES_META_PACKAGE = "${PN}"
> > �FILES:${PN} = ""
> > �ALLOW_EMPTY:${PN} = "1"
> > +
> > +# subset of kernel modules needed in initrd, to e.g. mount rootfs from block device
> > +KERNEL_INITRD_MODULES_META_PACKAGE ?= "${@ d.getVar("KERNEL_PACKAGE_NAME") or "kernel" }-initrd-modules"
> > +
> > +# match regex to path or file name. E.g. include all drivers with files in path /drivers/ata/
> > +KERNEL_INITRD_MODULES_REGEX ?= "(.*)(\
> > +/drivers/acpi/|\
> > +/drivers/ata/|\
> > +/drivers/block/|\
> > +/drivers/cdrom/|\
> > +/drivers/char/hw_random/|\
> > +/drivers/char/tpm/|\
> > +/drivers/char/|\
> > +/drivers/crypto/|\
> > +/drivers/dax/|\
> > +/drivers/firmware/arm_scmi/|\
> > +/drivers/gpu/drm/|\
> > +/drivers/md/|\
> > +/drivers/mmc/|\
> > +/drivers/mtd/|\
> > +/drivers/nvdimm/|\
> > +/drivers/nvme/|\
> > +/drivers/pci/|\
> > +/drivers/scsi/|\
> > +/drivers/tee/|\
> > +/drivers/tty/serial/|\
> > +/drivers/virtio/|\
> > +/drivers/watchdog/|\
> > +/kernel/arch/|\
> > +/kernel/block/|\
> > +/kernel/crypto/|\
> > +/kernel/fs/|\
> > +/kernel/lib/\
> > +)(.*)"
> > +
> > +FILES:${PN}-initrd = ""
> > +ALLOW_EMPTY:${PN}-initrd = "1"
> 
> What is the difference between the variable defined in kernel-module-
> split.bbclass and this one in module.bbclass? Do we need/want to
> separate but seemingly similar definitions?

One is for kernel compilation and in-tree drivers, the other is for
out-of-tree modules.

The "kernel-modules" meta package is handled this way too, with
duplication in both.

Bruce says this should be moved to linux-yocto kernel recipe,
which IMO breaks the use of kernel-initrd-modules for vendor kernel recipes
outside of oe-core. I'd rather support them too to e.g. more easily boot
qemu or run oeqa selftests with qemu.

Cheers,

-Mikko

Re: [OE-core] [PATCH v3 03/11] kernel.bbclass: add kernel-initrd-modules meta package

[Bruce Ashfield]

[-- Attachment #1: Type: text/plain, Size: 11641 bytes --]

On Thu, Apr 10, 2025 at 9:00 AM Mikko Rapeli via lists.openembedded.org
<mikko.rapeli=linaro.org@lists.openembedded.org> wrote:

> Hi,
>
> On Thu, Apr 10, 2025 at 01:42:12PM +0100, Richard Purdie wrote:
> > On Fri, 2025-04-04 at 19:29 +0300, Mikko Rapeli via
> lists.openembedded.org wrote:
> > > At the moment linux-yocto kernels for various architectures
> > > are not very modular and a lot of drivers are built into the kernel
> > > even when they are not needed at runtime. These make the main kernel
> > > binary big and slow to boot. This also impacts udev in userspace
> > > which takes a long time processing events from all these built in
> drivers,
> > > for example when udev runs in initrd.
> > >
> > > Then constructing the initrd is very device and kernel configuration
> specific.
> > > initrd image needs explicitly define which binary packages to install
> > > to avoid pulling in complex dependencies. A full set of kernel modules
> > > via kernel-modules meta package is too big for initrd and most of the
> > > drivers are not needed for use cases like "just load modules to mount
> > > main rootfs". Then the initrd configuration breaks if kernel driver
> > > is built into the kernel since the binary package doesn't exist.
> > >
> > > Introduce kernel-initrd-modules meta package to solve these problems.
> > > The meta package adds dependencies to real kernel modules based on
> > > the kernel module file paths so that it will include several
> > > kernel subsystems and their drivers which are often needed to find
> > > main rootfs from some block device. This works when drivers are built
> > > as modules but does not break if drivers are built into the kernel.
> > >
> > > The resulting initrd is also smaller since only a subset of drivers
> > > are needed for "mount the rootfs" usecase. Tested on genericarm64
> > > kernel and qemu and AMD KV260 HW.
> > >
> > > Signed-off-by: Mikko Rapeli <mikko.rapeli@linaro.org>
> > > ---
> > >  .../kernel-module-split.bbclass               | 48 +++++++++++++++++++
> > >  meta/classes-recipe/kernel.bbclass            |  5 +-
> > >  meta/classes-recipe/module.bbclass            | 37 ++++++++++++++
> > >  3 files changed, 89 insertions(+), 1 deletion(-)
> > >
> > > diff --git a/meta/classes-recipe/kernel-module-split.bbclass
> b/meta/classes-recipe/kernel-module-split.bbclass
> > > index 9487365eb7..101c5cd959 100644
> > > --- a/meta/classes-recipe/kernel-module-split.bbclass
> > > +++ b/meta/classes-recipe/kernel-module-split.bbclass
> > > @@ -42,6 +42,40 @@ KERNEL_MODULE_PACKAGE_PREFIX ?= ""
> > >  KERNEL_MODULE_PACKAGE_SUFFIX ?= "-${KERNEL_VERSION}"
> > >  KERNEL_MODULE_PROVIDE_VIRTUAL ?= "1"
> > >
> > > +# subset of kernel modules needed in initrd, to e.g. mount rootfs
> from block device
> > > +KERNEL_INITRD_MODULES_META_PACKAGE ?= "${@
> d.getVar("KERNEL_PACKAGE_NAME") or "kernel" }-initrd-modules"
> > > +
> > > +# match regex to path or file name. E.g. include all drivers with
> files in path /drivers/ata/
> > > +KERNEL_INITRD_MODULES_REGEX ?= "(.*)(\
> > > +/drivers/acpi/|\
> > > +/drivers/ata/|\
> > > +/drivers/block/|\
> > > +/drivers/cdrom/|\
> > > +/drivers/char/hw_random/|\
> > > +/drivers/char/tpm/|\
> > > +/drivers/char/|\
> > > +/drivers/crypto/|\
> > > +/drivers/dax/|\
> > > +/drivers/firmware/arm_scmi/|\
> > > +/drivers/gpu/drm/|\
> > > +/drivers/md/|\
> > > +/drivers/mmc/|\
> > > +/drivers/mtd/|\
> > > +/drivers/nvdimm/|\
> > > +/drivers/nvme/|\
> > > +/drivers/pci/|\
> > > +/drivers/scsi/|\
> > > +/drivers/tee/|\
> > > +/drivers/tty/serial/|\
> > > +/drivers/virtio/|\
> > > +/drivers/watchdog/|\
> > > +/kernel/arch/|\
> > > +/kernel/block/|\
> > > +/kernel/crypto/|\
> > > +/kernel/fs/|\
> > > +/kernel/lib/\
> > > +)(.*)"
> > > +
> > >  python split_kernel_module_packages () {
> > >      import re
> > >
> > > @@ -183,6 +217,20 @@ python split_kernel_module_packages () {
> > >      modules = do_split_packages(d,
> root='${nonarch_base_libdir}/modules', file_regex=module_regex,
> output_pattern=module_pattern, description='%s kernel module',
> postinst=postinst, postrm=postrm, recursive=True, hook=frob_metadata,
> extra_depends='%s-%s' % (kernel_package_name, kernel_version))
> > >      if modules:
> > >          d.appendVar('RDEPENDS:' + metapkg, ' '+' '.join(modules))
> > > +
> > > +    initrd_metapkg = d.getVar('KERNEL_INITRD_MODULES_META_PACKAGE')
> or ""
> > > +    initrd_module_regex = d.getVar('KERNEL_INITRD_MODULES_REGEX') or
> ""
> > > +    if (initrd_metapkg != "") and (initrd_module_regex != ""):
> > > +        initrd_module_regex = re.compile(initrd_module_regex)
> > > +        initrd_modules = []
> > > +        for module in modules:
> > > +            files = d.getVar('FILES:' + module)
> > > +            m = re.match(initrd_module_regex, files)
> > > +            if m:
> > > +                initrd_modules.append(module)
> > > +
> > > +        if initrd_modules:
> > > +            d.appendVar('RDEPENDS:' + initrd_metapkg, ' '+'
> '.join(initrd_modules))
> > >  }
> > >
> > >  do_package[vardeps] += '${@" ".join(map(lambda s: "module_conf_" + s,
> (d.getVar("KERNEL_MODULE_PROBECONF") or "").split()))}'
> > > diff --git a/meta/classes-recipe/kernel.bbclass
> b/meta/classes-recipe/kernel.bbclass
> > > index 36ce659762..3dcaebcaed 100644
> > > --- a/meta/classes-recipe/kernel.bbclass
> > > +++ b/meta/classes-recipe/kernel.bbclass
> > > @@ -695,13 +695,14 @@ EXPORT_FUNCTIONS do_compile do_transform_kernel
> do_transform_bundled_initramfs d
> > >
> > >  # kernel-base becomes kernel-${KERNEL_VERSION}
> > >  # kernel-image becomes kernel-image-${KERNEL_VERSION}
> > > -PACKAGES = "${KERNEL_PACKAGE_NAME} ${KERNEL_PACKAGE_NAME}-base
> ${KERNEL_PACKAGE_NAME}-vmlinux ${KERNEL_PACKAGE_NAME}-image
> ${KERNEL_PACKAGE_NAME}-dev ${KERNEL_PACKAGE_NAME}-modules
> ${KERNEL_PACKAGE_NAME}-dbg"
> > > +PACKAGES = "${KERNEL_PACKAGE_NAME} ${KERNEL_PACKAGE_NAME}-base
> ${KERNEL_PACKAGE_NAME}-vmlinux ${KERNEL_PACKAGE_NAME}-image
> ${KERNEL_PACKAGE_NAME}-dev ${KERNEL_PACKAGE_NAME}-modules
> ${KERNEL_PACKAGE_NAME}-initrd-modules ${KERNEL_PACKAGE_NAME}-dbg"
> > >  FILES:${PN} = ""
> > >  FILES:${KERNEL_PACKAGE_NAME}-base =
> "${nonarch_base_libdir}/modules/${KERNEL_VERSION}/modules.order
> ${nonarch_base_libdir}/modules/${KERNEL_VERSION}/modules.builtin
> ${nonarch_base_libdir}/modules/${KERNEL_VERSION}/modules.builtin.modinfo"
> > >  FILES:${KERNEL_PACKAGE_NAME}-image = ""
> > >  FILES:${KERNEL_PACKAGE_NAME}-dev = "/${KERNEL_IMAGEDEST}/System.map*
> /${KERNEL_IMAGEDEST}/Module.symvers* /${KERNEL_IMAGEDEST}/config*
> ${KERNEL_SRC_PATH} ${nonarch_base_libdir}/modules/${KERNEL_VERSION}/build"
> > >  FILES:${KERNEL_PACKAGE_NAME}-vmlinux =
> "/${KERNEL_IMAGEDEST}/vmlinux-${KERNEL_VERSION_NAME}"
> > >  FILES:${KERNEL_PACKAGE_NAME}-modules = ""
> > > +FILES:${KERNEL_PACKAGE_NAME}-initrd-modules = ""
> > >  FILES:${KERNEL_PACKAGE_NAME}-dbg = "/usr/lib/debug /usr/src/debug"
> > >  RDEPENDS:${KERNEL_PACKAGE_NAME} = "${KERNEL_PACKAGE_NAME}-base (=
> ${EXTENDPKGV})"
> > >  # Allow machines to override this dependency if kernel image files are
> > > @@ -716,7 +717,9 @@ ALLOW_EMPTY:${KERNEL_PACKAGE_NAME} = "1"
> > >  ALLOW_EMPTY:${KERNEL_PACKAGE_NAME}-base = "1"
> > >  ALLOW_EMPTY:${KERNEL_PACKAGE_NAME}-image = "1"
> > >  ALLOW_EMPTY:${KERNEL_PACKAGE_NAME}-modules = "1"
> > > +ALLOW_EMPTY:${KERNEL_PACKAGE_NAME}-initrd-modules = "1"
> > >  DESCRIPTION:${KERNEL_PACKAGE_NAME}-modules = "Kernel modules meta
> package"
> > > +DESCRIPTION:${KERNEL_PACKAGE_NAME}-initrd-modules = "Kernel initrd
> modules meta package"
> > >
> > >  pkg_postinst:${KERNEL_PACKAGE_NAME}-base () {
> > >     if [ ! -e "$D/lib/modules/${KERNEL_VERSION}" ]; then
> > > diff --git a/meta/classes-recipe/module.bbclass
> b/meta/classes-recipe/module.bbclass
> > > index f2f0b25a2d..51f864f1f9 100644
> > > --- a/meta/classes-recipe/module.bbclass
> > > +++ b/meta/classes-recipe/module.bbclass
> > > @@ -86,3 +86,40 @@ EXPORT_FUNCTIONS do_compile do_install
> > >  KERNEL_MODULES_META_PACKAGE = "${PN}"
> > >  FILES:${PN} = ""
> > >  ALLOW_EMPTY:${PN} = "1"
> > > +
> > > +# subset of kernel modules needed in initrd, to e.g. mount rootfs
> from block device
> > > +KERNEL_INITRD_MODULES_META_PACKAGE ?= "${@
> d.getVar("KERNEL_PACKAGE_NAME") or "kernel" }-initrd-modules"
> > > +
> > > +# match regex to path or file name. E.g. include all drivers with
> files in path /drivers/ata/
> > > +KERNEL_INITRD_MODULES_REGEX ?= "(.*)(\
> > > +/drivers/acpi/|\
> > > +/drivers/ata/|\
> > > +/drivers/block/|\
> > > +/drivers/cdrom/|\
> > > +/drivers/char/hw_random/|\
> > > +/drivers/char/tpm/|\
> > > +/drivers/char/|\
> > > +/drivers/crypto/|\
> > > +/drivers/dax/|\
> > > +/drivers/firmware/arm_scmi/|\
> > > +/drivers/gpu/drm/|\
> > > +/drivers/md/|\
> > > +/drivers/mmc/|\
> > > +/drivers/mtd/|\
> > > +/drivers/nvdimm/|\
> > > +/drivers/nvme/|\
> > > +/drivers/pci/|\
> > > +/drivers/scsi/|\
> > > +/drivers/tee/|\
> > > +/drivers/tty/serial/|\
> > > +/drivers/virtio/|\
> > > +/drivers/watchdog/|\
> > > +/kernel/arch/|\
> > > +/kernel/block/|\
> > > +/kernel/crypto/|\
> > > +/kernel/fs/|\
> > > +/kernel/lib/\
> > > +)(.*)"
> > > +
> > > +FILES:${PN}-initrd = ""
> > > +ALLOW_EMPTY:${PN}-initrd = "1"
> >
> > What is the difference between the variable defined in kernel-module-
> > split.bbclass and this one in module.bbclass? Do we need/want to
> > separate but seemingly similar definitions?
>
> One is for kernel compilation and in-tree drivers, the other is for
> out-of-tree modules.
>
> The "kernel-modules" meta package is handled this way too, with
> duplication in both.
>
> Bruce says this should be moved to linux-yocto kernel recipe,
> which IMO breaks the use of kernel-initrd-modules for vendor kernel recipes
> outside of oe-core. I'd rather support them too to e.g. more easily boot
> qemu or run oeqa selftests with qemu.
>

That's not quite what I said (but it is close), I said it shouldn't be
defined
at the base with no requirement opt-in from a recipe (even if this way
of constructing an initrd with the modules is not the default). It is a (
weak)
binding to specific kernel versions and directory layouts, but it is a
binding
none the less. If it sits at the base in the classes no one will ever look
at
it or even know that it should be considered.

My suggestion was not that it should only be in linux-yocto (but I'd
insist on overriding it or doing it slightly differently in linux-yocto),
I was saying that it I think  that the two definitions are far to similar
and even if there remain two definitions, they should be moved
into a .inc file.

Any kernel recipe that wants to build an initrd like this can opt-in by
including the .inc, and/or creating their own definition.

Bruce



>
> Cheers,
>
> -Mikko
>
> -=-=-=-=-=-=-=-=-=-=-=-
> Links: You receive all messages sent to this group.
> View/Reply Online (#214664):
> https://lists.openembedded.org/g/openembedded-core/message/214664
> Mute This Topic: https://lists.openembedded.org/mt/112087526/1050810
> Group Owner: openembedded-core+owner@lists.openembedded.org
> Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [
> bruce.ashfield@gmail.com]
> -=-=-=-=-=-=-=-=-=-=-=-
>
>

-- 
- Thou shalt not follow the NULL pointer, for chaos and madness await thee
at its end
- "Use the force Harry" - Gandalf, Star Trek II

[-- Attachment #2: Type: text/html, Size: 16357 bytes --]

Re: [OE-core] [PATCH v3 03/11] kernel.bbclass: add kernel-initrd-modules meta package

[Mikko Rapeli]

Hi,

On Thu, Apr 10, 2025 at 09:15:02AM -0400, Bruce Ashfield wrote:
> On Thu, Apr 10, 2025 at 9:00 AM Mikko Rapeli via lists.openembedded.org
> <mikko.rapeli=linaro.org@lists.openembedded.org> wrote:
> 
> > On Thu, Apr 10, 2025 at 01:42:12PM +0100, Richard Purdie wrote:
> > > On Fri, 2025-04-04 at 19:29 +0300, Mikko Rapeli via
> > lists.openembedded.org wrote:
> > > > At the moment linux-yocto kernels for various architectures
> > > > are not very modular and a lot of drivers are built into the kernel
> > > > even when they are not needed at runtime. These make the main kernel
> > > > binary big and slow to boot. This also impacts udev in userspace
> > > > which takes a long time processing events from all these built in
> > drivers,
> > > > for example when udev runs in initrd.
> > > >
> > > > Then constructing the initrd is very device and kernel configuration
> > specific.
> > > > initrd image needs explicitly define which binary packages to install
> > > > to avoid pulling in complex dependencies. A full set of kernel modules
> > > > via kernel-modules meta package is too big for initrd and most of the
> > > > drivers are not needed for use cases like "just load modules to mount
> > > > main rootfs". Then the initrd configuration breaks if kernel driver
> > > > is built into the kernel since the binary package doesn't exist.
> > > >
> > > > Introduce kernel-initrd-modules meta package to solve these problems.
> > > > The meta package adds dependencies to real kernel modules based on
> > > > the kernel module file paths so that it will include several
> > > > kernel subsystems and their drivers which are often needed to find
> > > > main rootfs from some block device. This works when drivers are built
> > > > as modules but does not break if drivers are built into the kernel.
> > > >
> > > > The resulting initrd is also smaller since only a subset of drivers
> > > > are needed for "mount the rootfs" usecase. Tested on genericarm64
> > > > kernel and qemu and AMD KV260 HW.
> > > >
> > > > Signed-off-by: Mikko Rapeli <mikko.rapeli@linaro.org>
> > > > ---
> > > >  .../kernel-module-split.bbclass               | 48 +++++++++++++++++++
> > > >  meta/classes-recipe/kernel.bbclass            |  5 +-
> > > >  meta/classes-recipe/module.bbclass            | 37 ++++++++++++++
> > > >  3 files changed, 89 insertions(+), 1 deletion(-)
> > > >
> > > > diff --git a/meta/classes-recipe/kernel-module-split.bbclass
> > b/meta/classes-recipe/kernel-module-split.bbclass
> > > > index 9487365eb7..101c5cd959 100644
> > > > --- a/meta/classes-recipe/kernel-module-split.bbclass
> > > > +++ b/meta/classes-recipe/kernel-module-split.bbclass
> > > > @@ -42,6 +42,40 @@ KERNEL_MODULE_PACKAGE_PREFIX ?= ""
> > > >  KERNEL_MODULE_PACKAGE_SUFFIX ?= "-${KERNEL_VERSION}"
> > > >  KERNEL_MODULE_PROVIDE_VIRTUAL ?= "1"
> > > >
> > > > +# subset of kernel modules needed in initrd, to e.g. mount rootfs
> > from block device
> > > > +KERNEL_INITRD_MODULES_META_PACKAGE ?= "${@
> > d.getVar("KERNEL_PACKAGE_NAME") or "kernel" }-initrd-modules"
> > > > +
> > > > +# match regex to path or file name. E.g. include all drivers with
> > files in path /drivers/ata/
> > > > +KERNEL_INITRD_MODULES_REGEX ?= "(.*)(\
> > > > +/drivers/acpi/|\
> > > > +/drivers/ata/|\
> > > > +/drivers/block/|\
> > > > +/drivers/cdrom/|\
> > > > +/drivers/char/hw_random/|\
> > > > +/drivers/char/tpm/|\
> > > > +/drivers/char/|\
> > > > +/drivers/crypto/|\
> > > > +/drivers/dax/|\
> > > > +/drivers/firmware/arm_scmi/|\
> > > > +/drivers/gpu/drm/|\
> > > > +/drivers/md/|\
> > > > +/drivers/mmc/|\
> > > > +/drivers/mtd/|\
> > > > +/drivers/nvdimm/|\
> > > > +/drivers/nvme/|\
> > > > +/drivers/pci/|\
> > > > +/drivers/scsi/|\
> > > > +/drivers/tee/|\
> > > > +/drivers/tty/serial/|\
> > > > +/drivers/virtio/|\
> > > > +/drivers/watchdog/|\
> > > > +/kernel/arch/|\
> > > > +/kernel/block/|\
> > > > +/kernel/crypto/|\
> > > > +/kernel/fs/|\
> > > > +/kernel/lib/\
> > > > +)(.*)"
> > > > +
> > > >  python split_kernel_module_packages () {
> > > >      import re
> > > >
> > > > @@ -183,6 +217,20 @@ python split_kernel_module_packages () {
> > > >      modules = do_split_packages(d,
> > root='${nonarch_base_libdir}/modules', file_regex=module_regex,
> > output_pattern=module_pattern, description='%s kernel module',
> > postinst=postinst, postrm=postrm, recursive=True, hook=frob_metadata,
> > extra_depends='%s-%s' % (kernel_package_name, kernel_version))
> > > >      if modules:
> > > >          d.appendVar('RDEPENDS:' + metapkg, ' '+' '.join(modules))
> > > > +
> > > > +    initrd_metapkg = d.getVar('KERNEL_INITRD_MODULES_META_PACKAGE')
> > or ""
> > > > +    initrd_module_regex = d.getVar('KERNEL_INITRD_MODULES_REGEX') or
> > ""
> > > > +    if (initrd_metapkg != "") and (initrd_module_regex != ""):
> > > > +        initrd_module_regex = re.compile(initrd_module_regex)
> > > > +        initrd_modules = []
> > > > +        for module in modules:
> > > > +            files = d.getVar('FILES:' + module)
> > > > +            m = re.match(initrd_module_regex, files)
> > > > +            if m:
> > > > +                initrd_modules.append(module)
> > > > +
> > > > +        if initrd_modules:
> > > > +            d.appendVar('RDEPENDS:' + initrd_metapkg, ' '+'
> > '.join(initrd_modules))
> > > >  }
> > > >
> > > >  do_package[vardeps] += '${@" ".join(map(lambda s: "module_conf_" + s,
> > (d.getVar("KERNEL_MODULE_PROBECONF") or "").split()))}'
> > > > diff --git a/meta/classes-recipe/kernel.bbclass
> > b/meta/classes-recipe/kernel.bbclass
> > > > index 36ce659762..3dcaebcaed 100644
> > > > --- a/meta/classes-recipe/kernel.bbclass
> > > > +++ b/meta/classes-recipe/kernel.bbclass
> > > > @@ -695,13 +695,14 @@ EXPORT_FUNCTIONS do_compile do_transform_kernel
> > do_transform_bundled_initramfs d
> > > >
> > > >  # kernel-base becomes kernel-${KERNEL_VERSION}
> > > >  # kernel-image becomes kernel-image-${KERNEL_VERSION}
> > > > -PACKAGES = "${KERNEL_PACKAGE_NAME} ${KERNEL_PACKAGE_NAME}-base
> > ${KERNEL_PACKAGE_NAME}-vmlinux ${KERNEL_PACKAGE_NAME}-image
> > ${KERNEL_PACKAGE_NAME}-dev ${KERNEL_PACKAGE_NAME}-modules
> > ${KERNEL_PACKAGE_NAME}-dbg"
> > > > +PACKAGES = "${KERNEL_PACKAGE_NAME} ${KERNEL_PACKAGE_NAME}-base
> > ${KERNEL_PACKAGE_NAME}-vmlinux ${KERNEL_PACKAGE_NAME}-image
> > ${KERNEL_PACKAGE_NAME}-dev ${KERNEL_PACKAGE_NAME}-modules
> > ${KERNEL_PACKAGE_NAME}-initrd-modules ${KERNEL_PACKAGE_NAME}-dbg"
> > > >  FILES:${PN} = ""
> > > >  FILES:${KERNEL_PACKAGE_NAME}-base =
> > "${nonarch_base_libdir}/modules/${KERNEL_VERSION}/modules.order
> > ${nonarch_base_libdir}/modules/${KERNEL_VERSION}/modules.builtin
> > ${nonarch_base_libdir}/modules/${KERNEL_VERSION}/modules.builtin.modinfo"
> > > >  FILES:${KERNEL_PACKAGE_NAME}-image = ""
> > > >  FILES:${KERNEL_PACKAGE_NAME}-dev = "/${KERNEL_IMAGEDEST}/System.map*
> > /${KERNEL_IMAGEDEST}/Module.symvers* /${KERNEL_IMAGEDEST}/config*
> > ${KERNEL_SRC_PATH} ${nonarch_base_libdir}/modules/${KERNEL_VERSION}/build"
> > > >  FILES:${KERNEL_PACKAGE_NAME}-vmlinux =
> > "/${KERNEL_IMAGEDEST}/vmlinux-${KERNEL_VERSION_NAME}"
> > > >  FILES:${KERNEL_PACKAGE_NAME}-modules = ""
> > > > +FILES:${KERNEL_PACKAGE_NAME}-initrd-modules = ""
> > > >  FILES:${KERNEL_PACKAGE_NAME}-dbg = "/usr/lib/debug /usr/src/debug"
> > > >  RDEPENDS:${KERNEL_PACKAGE_NAME} = "${KERNEL_PACKAGE_NAME}-base (=
> > ${EXTENDPKGV})"
> > > >  # Allow machines to override this dependency if kernel image files are
> > > > @@ -716,7 +717,9 @@ ALLOW_EMPTY:${KERNEL_PACKAGE_NAME} = "1"
> > > >  ALLOW_EMPTY:${KERNEL_PACKAGE_NAME}-base = "1"
> > > >  ALLOW_EMPTY:${KERNEL_PACKAGE_NAME}-image = "1"
> > > >  ALLOW_EMPTY:${KERNEL_PACKAGE_NAME}-modules = "1"
> > > > +ALLOW_EMPTY:${KERNEL_PACKAGE_NAME}-initrd-modules = "1"
> > > >  DESCRIPTION:${KERNEL_PACKAGE_NAME}-modules = "Kernel modules meta
> > package"
> > > > +DESCRIPTION:${KERNEL_PACKAGE_NAME}-initrd-modules = "Kernel initrd
> > modules meta package"
> > > >
> > > >  pkg_postinst:${KERNEL_PACKAGE_NAME}-base () {
> > > >     if [ ! -e "$D/lib/modules/${KERNEL_VERSION}" ]; then
> > > > diff --git a/meta/classes-recipe/module.bbclass
> > b/meta/classes-recipe/module.bbclass
> > > > index f2f0b25a2d..51f864f1f9 100644
> > > > --- a/meta/classes-recipe/module.bbclass
> > > > +++ b/meta/classes-recipe/module.bbclass
> > > > @@ -86,3 +86,40 @@ EXPORT_FUNCTIONS do_compile do_install
> > > >  KERNEL_MODULES_META_PACKAGE = "${PN}"
> > > >  FILES:${PN} = ""
> > > >  ALLOW_EMPTY:${PN} = "1"
> > > > +
> > > > +# subset of kernel modules needed in initrd, to e.g. mount rootfs
> > from block device
> > > > +KERNEL_INITRD_MODULES_META_PACKAGE ?= "${@
> > d.getVar("KERNEL_PACKAGE_NAME") or "kernel" }-initrd-modules"
> > > > +
> > > > +# match regex to path or file name. E.g. include all drivers with
> > files in path /drivers/ata/
> > > > +KERNEL_INITRD_MODULES_REGEX ?= "(.*)(\
> > > > +/drivers/acpi/|\
> > > > +/drivers/ata/|\
> > > > +/drivers/block/|\
> > > > +/drivers/cdrom/|\
> > > > +/drivers/char/hw_random/|\
> > > > +/drivers/char/tpm/|\
> > > > +/drivers/char/|\
> > > > +/drivers/crypto/|\
> > > > +/drivers/dax/|\
> > > > +/drivers/firmware/arm_scmi/|\
> > > > +/drivers/gpu/drm/|\
> > > > +/drivers/md/|\
> > > > +/drivers/mmc/|\
> > > > +/drivers/mtd/|\
> > > > +/drivers/nvdimm/|\
> > > > +/drivers/nvme/|\
> > > > +/drivers/pci/|\
> > > > +/drivers/scsi/|\
> > > > +/drivers/tee/|\
> > > > +/drivers/tty/serial/|\
> > > > +/drivers/virtio/|\
> > > > +/drivers/watchdog/|\
> > > > +/kernel/arch/|\
> > > > +/kernel/block/|\
> > > > +/kernel/crypto/|\
> > > > +/kernel/fs/|\
> > > > +/kernel/lib/\
> > > > +)(.*)"
> > > > +
> > > > +FILES:${PN}-initrd = ""
> > > > +ALLOW_EMPTY:${PN}-initrd = "1"
> > >
> > > What is the difference between the variable defined in kernel-module-
> > > split.bbclass and this one in module.bbclass? Do we need/want to
> > > separate but seemingly similar definitions?
> >
> > One is for kernel compilation and in-tree drivers, the other is for
> > out-of-tree modules.
> >
> > The "kernel-modules" meta package is handled this way too, with
> > duplication in both.
> >
> > Bruce says this should be moved to linux-yocto kernel recipe,
> > which IMO breaks the use of kernel-initrd-modules for vendor kernel recipes
> > outside of oe-core. I'd rather support them too to e.g. more easily boot
> > qemu or run oeqa selftests with qemu.
> >
> 
> That's not quite what I said (but it is close), I said it shouldn't be
> defined
> at the base with no requirement opt-in from a recipe (even if this way
> of constructing an initrd with the modules is not the default). It is a (
> weak)
> binding to specific kernel versions and directory layouts, but it is a
> binding
> none the less. If it sits at the base in the classes no one will ever look
> at
> it or even know that it should be considered.
> 
> My suggestion was not that it should only be in linux-yocto (but I'd
> insist on overriding it or doing it slightly differently in linux-yocto),
> I was saying that it I think  that the two definitions are far to similar
> and even if there remain two definitions, they should be moved
> into a .inc file.

Actually the duplication is a bug. All duplication in module.bbclass can be
removed since it includes kernel-module-split.bbclass. Both kernel.bbclass and
module.bbclass include kernel-module-split.bbclass. Sorry about this.
I must have stopped half way when moving things there.

Sending v4 with this fixed soon.

> Any kernel recipe that wants to build an initrd like this can opt-in by
> including the .inc, and/or creating their own definition.

This I don't get. I think the kernel.bbclass and module.bbclass should
work out of the box with sane defaults. The kernel recipes can override
and adjust these as they see fit. Yes there is a dependency to some kernel
APIs (kernel module install paths) which can change, but those have been
stable for, over 25 years (as long as I have been compiling kernels)?

For full control, initrd recipe maintainers can define the exact set
of kernel and other binary packages to install which makes the recipe
kernel config and machine specific.

I don't think moving the definitions to a linux-yocto side .inc file
and then using that as basis in non-core kernel recipes is good. The
kernel.bbclass and module.bbclass would not work independently anymore
and require meta/recipes-kernel/linux/ side .inc file for working defaults.
Or should the .inc file live in meta/conf/distro/include?

I think the defaults belong to kernel-module-split.bbclass used by both
kernel and modules bbclasses.

Cheers,

-Mikko

Re: [OE-core] [PATCH v3 03/11] kernel.bbclass: add kernel-initrd-modules meta package

[Bruce Ashfield]

[-- Attachment #1: Type: text/plain, Size: 14465 bytes --]

On Fri, Apr 11, 2025 at 3:48 AM Mikko Rapeli <mikko.rapeli@linaro.org>
wrote:

> Hi,
>
> On Thu, Apr 10, 2025 at 09:15:02AM -0400, Bruce Ashfield wrote:
> > On Thu, Apr 10, 2025 at 9:00 AM Mikko Rapeli via lists.openembedded.org
> > <mikko.rapeli=linaro.org@lists.openembedded.org> wrote:
> >
> > > On Thu, Apr 10, 2025 at 01:42:12PM +0100, Richard Purdie wrote:
> > > > On Fri, 2025-04-04 at 19:29 +0300, Mikko Rapeli via
> > > lists.openembedded.org wrote:
> > > > > At the moment linux-yocto kernels for various architectures
> > > > > are not very modular and a lot of drivers are built into the kernel
> > > > > even when they are not needed at runtime. These make the main
> kernel
> > > > > binary big and slow to boot. This also impacts udev in userspace
> > > > > which takes a long time processing events from all these built in
> > > drivers,
> > > > > for example when udev runs in initrd.
> > > > >
> > > > > Then constructing the initrd is very device and kernel
> configuration
> > > specific.
> > > > > initrd image needs explicitly define which binary packages to
> install
> > > > > to avoid pulling in complex dependencies. A full set of kernel
> modules
> > > > > via kernel-modules meta package is too big for initrd and most of
> the
> > > > > drivers are not needed for use cases like "just load modules to
> mount
> > > > > main rootfs". Then the initrd configuration breaks if kernel driver
> > > > > is built into the kernel since the binary package doesn't exist.
> > > > >
> > > > > Introduce kernel-initrd-modules meta package to solve these
> problems.
> > > > > The meta package adds dependencies to real kernel modules based on
> > > > > the kernel module file paths so that it will include several
> > > > > kernel subsystems and their drivers which are often needed to find
> > > > > main rootfs from some block device. This works when drivers are
> built
> > > > > as modules but does not break if drivers are built into the kernel.
> > > > >
> > > > > The resulting initrd is also smaller since only a subset of drivers
> > > > > are needed for "mount the rootfs" usecase. Tested on genericarm64
> > > > > kernel and qemu and AMD KV260 HW.
> > > > >
> > > > > Signed-off-by: Mikko Rapeli <mikko.rapeli@linaro.org>
> > > > > ---
> > > > >  .../kernel-module-split.bbclass               | 48
> +++++++++++++++++++
> > > > >  meta/classes-recipe/kernel.bbclass            |  5 +-
> > > > >  meta/classes-recipe/module.bbclass            | 37 ++++++++++++++
> > > > >  3 files changed, 89 insertions(+), 1 deletion(-)
> > > > >
> > > > > diff --git a/meta/classes-recipe/kernel-module-split.bbclass
> > > b/meta/classes-recipe/kernel-module-split.bbclass
> > > > > index 9487365eb7..101c5cd959 100644
> > > > > --- a/meta/classes-recipe/kernel-module-split.bbclass
> > > > > +++ b/meta/classes-recipe/kernel-module-split.bbclass
> > > > > @@ -42,6 +42,40 @@ KERNEL_MODULE_PACKAGE_PREFIX ?= ""
> > > > >  KERNEL_MODULE_PACKAGE_SUFFIX ?= "-${KERNEL_VERSION}"
> > > > >  KERNEL_MODULE_PROVIDE_VIRTUAL ?= "1"
> > > > >
> > > > > +# subset of kernel modules needed in initrd, to e.g. mount rootfs
> > > from block device
> > > > > +KERNEL_INITRD_MODULES_META_PACKAGE ?= "${@
> > > d.getVar("KERNEL_PACKAGE_NAME") or "kernel" }-initrd-modules"
> > > > > +
> > > > > +# match regex to path or file name. E.g. include all drivers with
> > > files in path /drivers/ata/
> > > > > +KERNEL_INITRD_MODULES_REGEX ?= "(.*)(\
> > > > > +/drivers/acpi/|\
> > > > > +/drivers/ata/|\
> > > > > +/drivers/block/|\
> > > > > +/drivers/cdrom/|\
> > > > > +/drivers/char/hw_random/|\
> > > > > +/drivers/char/tpm/|\
> > > > > +/drivers/char/|\
> > > > > +/drivers/crypto/|\
> > > > > +/drivers/dax/|\
> > > > > +/drivers/firmware/arm_scmi/|\
> > > > > +/drivers/gpu/drm/|\
> > > > > +/drivers/md/|\
> > > > > +/drivers/mmc/|\
> > > > > +/drivers/mtd/|\
> > > > > +/drivers/nvdimm/|\
> > > > > +/drivers/nvme/|\
> > > > > +/drivers/pci/|\
> > > > > +/drivers/scsi/|\
> > > > > +/drivers/tee/|\
> > > > > +/drivers/tty/serial/|\
> > > > > +/drivers/virtio/|\
> > > > > +/drivers/watchdog/|\
> > > > > +/kernel/arch/|\
> > > > > +/kernel/block/|\
> > > > > +/kernel/crypto/|\
> > > > > +/kernel/fs/|\
> > > > > +/kernel/lib/\
> > > > > +)(.*)"
> > > > > +
> > > > >  python split_kernel_module_packages () {
> > > > >      import re
> > > > >
> > > > > @@ -183,6 +217,20 @@ python split_kernel_module_packages () {
> > > > >      modules = do_split_packages(d,
> > > root='${nonarch_base_libdir}/modules', file_regex=module_regex,
> > > output_pattern=module_pattern, description='%s kernel module',
> > > postinst=postinst, postrm=postrm, recursive=True, hook=frob_metadata,
> > > extra_depends='%s-%s' % (kernel_package_name, kernel_version))
> > > > >      if modules:
> > > > >          d.appendVar('RDEPENDS:' + metapkg, ' '+' '.join(modules))
> > > > > +
> > > > > +    initrd_metapkg =
> d.getVar('KERNEL_INITRD_MODULES_META_PACKAGE')
> > > or ""
> > > > > +    initrd_module_regex = d.getVar('KERNEL_INITRD_MODULES_REGEX')
> or
> > > ""
> > > > > +    if (initrd_metapkg != "") and (initrd_module_regex != ""):
> > > > > +        initrd_module_regex = re.compile(initrd_module_regex)
> > > > > +        initrd_modules = []
> > > > > +        for module in modules:
> > > > > +            files = d.getVar('FILES:' + module)
> > > > > +            m = re.match(initrd_module_regex, files)
> > > > > +            if m:
> > > > > +                initrd_modules.append(module)
> > > > > +
> > > > > +        if initrd_modules:
> > > > > +            d.appendVar('RDEPENDS:' + initrd_metapkg, ' '+'
> > > '.join(initrd_modules))
> > > > >  }
> > > > >
> > > > >  do_package[vardeps] += '${@" ".join(map(lambda s: "module_conf_"
> + s,
> > > (d.getVar("KERNEL_MODULE_PROBECONF") or "").split()))}'
> > > > > diff --git a/meta/classes-recipe/kernel.bbclass
> > > b/meta/classes-recipe/kernel.bbclass
> > > > > index 36ce659762..3dcaebcaed 100644
> > > > > --- a/meta/classes-recipe/kernel.bbclass
> > > > > +++ b/meta/classes-recipe/kernel.bbclass
> > > > > @@ -695,13 +695,14 @@ EXPORT_FUNCTIONS do_compile
> do_transform_kernel
> > > do_transform_bundled_initramfs d
> > > > >
> > > > >  # kernel-base becomes kernel-${KERNEL_VERSION}
> > > > >  # kernel-image becomes kernel-image-${KERNEL_VERSION}
> > > > > -PACKAGES = "${KERNEL_PACKAGE_NAME} ${KERNEL_PACKAGE_NAME}-base
> > > ${KERNEL_PACKAGE_NAME}-vmlinux ${KERNEL_PACKAGE_NAME}-image
> > > ${KERNEL_PACKAGE_NAME}-dev ${KERNEL_PACKAGE_NAME}-modules
> > > ${KERNEL_PACKAGE_NAME}-dbg"
> > > > > +PACKAGES = "${KERNEL_PACKAGE_NAME} ${KERNEL_PACKAGE_NAME}-base
> > > ${KERNEL_PACKAGE_NAME}-vmlinux ${KERNEL_PACKAGE_NAME}-image
> > > ${KERNEL_PACKAGE_NAME}-dev ${KERNEL_PACKAGE_NAME}-modules
> > > ${KERNEL_PACKAGE_NAME}-initrd-modules ${KERNEL_PACKAGE_NAME}-dbg"
> > > > >  FILES:${PN} = ""
> > > > >  FILES:${KERNEL_PACKAGE_NAME}-base =
> > > "${nonarch_base_libdir}/modules/${KERNEL_VERSION}/modules.order
> > > ${nonarch_base_libdir}/modules/${KERNEL_VERSION}/modules.builtin
> > >
> ${nonarch_base_libdir}/modules/${KERNEL_VERSION}/modules.builtin.modinfo"
> > > > >  FILES:${KERNEL_PACKAGE_NAME}-image = ""
> > > > >  FILES:${KERNEL_PACKAGE_NAME}-dev =
> "/${KERNEL_IMAGEDEST}/System.map*
> > > /${KERNEL_IMAGEDEST}/Module.symvers* /${KERNEL_IMAGEDEST}/config*
> > > ${KERNEL_SRC_PATH}
> ${nonarch_base_libdir}/modules/${KERNEL_VERSION}/build"
> > > > >  FILES:${KERNEL_PACKAGE_NAME}-vmlinux =
> > > "/${KERNEL_IMAGEDEST}/vmlinux-${KERNEL_VERSION_NAME}"
> > > > >  FILES:${KERNEL_PACKAGE_NAME}-modules = ""
> > > > > +FILES:${KERNEL_PACKAGE_NAME}-initrd-modules = ""
> > > > >  FILES:${KERNEL_PACKAGE_NAME}-dbg = "/usr/lib/debug /usr/src/debug"
> > > > >  RDEPENDS:${KERNEL_PACKAGE_NAME} = "${KERNEL_PACKAGE_NAME}-base (=
> > > ${EXTENDPKGV})"
> > > > >  # Allow machines to override this dependency if kernel image
> files are
> > > > > @@ -716,7 +717,9 @@ ALLOW_EMPTY:${KERNEL_PACKAGE_NAME} = "1"
> > > > >  ALLOW_EMPTY:${KERNEL_PACKAGE_NAME}-base = "1"
> > > > >  ALLOW_EMPTY:${KERNEL_PACKAGE_NAME}-image = "1"
> > > > >  ALLOW_EMPTY:${KERNEL_PACKAGE_NAME}-modules = "1"
> > > > > +ALLOW_EMPTY:${KERNEL_PACKAGE_NAME}-initrd-modules = "1"
> > > > >  DESCRIPTION:${KERNEL_PACKAGE_NAME}-modules = "Kernel modules meta
> > > package"
> > > > > +DESCRIPTION:${KERNEL_PACKAGE_NAME}-initrd-modules = "Kernel initrd
> > > modules meta package"
> > > > >
> > > > >  pkg_postinst:${KERNEL_PACKAGE_NAME}-base () {
> > > > >     if [ ! -e "$D/lib/modules/${KERNEL_VERSION}" ]; then
> > > > > diff --git a/meta/classes-recipe/module.bbclass
> > > b/meta/classes-recipe/module.bbclass
> > > > > index f2f0b25a2d..51f864f1f9 100644
> > > > > --- a/meta/classes-recipe/module.bbclass
> > > > > +++ b/meta/classes-recipe/module.bbclass
> > > > > @@ -86,3 +86,40 @@ EXPORT_FUNCTIONS do_compile do_install
> > > > >  KERNEL_MODULES_META_PACKAGE = "${PN}"
> > > > >  FILES:${PN} = ""
> > > > >  ALLOW_EMPTY:${PN} = "1"
> > > > > +
> > > > > +# subset of kernel modules needed in initrd, to e.g. mount rootfs
> > > from block device
> > > > > +KERNEL_INITRD_MODULES_META_PACKAGE ?= "${@
> > > d.getVar("KERNEL_PACKAGE_NAME") or "kernel" }-initrd-modules"
> > > > > +
> > > > > +# match regex to path or file name. E.g. include all drivers with
> > > files in path /drivers/ata/
> > > > > +KERNEL_INITRD_MODULES_REGEX ?= "(.*)(\
> > > > > +/drivers/acpi/|\
> > > > > +/drivers/ata/|\
> > > > > +/drivers/block/|\
> > > > > +/drivers/cdrom/|\
> > > > > +/drivers/char/hw_random/|\
> > > > > +/drivers/char/tpm/|\
> > > > > +/drivers/char/|\
> > > > > +/drivers/crypto/|\
> > > > > +/drivers/dax/|\
> > > > > +/drivers/firmware/arm_scmi/|\
> > > > > +/drivers/gpu/drm/|\
> > > > > +/drivers/md/|\
> > > > > +/drivers/mmc/|\
> > > > > +/drivers/mtd/|\
> > > > > +/drivers/nvdimm/|\
> > > > > +/drivers/nvme/|\
> > > > > +/drivers/pci/|\
> > > > > +/drivers/scsi/|\
> > > > > +/drivers/tee/|\
> > > > > +/drivers/tty/serial/|\
> > > > > +/drivers/virtio/|\
> > > > > +/drivers/watchdog/|\
> > > > > +/kernel/arch/|\
> > > > > +/kernel/block/|\
> > > > > +/kernel/crypto/|\
> > > > > +/kernel/fs/|\
> > > > > +/kernel/lib/\
> > > > > +)(.*)"
> > > > > +
> > > > > +FILES:${PN}-initrd = ""
> > > > > +ALLOW_EMPTY:${PN}-initrd = "1"
> > > >
> > > > What is the difference between the variable defined in kernel-module-
> > > > split.bbclass and this one in module.bbclass? Do we need/want to
> > > > separate but seemingly similar definitions?
> > >
> > > One is for kernel compilation and in-tree drivers, the other is for
> > > out-of-tree modules.
> > >
> > > The "kernel-modules" meta package is handled this way too, with
> > > duplication in both.
> > >
> > > Bruce says this should be moved to linux-yocto kernel recipe,
> > > which IMO breaks the use of kernel-initrd-modules for vendor kernel
> recipes
> > > outside of oe-core. I'd rather support them too to e.g. more easily
> boot
> > > qemu or run oeqa selftests with qemu.
> > >
> >
> > That's not quite what I said (but it is close), I said it shouldn't be
> > defined
> > at the base with no requirement opt-in from a recipe (even if this way
> > of constructing an initrd with the modules is not the default). It is a (
> > weak)
> > binding to specific kernel versions and directory layouts, but it is a
> > binding
> > none the less. If it sits at the base in the classes no one will ever
> look
> > at
> > it or even know that it should be considered.
> >
> > My suggestion was not that it should only be in linux-yocto (but I'd
> > insist on overriding it or doing it slightly differently in linux-yocto),
> > I was saying that it I think  that the two definitions are far to similar
> > and even if there remain two definitions, they should be moved
> > into a .inc file.
>
> Actually the duplication is a bug. All duplication in module.bbclass can be
> removed since it includes kernel-module-split.bbclass. Both kernel.bbclass
> and
> module.bbclass include kernel-module-split.bbclass. Sorry about this.
> I must have stopped half way when moving things there.
>
> Sending v4 with this fixed soon.
>
> > Any kernel recipe that wants to build an initrd like this can opt-in by
> > including the .inc, and/or creating their own definition.
>
> This I don't get. I think the kernel.bbclass and module.bbclass should
> work out of the box with sane defaults. The kernel recipes can override
> and adjust these as they see fit. Yes there is a dependency to some kernel
> APIs (kernel module install paths) which can change, but those have been
> stable for, over 25 years (as long as I have been compiling kernels)?
>
> For full control, initrd recipe maintainers can define the exact set
> of kernel and other binary packages to install which makes the recipe
> kernel config and machine specific.
>
> I don't think moving the definitions to a linux-yocto side .inc file
> and then using that as basis in non-core kernel recipes is good. The
> kernel.bbclass and module.bbclass would not work independently anymore
> and require meta/recipes-kernel/linux/ side .inc file for working defaults.
> Or should the .inc file live in meta/conf/distro/include?
>

Let me be clear. I am not saying "linux-yocto" here. I said a ".inc" file.

Put that .inc file in a common directory and call it something like
initrd-kernel-<foo>.inc, recipes include that .inc file to opt into the
behaviour and get the base definition if they want it.

This modular based initrd isn't going to be the default, so it has
to be opt-in anyway. So put the opt-in and the definitions in a .inc
file, a recipe including it, opts-in.

I don't like the directory listings at all, but that's the best way to
not hide them and again, you can't get a general enough set of
definitions in a base class to serve all possible use cases. It needs
to come from top down.

Bruce



>
> I think the defaults belong to kernel-module-split.bbclass used by both
> kernel and modules bbclasses.
>
> Cheers,
>
> -Mikko
>


-- 
- Thou shalt not follow the NULL pointer, for chaos and madness await thee
at its end
- "Use the force Harry" - Gandalf, Star Trek II

[-- Attachment #2: Type: text/html, Size: 20120 bytes --]

Re: [OE-core] [PATCH v3 03/11] kernel.bbclass: add kernel-initrd-modules meta package

[Mikko Rapeli]

Hi,

On Fri, Apr 11, 2025 at 08:52:24AM -0400, Bruce Ashfield wrote:
> On Fri, Apr 11, 2025 at 3:48 AM Mikko Rapeli <mikko.rapeli@linaro.org>
> wrote:
> 
> > Hi,
> >
> > On Thu, Apr 10, 2025 at 09:15:02AM -0400, Bruce Ashfield wrote:
> > > On Thu, Apr 10, 2025 at 9:00 AM Mikko Rapeli via lists.openembedded.org
> > > <mikko.rapeli=linaro.org@lists.openembedded.org> wrote:
> > >
> > > > On Thu, Apr 10, 2025 at 01:42:12PM +0100, Richard Purdie wrote:
> > > > > On Fri, 2025-04-04 at 19:29 +0300, Mikko Rapeli via
> > > > lists.openembedded.org wrote:
> > > > > > At the moment linux-yocto kernels for various architectures
> > > > > > are not very modular and a lot of drivers are built into the kernel
> > > > > > even when they are not needed at runtime. These make the main
> > kernel
> > > > > > binary big and slow to boot. This also impacts udev in userspace
> > > > > > which takes a long time processing events from all these built in
> > > > drivers,
> > > > > > for example when udev runs in initrd.
> > > > > >
> > > > > > Then constructing the initrd is very device and kernel
> > configuration
> > > > specific.
> > > > > > initrd image needs explicitly define which binary packages to
> > install
> > > > > > to avoid pulling in complex dependencies. A full set of kernel
> > modules
> > > > > > via kernel-modules meta package is too big for initrd and most of
> > the
> > > > > > drivers are not needed for use cases like "just load modules to
> > mount
> > > > > > main rootfs". Then the initrd configuration breaks if kernel driver
> > > > > > is built into the kernel since the binary package doesn't exist.
> > > > > >
> > > > > > Introduce kernel-initrd-modules meta package to solve these
> > problems.
> > > > > > The meta package adds dependencies to real kernel modules based on
> > > > > > the kernel module file paths so that it will include several
> > > > > > kernel subsystems and their drivers which are often needed to find
> > > > > > main rootfs from some block device. This works when drivers are
> > built
> > > > > > as modules but does not break if drivers are built into the kernel.
> > > > > >
> > > > > > The resulting initrd is also smaller since only a subset of drivers
> > > > > > are needed for "mount the rootfs" usecase. Tested on genericarm64
> > > > > > kernel and qemu and AMD KV260 HW.
> > > > > >
> > > > > > Signed-off-by: Mikko Rapeli <mikko.rapeli@linaro.org>
> > > > > > ---
> > > > > >  .../kernel-module-split.bbclass               | 48
> > +++++++++++++++++++
> > > > > >  meta/classes-recipe/kernel.bbclass            |  5 +-
> > > > > >  meta/classes-recipe/module.bbclass            | 37 ++++++++++++++
> > > > > >  3 files changed, 89 insertions(+), 1 deletion(-)
> > > > > >
> > > > > > diff --git a/meta/classes-recipe/kernel-module-split.bbclass
> > > > b/meta/classes-recipe/kernel-module-split.bbclass
> > > > > > index 9487365eb7..101c5cd959 100644
> > > > > > --- a/meta/classes-recipe/kernel-module-split.bbclass
> > > > > > +++ b/meta/classes-recipe/kernel-module-split.bbclass
> > > > > > @@ -42,6 +42,40 @@ KERNEL_MODULE_PACKAGE_PREFIX ?= ""
> > > > > >  KERNEL_MODULE_PACKAGE_SUFFIX ?= "-${KERNEL_VERSION}"
> > > > > >  KERNEL_MODULE_PROVIDE_VIRTUAL ?= "1"
> > > > > >
> > > > > > +# subset of kernel modules needed in initrd, to e.g. mount rootfs
> > > > from block device
> > > > > > +KERNEL_INITRD_MODULES_META_PACKAGE ?= "${@
> > > > d.getVar("KERNEL_PACKAGE_NAME") or "kernel" }-initrd-modules"
> > > > > > +
> > > > > > +# match regex to path or file name. E.g. include all drivers with
> > > > files in path /drivers/ata/
> > > > > > +KERNEL_INITRD_MODULES_REGEX ?= "(.*)(\
> > > > > > +/drivers/acpi/|\
> > > > > > +/drivers/ata/|\
> > > > > > +/drivers/block/|\
> > > > > > +/drivers/cdrom/|\
> > > > > > +/drivers/char/hw_random/|\
> > > > > > +/drivers/char/tpm/|\
> > > > > > +/drivers/char/|\
> > > > > > +/drivers/crypto/|\
> > > > > > +/drivers/dax/|\
> > > > > > +/drivers/firmware/arm_scmi/|\
> > > > > > +/drivers/gpu/drm/|\
> > > > > > +/drivers/md/|\
> > > > > > +/drivers/mmc/|\
> > > > > > +/drivers/mtd/|\
> > > > > > +/drivers/nvdimm/|\
> > > > > > +/drivers/nvme/|\
> > > > > > +/drivers/pci/|\
> > > > > > +/drivers/scsi/|\
> > > > > > +/drivers/tee/|\
> > > > > > +/drivers/tty/serial/|\
> > > > > > +/drivers/virtio/|\
> > > > > > +/drivers/watchdog/|\
> > > > > > +/kernel/arch/|\
> > > > > > +/kernel/block/|\
> > > > > > +/kernel/crypto/|\
> > > > > > +/kernel/fs/|\
> > > > > > +/kernel/lib/\
> > > > > > +)(.*)"
> > > > > > +
> > > > > >  python split_kernel_module_packages () {
> > > > > >      import re
> > > > > >
> > > > > > @@ -183,6 +217,20 @@ python split_kernel_module_packages () {
> > > > > >      modules = do_split_packages(d,
> > > > root='${nonarch_base_libdir}/modules', file_regex=module_regex,
> > > > output_pattern=module_pattern, description='%s kernel module',
> > > > postinst=postinst, postrm=postrm, recursive=True, hook=frob_metadata,
> > > > extra_depends='%s-%s' % (kernel_package_name, kernel_version))
> > > > > >      if modules:
> > > > > >          d.appendVar('RDEPENDS:' + metapkg, ' '+' '.join(modules))
> > > > > > +
> > > > > > +    initrd_metapkg =
> > d.getVar('KERNEL_INITRD_MODULES_META_PACKAGE')
> > > > or ""
> > > > > > +    initrd_module_regex = d.getVar('KERNEL_INITRD_MODULES_REGEX')
> > or
> > > > ""
> > > > > > +    if (initrd_metapkg != "") and (initrd_module_regex != ""):
> > > > > > +        initrd_module_regex = re.compile(initrd_module_regex)
> > > > > > +        initrd_modules = []
> > > > > > +        for module in modules:
> > > > > > +            files = d.getVar('FILES:' + module)
> > > > > > +            m = re.match(initrd_module_regex, files)
> > > > > > +            if m:
> > > > > > +                initrd_modules.append(module)
> > > > > > +
> > > > > > +        if initrd_modules:
> > > > > > +            d.appendVar('RDEPENDS:' + initrd_metapkg, ' '+'
> > > > '.join(initrd_modules))
> > > > > >  }
> > > > > >
> > > > > >  do_package[vardeps] += '${@" ".join(map(lambda s: "module_conf_"
> > + s,
> > > > (d.getVar("KERNEL_MODULE_PROBECONF") or "").split()))}'
> > > > > > diff --git a/meta/classes-recipe/kernel.bbclass
> > > > b/meta/classes-recipe/kernel.bbclass
> > > > > > index 36ce659762..3dcaebcaed 100644
> > > > > > --- a/meta/classes-recipe/kernel.bbclass
> > > > > > +++ b/meta/classes-recipe/kernel.bbclass
> > > > > > @@ -695,13 +695,14 @@ EXPORT_FUNCTIONS do_compile
> > do_transform_kernel
> > > > do_transform_bundled_initramfs d
> > > > > >
> > > > > >  # kernel-base becomes kernel-${KERNEL_VERSION}
> > > > > >  # kernel-image becomes kernel-image-${KERNEL_VERSION}
> > > > > > -PACKAGES = "${KERNEL_PACKAGE_NAME} ${KERNEL_PACKAGE_NAME}-base
> > > > ${KERNEL_PACKAGE_NAME}-vmlinux ${KERNEL_PACKAGE_NAME}-image
> > > > ${KERNEL_PACKAGE_NAME}-dev ${KERNEL_PACKAGE_NAME}-modules
> > > > ${KERNEL_PACKAGE_NAME}-dbg"
> > > > > > +PACKAGES = "${KERNEL_PACKAGE_NAME} ${KERNEL_PACKAGE_NAME}-base
> > > > ${KERNEL_PACKAGE_NAME}-vmlinux ${KERNEL_PACKAGE_NAME}-image
> > > > ${KERNEL_PACKAGE_NAME}-dev ${KERNEL_PACKAGE_NAME}-modules
> > > > ${KERNEL_PACKAGE_NAME}-initrd-modules ${KERNEL_PACKAGE_NAME}-dbg"
> > > > > >  FILES:${PN} = ""
> > > > > >  FILES:${KERNEL_PACKAGE_NAME}-base =
> > > > "${nonarch_base_libdir}/modules/${KERNEL_VERSION}/modules.order
> > > > ${nonarch_base_libdir}/modules/${KERNEL_VERSION}/modules.builtin
> > > >
> > ${nonarch_base_libdir}/modules/${KERNEL_VERSION}/modules.builtin.modinfo"
> > > > > >  FILES:${KERNEL_PACKAGE_NAME}-image = ""
> > > > > >  FILES:${KERNEL_PACKAGE_NAME}-dev =
> > "/${KERNEL_IMAGEDEST}/System.map*
> > > > /${KERNEL_IMAGEDEST}/Module.symvers* /${KERNEL_IMAGEDEST}/config*
> > > > ${KERNEL_SRC_PATH}
> > ${nonarch_base_libdir}/modules/${KERNEL_VERSION}/build"
> > > > > >  FILES:${KERNEL_PACKAGE_NAME}-vmlinux =
> > > > "/${KERNEL_IMAGEDEST}/vmlinux-${KERNEL_VERSION_NAME}"
> > > > > >  FILES:${KERNEL_PACKAGE_NAME}-modules = ""
> > > > > > +FILES:${KERNEL_PACKAGE_NAME}-initrd-modules = ""
> > > > > >  FILES:${KERNEL_PACKAGE_NAME}-dbg = "/usr/lib/debug /usr/src/debug"
> > > > > >  RDEPENDS:${KERNEL_PACKAGE_NAME} = "${KERNEL_PACKAGE_NAME}-base (=
> > > > ${EXTENDPKGV})"
> > > > > >  # Allow machines to override this dependency if kernel image
> > files are
> > > > > > @@ -716,7 +717,9 @@ ALLOW_EMPTY:${KERNEL_PACKAGE_NAME} = "1"
> > > > > >  ALLOW_EMPTY:${KERNEL_PACKAGE_NAME}-base = "1"
> > > > > >  ALLOW_EMPTY:${KERNEL_PACKAGE_NAME}-image = "1"
> > > > > >  ALLOW_EMPTY:${KERNEL_PACKAGE_NAME}-modules = "1"
> > > > > > +ALLOW_EMPTY:${KERNEL_PACKAGE_NAME}-initrd-modules = "1"
> > > > > >  DESCRIPTION:${KERNEL_PACKAGE_NAME}-modules = "Kernel modules meta
> > > > package"
> > > > > > +DESCRIPTION:${KERNEL_PACKAGE_NAME}-initrd-modules = "Kernel initrd
> > > > modules meta package"
> > > > > >
> > > > > >  pkg_postinst:${KERNEL_PACKAGE_NAME}-base () {
> > > > > >     if [ ! -e "$D/lib/modules/${KERNEL_VERSION}" ]; then
> > > > > > diff --git a/meta/classes-recipe/module.bbclass
> > > > b/meta/classes-recipe/module.bbclass
> > > > > > index f2f0b25a2d..51f864f1f9 100644
> > > > > > --- a/meta/classes-recipe/module.bbclass
> > > > > > +++ b/meta/classes-recipe/module.bbclass
> > > > > > @@ -86,3 +86,40 @@ EXPORT_FUNCTIONS do_compile do_install
> > > > > >  KERNEL_MODULES_META_PACKAGE = "${PN}"
> > > > > >  FILES:${PN} = ""
> > > > > >  ALLOW_EMPTY:${PN} = "1"
> > > > > > +
> > > > > > +# subset of kernel modules needed in initrd, to e.g. mount rootfs
> > > > from block device
> > > > > > +KERNEL_INITRD_MODULES_META_PACKAGE ?= "${@
> > > > d.getVar("KERNEL_PACKAGE_NAME") or "kernel" }-initrd-modules"
> > > > > > +
> > > > > > +# match regex to path or file name. E.g. include all drivers with
> > > > files in path /drivers/ata/
> > > > > > +KERNEL_INITRD_MODULES_REGEX ?= "(.*)(\
> > > > > > +/drivers/acpi/|\
> > > > > > +/drivers/ata/|\
> > > > > > +/drivers/block/|\
> > > > > > +/drivers/cdrom/|\
> > > > > > +/drivers/char/hw_random/|\
> > > > > > +/drivers/char/tpm/|\
> > > > > > +/drivers/char/|\
> > > > > > +/drivers/crypto/|\
> > > > > > +/drivers/dax/|\
> > > > > > +/drivers/firmware/arm_scmi/|\
> > > > > > +/drivers/gpu/drm/|\
> > > > > > +/drivers/md/|\
> > > > > > +/drivers/mmc/|\
> > > > > > +/drivers/mtd/|\
> > > > > > +/drivers/nvdimm/|\
> > > > > > +/drivers/nvme/|\
> > > > > > +/drivers/pci/|\
> > > > > > +/drivers/scsi/|\
> > > > > > +/drivers/tee/|\
> > > > > > +/drivers/tty/serial/|\
> > > > > > +/drivers/virtio/|\
> > > > > > +/drivers/watchdog/|\
> > > > > > +/kernel/arch/|\
> > > > > > +/kernel/block/|\
> > > > > > +/kernel/crypto/|\
> > > > > > +/kernel/fs/|\
> > > > > > +/kernel/lib/\
> > > > > > +)(.*)"
> > > > > > +
> > > > > > +FILES:${PN}-initrd = ""
> > > > > > +ALLOW_EMPTY:${PN}-initrd = "1"
> > > > >
> > > > > What is the difference between the variable defined in kernel-module-
> > > > > split.bbclass and this one in module.bbclass? Do we need/want to
> > > > > separate but seemingly similar definitions?
> > > >
> > > > One is for kernel compilation and in-tree drivers, the other is for
> > > > out-of-tree modules.
> > > >
> > > > The "kernel-modules" meta package is handled this way too, with
> > > > duplication in both.
> > > >
> > > > Bruce says this should be moved to linux-yocto kernel recipe,
> > > > which IMO breaks the use of kernel-initrd-modules for vendor kernel
> > recipes
> > > > outside of oe-core. I'd rather support them too to e.g. more easily
> > boot
> > > > qemu or run oeqa selftests with qemu.
> > > >
> > >
> > > That's not quite what I said (but it is close), I said it shouldn't be
> > > defined
> > > at the base with no requirement opt-in from a recipe (even if this way
> > > of constructing an initrd with the modules is not the default). It is a (
> > > weak)
> > > binding to specific kernel versions and directory layouts, but it is a
> > > binding
> > > none the less. If it sits at the base in the classes no one will ever
> > look
> > > at
> > > it or even know that it should be considered.
> > >
> > > My suggestion was not that it should only be in linux-yocto (but I'd
> > > insist on overriding it or doing it slightly differently in linux-yocto),
> > > I was saying that it I think  that the two definitions are far to similar
> > > and even if there remain two definitions, they should be moved
> > > into a .inc file.
> >
> > Actually the duplication is a bug. All duplication in module.bbclass can be
> > removed since it includes kernel-module-split.bbclass. Both kernel.bbclass
> > and
> > module.bbclass include kernel-module-split.bbclass. Sorry about this.
> > I must have stopped half way when moving things there.
> >
> > Sending v4 with this fixed soon.
> >
> > > Any kernel recipe that wants to build an initrd like this can opt-in by
> > > including the .inc, and/or creating their own definition.
> >
> > This I don't get. I think the kernel.bbclass and module.bbclass should
> > work out of the box with sane defaults. The kernel recipes can override
> > and adjust these as they see fit. Yes there is a dependency to some kernel
> > APIs (kernel module install paths) which can change, but those have been
> > stable for, over 25 years (as long as I have been compiling kernels)?
> >
> > For full control, initrd recipe maintainers can define the exact set
> > of kernel and other binary packages to install which makes the recipe
> > kernel config and machine specific.
> >
> > I don't think moving the definitions to a linux-yocto side .inc file
> > and then using that as basis in non-core kernel recipes is good. The
> > kernel.bbclass and module.bbclass would not work independently anymore
> > and require meta/recipes-kernel/linux/ side .inc file for working defaults.
> > Or should the .inc file live in meta/conf/distro/include?
> >
> 
> Let me be clear. I am not saying "linux-yocto" here. I said a ".inc" file.
> 
> Put that .inc file in a common directory and call it something like
> initrd-kernel-<foo>.inc, recipes include that .inc file to opt into the
> behaviour and get the base definition if they want it.

Ok I will do this in v5.
 
> This modular based initrd isn't going to be the default, so it has
> to be opt-in anyway. So put the opt-in and the definitions in a .inc
> file, a recipe including it, opts-in.

I think this should be the default on most machines which use
core-image-initramfs-boot in oe-core.

genericarm64, beagleplay etc machines already for install of "kernel-modules"
to all images, including core-image-initramfs-boot:

$ git grep MACHINE_EXTRA_RRECOMMENDS meta/conf/machine meta-yocto-bsp/conf/machine/ | grep kernel-modules
meta-yocto-bsp/conf/machine/beaglebone-yocto.conf:MACHINE_EXTRA_RRECOMMENDS = "kernel-modules"
meta-yocto-bsp/conf/machine/genericarm64.conf:MACHINE_EXTRA_RRECOMMENDS += "kernel-modules"
meta-yocto-bsp/conf/machine/include/genericx86-common.inc:MACHINE_EXTRA_RRECOMMENDS += "kernel-modules linux-firmware"
meta/conf/machine/include/loongarch/qemuloongarch.inc:MACHINE_EXTRA_RRECOMMENDS += " kernel-modules"
meta/conf/machine/include/riscv/qemuriscv.inc:MACHINE_EXTRA_RRECOMMENDS += " kernel-modules"
meta/conf/machine/qemuppc64.conf:MACHINE_EXTRA_RRECOMMENDS += " kernel-modules"

Some qemu machines don't and that causes issues since
initrd is not flexible to boot even slightly different configurations,
like block device emulation moved from scsi to virtio.
This causes issues with oeqa selftests when small kernel or qemuboot
differences break tests.

initrd itself is optional, but in core-image-initramfs-boot I made
including "kernel-initrd-modules" the default. To me this makes sense.

Kernels for different machines can enable drivers as modules or as built-in
but the initrd config stays the same and will mostly just work. I think
this is a good default.

And then "kernel-initrd-modules" are much smaller than "kernel-modules".
Still too big for real products but better than nothing. For
genericarm64 this reduced initrd image size from 200 Mb to 54 Mb.

> I don't like the directory listings at all, but that's the best way to
> not hide them and again, you can't get a general enough set of
> definitions in a base class to serve all possible use cases. It needs
> to come from top down.

Yes, improvements welcome. At least this doesn't break when drivers
change from built-in or as modules and new features added to linux-yocto
configs don't bloat the kernel so much anymore. Like the pmem patches
which just got in. They work as modules.

Cheers,

-Mikko

Re: [OE-core] [PATCH v3 03/11] kernel.bbclass: add kernel-initrd-modules meta package

[Bruce Ashfield]

[-- Attachment #1: Type: text/plain, Size: 21463 bytes --]

On Fri, Apr 11, 2025 at 9:12 AM Mikko Rapeli <mikko.rapeli@linaro.org>
wrote:

> Hi,
>
> On Fri, Apr 11, 2025 at 08:52:24AM -0400, Bruce Ashfield wrote:
> > On Fri, Apr 11, 2025 at 3:48 AM Mikko Rapeli <mikko.rapeli@linaro.org>
> > wrote:
> >
> > > Hi,
> > >
> > > On Thu, Apr 10, 2025 at 09:15:02AM -0400, Bruce Ashfield wrote:
> > > > On Thu, Apr 10, 2025 at 9:00 AM Mikko Rapeli via
> lists.openembedded.org
> > > > <mikko.rapeli=linaro.org@lists.openembedded.org> wrote:
> > > >
> > > > > On Thu, Apr 10, 2025 at 01:42:12PM +0100, Richard Purdie wrote:
> > > > > > On Fri, 2025-04-04 at 19:29 +0300, Mikko Rapeli via
> > > > > lists.openembedded.org wrote:
> > > > > > > At the moment linux-yocto kernels for various architectures
> > > > > > > are not very modular and a lot of drivers are built into the
> kernel
> > > > > > > even when they are not needed at runtime. These make the main
> > > kernel
> > > > > > > binary big and slow to boot. This also impacts udev in
> userspace
> > > > > > > which takes a long time processing events from all these built
> in
> > > > > drivers,
> > > > > > > for example when udev runs in initrd.
> > > > > > >
> > > > > > > Then constructing the initrd is very device and kernel
> > > configuration
> > > > > specific.
> > > > > > > initrd image needs explicitly define which binary packages to
> > > install
> > > > > > > to avoid pulling in complex dependencies. A full set of kernel
> > > modules
> > > > > > > via kernel-modules meta package is too big for initrd and most
> of
> > > the
> > > > > > > drivers are not needed for use cases like "just load modules to
> > > mount
> > > > > > > main rootfs". Then the initrd configuration breaks if kernel
> driver
> > > > > > > is built into the kernel since the binary package doesn't
> exist.
> > > > > > >
> > > > > > > Introduce kernel-initrd-modules meta package to solve these
> > > problems.
> > > > > > > The meta package adds dependencies to real kernel modules
> based on
> > > > > > > the kernel module file paths so that it will include several
> > > > > > > kernel subsystems and their drivers which are often needed to
> find
> > > > > > > main rootfs from some block device. This works when drivers are
> > > built
> > > > > > > as modules but does not break if drivers are built into the
> kernel.
> > > > > > >
> > > > > > > The resulting initrd is also smaller since only a subset of
> drivers
> > > > > > > are needed for "mount the rootfs" usecase. Tested on
> genericarm64
> > > > > > > kernel and qemu and AMD KV260 HW.
> > > > > > >
> > > > > > > Signed-off-by: Mikko Rapeli <mikko.rapeli@linaro.org>
> > > > > > > ---
> > > > > > >  .../kernel-module-split.bbclass               | 48
> > > +++++++++++++++++++
> > > > > > >  meta/classes-recipe/kernel.bbclass            |  5 +-
> > > > > > >  meta/classes-recipe/module.bbclass            | 37
> ++++++++++++++
> > > > > > >  3 files changed, 89 insertions(+), 1 deletion(-)
> > > > > > >
> > > > > > > diff --git a/meta/classes-recipe/kernel-module-split.bbclass
> > > > > b/meta/classes-recipe/kernel-module-split.bbclass
> > > > > > > index 9487365eb7..101c5cd959 100644
> > > > > > > --- a/meta/classes-recipe/kernel-module-split.bbclass
> > > > > > > +++ b/meta/classes-recipe/kernel-module-split.bbclass
> > > > > > > @@ -42,6 +42,40 @@ KERNEL_MODULE_PACKAGE_PREFIX ?= ""
> > > > > > >  KERNEL_MODULE_PACKAGE_SUFFIX ?= "-${KERNEL_VERSION}"
> > > > > > >  KERNEL_MODULE_PROVIDE_VIRTUAL ?= "1"
> > > > > > >
> > > > > > > +# subset of kernel modules needed in initrd, to e.g. mount
> rootfs
> > > > > from block device
> > > > > > > +KERNEL_INITRD_MODULES_META_PACKAGE ?= "${@
> > > > > d.getVar("KERNEL_PACKAGE_NAME") or "kernel" }-initrd-modules"
> > > > > > > +
> > > > > > > +# match regex to path or file name. E.g. include all drivers
> with
> > > > > files in path /drivers/ata/
> > > > > > > +KERNEL_INITRD_MODULES_REGEX ?= "(.*)(\
> > > > > > > +/drivers/acpi/|\
> > > > > > > +/drivers/ata/|\
> > > > > > > +/drivers/block/|\
> > > > > > > +/drivers/cdrom/|\
> > > > > > > +/drivers/char/hw_random/|\
> > > > > > > +/drivers/char/tpm/|\
> > > > > > > +/drivers/char/|\
> > > > > > > +/drivers/crypto/|\
> > > > > > > +/drivers/dax/|\
> > > > > > > +/drivers/firmware/arm_scmi/|\
> > > > > > > +/drivers/gpu/drm/|\
> > > > > > > +/drivers/md/|\
> > > > > > > +/drivers/mmc/|\
> > > > > > > +/drivers/mtd/|\
> > > > > > > +/drivers/nvdimm/|\
> > > > > > > +/drivers/nvme/|\
> > > > > > > +/drivers/pci/|\
> > > > > > > +/drivers/scsi/|\
> > > > > > > +/drivers/tee/|\
> > > > > > > +/drivers/tty/serial/|\
> > > > > > > +/drivers/virtio/|\
> > > > > > > +/drivers/watchdog/|\
> > > > > > > +/kernel/arch/|\
> > > > > > > +/kernel/block/|\
> > > > > > > +/kernel/crypto/|\
> > > > > > > +/kernel/fs/|\
> > > > > > > +/kernel/lib/\
> > > > > > > +)(.*)"
> > > > > > > +
> > > > > > >  python split_kernel_module_packages () {
> > > > > > >      import re
> > > > > > >
> > > > > > > @@ -183,6 +217,20 @@ python split_kernel_module_packages () {
> > > > > > >      modules = do_split_packages(d,
> > > > > root='${nonarch_base_libdir}/modules', file_regex=module_regex,
> > > > > output_pattern=module_pattern, description='%s kernel module',
> > > > > postinst=postinst, postrm=postrm, recursive=True,
> hook=frob_metadata,
> > > > > extra_depends='%s-%s' % (kernel_package_name, kernel_version))
> > > > > > >      if modules:
> > > > > > >          d.appendVar('RDEPENDS:' + metapkg, ' '+'
> '.join(modules))
> > > > > > > +
> > > > > > > +    initrd_metapkg =
> > > d.getVar('KERNEL_INITRD_MODULES_META_PACKAGE')
> > > > > or ""
> > > > > > > +    initrd_module_regex =
> d.getVar('KERNEL_INITRD_MODULES_REGEX')
> > > or
> > > > > ""
> > > > > > > +    if (initrd_metapkg != "") and (initrd_module_regex != ""):
> > > > > > > +        initrd_module_regex = re.compile(initrd_module_regex)
> > > > > > > +        initrd_modules = []
> > > > > > > +        for module in modules:
> > > > > > > +            files = d.getVar('FILES:' + module)
> > > > > > > +            m = re.match(initrd_module_regex, files)
> > > > > > > +            if m:
> > > > > > > +                initrd_modules.append(module)
> > > > > > > +
> > > > > > > +        if initrd_modules:
> > > > > > > +            d.appendVar('RDEPENDS:' + initrd_metapkg, ' '+'
> > > > > '.join(initrd_modules))
> > > > > > >  }
> > > > > > >
> > > > > > >  do_package[vardeps] += '${@" ".join(map(lambda s:
> "module_conf_"
> > > + s,
> > > > > (d.getVar("KERNEL_MODULE_PROBECONF") or "").split()))}'
> > > > > > > diff --git a/meta/classes-recipe/kernel.bbclass
> > > > > b/meta/classes-recipe/kernel.bbclass
> > > > > > > index 36ce659762..3dcaebcaed 100644
> > > > > > > --- a/meta/classes-recipe/kernel.bbclass
> > > > > > > +++ b/meta/classes-recipe/kernel.bbclass
> > > > > > > @@ -695,13 +695,14 @@ EXPORT_FUNCTIONS do_compile
> > > do_transform_kernel
> > > > > do_transform_bundled_initramfs d
> > > > > > >
> > > > > > >  # kernel-base becomes kernel-${KERNEL_VERSION}
> > > > > > >  # kernel-image becomes kernel-image-${KERNEL_VERSION}
> > > > > > > -PACKAGES = "${KERNEL_PACKAGE_NAME} ${KERNEL_PACKAGE_NAME}-base
> > > > > ${KERNEL_PACKAGE_NAME}-vmlinux ${KERNEL_PACKAGE_NAME}-image
> > > > > ${KERNEL_PACKAGE_NAME}-dev ${KERNEL_PACKAGE_NAME}-modules
> > > > > ${KERNEL_PACKAGE_NAME}-dbg"
> > > > > > > +PACKAGES = "${KERNEL_PACKAGE_NAME} ${KERNEL_PACKAGE_NAME}-base
> > > > > ${KERNEL_PACKAGE_NAME}-vmlinux ${KERNEL_PACKAGE_NAME}-image
> > > > > ${KERNEL_PACKAGE_NAME}-dev ${KERNEL_PACKAGE_NAME}-modules
> > > > > ${KERNEL_PACKAGE_NAME}-initrd-modules ${KERNEL_PACKAGE_NAME}-dbg"
> > > > > > >  FILES:${PN} = ""
> > > > > > >  FILES:${KERNEL_PACKAGE_NAME}-base =
> > > > > "${nonarch_base_libdir}/modules/${KERNEL_VERSION}/modules.order
> > > > > ${nonarch_base_libdir}/modules/${KERNEL_VERSION}/modules.builtin
> > > > >
> > >
> ${nonarch_base_libdir}/modules/${KERNEL_VERSION}/modules.builtin.modinfo"
> > > > > > >  FILES:${KERNEL_PACKAGE_NAME}-image = ""
> > > > > > >  FILES:${KERNEL_PACKAGE_NAME}-dev =
> > > "/${KERNEL_IMAGEDEST}/System.map*
> > > > > /${KERNEL_IMAGEDEST}/Module.symvers* /${KERNEL_IMAGEDEST}/config*
> > > > > ${KERNEL_SRC_PATH}
> > > ${nonarch_base_libdir}/modules/${KERNEL_VERSION}/build"
> > > > > > >  FILES:${KERNEL_PACKAGE_NAME}-vmlinux =
> > > > > "/${KERNEL_IMAGEDEST}/vmlinux-${KERNEL_VERSION_NAME}"
> > > > > > >  FILES:${KERNEL_PACKAGE_NAME}-modules = ""
> > > > > > > +FILES:${KERNEL_PACKAGE_NAME}-initrd-modules = ""
> > > > > > >  FILES:${KERNEL_PACKAGE_NAME}-dbg = "/usr/lib/debug
> /usr/src/debug"
> > > > > > >  RDEPENDS:${KERNEL_PACKAGE_NAME} =
> "${KERNEL_PACKAGE_NAME}-base (=
> > > > > ${EXTENDPKGV})"
> > > > > > >  # Allow machines to override this dependency if kernel image
> > > files are
> > > > > > > @@ -716,7 +717,9 @@ ALLOW_EMPTY:${KERNEL_PACKAGE_NAME} = "1"
> > > > > > >  ALLOW_EMPTY:${KERNEL_PACKAGE_NAME}-base = "1"
> > > > > > >  ALLOW_EMPTY:${KERNEL_PACKAGE_NAME}-image = "1"
> > > > > > >  ALLOW_EMPTY:${KERNEL_PACKAGE_NAME}-modules = "1"
> > > > > > > +ALLOW_EMPTY:${KERNEL_PACKAGE_NAME}-initrd-modules = "1"
> > > > > > >  DESCRIPTION:${KERNEL_PACKAGE_NAME}-modules = "Kernel modules
> meta
> > > > > package"
> > > > > > > +DESCRIPTION:${KERNEL_PACKAGE_NAME}-initrd-modules = "Kernel
> initrd
> > > > > modules meta package"
> > > > > > >
> > > > > > >  pkg_postinst:${KERNEL_PACKAGE_NAME}-base () {
> > > > > > >     if [ ! -e "$D/lib/modules/${KERNEL_VERSION}" ]; then
> > > > > > > diff --git a/meta/classes-recipe/module.bbclass
> > > > > b/meta/classes-recipe/module.bbclass
> > > > > > > index f2f0b25a2d..51f864f1f9 100644
> > > > > > > --- a/meta/classes-recipe/module.bbclass
> > > > > > > +++ b/meta/classes-recipe/module.bbclass
> > > > > > > @@ -86,3 +86,40 @@ EXPORT_FUNCTIONS do_compile do_install
> > > > > > >  KERNEL_MODULES_META_PACKAGE = "${PN}"
> > > > > > >  FILES:${PN} = ""
> > > > > > >  ALLOW_EMPTY:${PN} = "1"
> > > > > > > +
> > > > > > > +# subset of kernel modules needed in initrd, to e.g. mount
> rootfs
> > > > > from block device
> > > > > > > +KERNEL_INITRD_MODULES_META_PACKAGE ?= "${@
> > > > > d.getVar("KERNEL_PACKAGE_NAME") or "kernel" }-initrd-modules"
> > > > > > > +
> > > > > > > +# match regex to path or file name. E.g. include all drivers
> with
> > > > > files in path /drivers/ata/
> > > > > > > +KERNEL_INITRD_MODULES_REGEX ?= "(.*)(\
> > > > > > > +/drivers/acpi/|\
> > > > > > > +/drivers/ata/|\
> > > > > > > +/drivers/block/|\
> > > > > > > +/drivers/cdrom/|\
> > > > > > > +/drivers/char/hw_random/|\
> > > > > > > +/drivers/char/tpm/|\
> > > > > > > +/drivers/char/|\
> > > > > > > +/drivers/crypto/|\
> > > > > > > +/drivers/dax/|\
> > > > > > > +/drivers/firmware/arm_scmi/|\
> > > > > > > +/drivers/gpu/drm/|\
> > > > > > > +/drivers/md/|\
> > > > > > > +/drivers/mmc/|\
> > > > > > > +/drivers/mtd/|\
> > > > > > > +/drivers/nvdimm/|\
> > > > > > > +/drivers/nvme/|\
> > > > > > > +/drivers/pci/|\
> > > > > > > +/drivers/scsi/|\
> > > > > > > +/drivers/tee/|\
> > > > > > > +/drivers/tty/serial/|\
> > > > > > > +/drivers/virtio/|\
> > > > > > > +/drivers/watchdog/|\
> > > > > > > +/kernel/arch/|\
> > > > > > > +/kernel/block/|\
> > > > > > > +/kernel/crypto/|\
> > > > > > > +/kernel/fs/|\
> > > > > > > +/kernel/lib/\
> > > > > > > +)(.*)"
> > > > > > > +
> > > > > > > +FILES:${PN}-initrd = ""
> > > > > > > +ALLOW_EMPTY:${PN}-initrd = "1"
> > > > > >
> > > > > > What is the difference between the variable defined in
> kernel-module-
> > > > > > split.bbclass and this one in module.bbclass? Do we need/want to
> > > > > > separate but seemingly similar definitions?
> > > > >
> > > > > One is for kernel compilation and in-tree drivers, the other is for
> > > > > out-of-tree modules.
> > > > >
> > > > > The "kernel-modules" meta package is handled this way too, with
> > > > > duplication in both.
> > > > >
> > > > > Bruce says this should be moved to linux-yocto kernel recipe,
> > > > > which IMO breaks the use of kernel-initrd-modules for vendor kernel
> > > recipes
> > > > > outside of oe-core. I'd rather support them too to e.g. more easily
> > > boot
> > > > > qemu or run oeqa selftests with qemu.
> > > > >
> > > >
> > > > That's not quite what I said (but it is close), I said it shouldn't
> be
> > > > defined
> > > > at the base with no requirement opt-in from a recipe (even if this
> way
> > > > of constructing an initrd with the modules is not the default). It
> is a (
> > > > weak)
> > > > binding to specific kernel versions and directory layouts, but it is
> a
> > > > binding
> > > > none the less. If it sits at the base in the classes no one will ever
> > > look
> > > > at
> > > > it or even know that it should be considered.
> > > >
> > > > My suggestion was not that it should only be in linux-yocto (but I'd
> > > > insist on overriding it or doing it slightly differently in
> linux-yocto),
> > > > I was saying that it I think  that the two definitions are far to
> similar
> > > > and even if there remain two definitions, they should be moved
> > > > into a .inc file.
> > >
> > > Actually the duplication is a bug. All duplication in module.bbclass
> can be
> > > removed since it includes kernel-module-split.bbclass. Both
> kernel.bbclass
> > > and
> > > module.bbclass include kernel-module-split.bbclass. Sorry about this.
> > > I must have stopped half way when moving things there.
> > >
> > > Sending v4 with this fixed soon.
> > >
> > > > Any kernel recipe that wants to build an initrd like this can opt-in
> by
> > > > including the .inc, and/or creating their own definition.
> > >
> > > This I don't get. I think the kernel.bbclass and module.bbclass should
> > > work out of the box with sane defaults. The kernel recipes can override
> > > and adjust these as they see fit. Yes there is a dependency to some
> kernel
> > > APIs (kernel module install paths) which can change, but those have
> been
> > > stable for, over 25 years (as long as I have been compiling kernels)?
> > >
> > > For full control, initrd recipe maintainers can define the exact set
> > > of kernel and other binary packages to install which makes the recipe
> > > kernel config and machine specific.
> > >
> > > I don't think moving the definitions to a linux-yocto side .inc file
> > > and then using that as basis in non-core kernel recipes is good. The
> > > kernel.bbclass and module.bbclass would not work independently anymore
> > > and require meta/recipes-kernel/linux/ side .inc file for working
> defaults.
> > > Or should the .inc file live in meta/conf/distro/include?
> > >
> >
> > Let me be clear. I am not saying "linux-yocto" here. I said a ".inc"
> file.
> >
> > Put that .inc file in a common directory and call it something like
> > initrd-kernel-<foo>.inc, recipes include that .inc file to opt into the
> > behaviour and get the base definition if they want it.
>
> Ok I will do this in v5.
>
> > This modular based initrd isn't going to be the default, so it has
> > to be opt-in anyway. So put the opt-in and the definitions in a .inc
> > file, a recipe including it, opts-in.
>
> I think this should be the default on most machines which use
> core-image-initramfs-boot in oe-core.


I'll disagree on that point, but in the end, it isn't a hill that
is worth climbing (for me). If that's the way the default policy
goes, I'll just roll with it.




>
> genericarm64, beagleplay etc machines already for install of
> "kernel-modules"
> to all images, including core-image-initramfs-boot:
>
> $ git grep MACHINE_EXTRA_RRECOMMENDS meta/conf/machine
> meta-yocto-bsp/conf/machine/ | grep kernel-modules
> meta-yocto-bsp/conf/machine/beaglebone-yocto.conf:MACHINE_EXTRA_RRECOMMENDS
> = "kernel-modules"
> meta-yocto-bsp/conf/machine/genericarm64.conf:MACHINE_EXTRA_RRECOMMENDS +=
> "kernel-modules"
> meta-yocto-bsp/conf/machine/include/genericx86-common.inc:MACHINE_EXTRA_RRECOMMENDS
> += "kernel-modules linux-firmware"
> meta/conf/machine/include/loongarch/qemuloongarch.inc:MACHINE_EXTRA_RRECOMMENDS
> += " kernel-modules"
> meta/conf/machine/include/riscv/qemuriscv.inc:MACHINE_EXTRA_RRECOMMENDS +=
> " kernel-modules"
> meta/conf/machine/qemuppc64.conf:MACHINE_EXTRA_RRECOMMENDS += "
> kernel-modules"
>
>
Right, and that was by design.

The philosophy has been that the kernel provider should understand
and control its configuration (since we are talking about embedded
devices here). Sure, those examples took the simplest path, and that
was their decision / tradeoff.

We package all the modules individually (I'm stating the obvious,
since we all know this) so that they can be individually installed
and required for something that really wants to control the configuration
tightly.

In any machine / BSP that I build, the configuration is on purpose
and if I want to install individual modules, I'll do that, otherwise,
I trust my configuration and take all the modules.

What you have is something in the middle, and why I still think it
needs to be opt-in. BSP creators need to understand their
configuration and tune it. Having something down at the packaging
level pick and choose which modules on their behalf means that
they are relying on something that needs to be discovered and
tweaked (versus the "all of it" or "you chose your own" as it was
before).


> Some qemu machines don't and that causes issues since
> initrd is not flexible to boot even slightly different configurations,
> like block device emulation moved from scsi to virtio.
> This causes issues with oeqa selftests when small kernel or qemuboot
> differences break tests.
>

And we'll continue to do that, as all the boot methods and kernels
need to be tested. But I agree, there are pros and cons to the
various methods.


> initrd itself is optional, but in core-image-initramfs-boot I made
> including "kernel-initrd-modules" the default. To me this makes sense.
>
> Kernels for different machines can enable drivers as modules or as built-in
> but the initrd config stays the same and will mostly just work. I think
> this is a good default.
>
>
It is just that behaviour which is why I'm saying it should be
explicit and opt-in. If they change their configuration it should
be with a direct line of sight to how the various components
consume it.

Preferably not "I have a custom driver, I need it to boot, I'm
now building it as a module" .. and then wondering why it isn't
picked up in the initrd. If they had to opt-in, they'll already be
aware of the mechanism that is selecting their modules over
and above what their kernel configuration dictates.


> And then "kernel-initrd-modules" are much smaller than "kernel-modules".
> Still too big for real products but better than nothing. For
> genericarm64 this reduced initrd image size from 200 Mb to 54 Mb.


Definitely a valid point / improvement. I'm again back to saying it
just has to be explicit. The same way that many (most?) people
don't want or use linux-yocto as production, we have to design
our configurations as something to be opt-in and something that
is clear it needs to be tweaked for production.

We aren't far off in our view on this.  Most of this looks really
good to me, and is a good step forward. I think that our
different point of view is about the breadth of the types of
kernels, machines, boot methods, products, etc, that are built
on top and how to enable this mechanism.


> > I don't like the directory listings at all, but that's the best way to
> > not hide them and again, you can't get a general enough set of
> > definitions in a base class to serve all possible use cases. It needs
> > to come from top down.
>
> Yes, improvements welcome. At least this doesn't break when drivers
> change from built-in or as modules and new features added to linux-yocto
> configs don't bloat the kernel so much anymore. Like the pmem patches
> which just got in. They work as modules.
>
>
I'm still working on this part, but trying to get this release out
the door has my time mostly chewed up.  I'd still like to explore
a way that either the kernel configuration or the packaging of the
modules is how a recipe indicates that something belongs in
this essential module list for the initrd (or whatever else).

Richard: If you are reading this and get this far, is there any way
to add some sort of RPROVIDES to a package that is almost a
wild card ?  I just haven't had time to think it through or experiment.
Rather than the directory listings, if the new initrd kernel module
meta-package could be constructed (or just the image doing the
installs) from something like IMAGE_INSTALL += "kernel-essential-boot-*'
and that RPROVIDES was put into the packages when they were
created .. we'd have the top down control and explicit configuration
I'm looking for.

Bruce



> Cheers,
>
> -Mikko
>


-- 
- Thou shalt not follow the NULL pointer, for chaos and madness await thee
at its end
- "Use the force Harry" - Gandalf, Star Trek II

[-- Attachment #2: Type: text/html, Size: 33232 bytes --]

Re: [OE-core] [PATCH v3 03/11] kernel.bbclass: add kernel-initrd-modules meta package

[Richard Purdie]

On Fri, 2025-04-11 at 09:39 -0400, Bruce Ashfield wrote:
> Richard: If you are reading this and get this far, is there any way
> to add some sort of RPROVIDES to a package that is almost a
> wild card ?  I just haven't had time to think it through or
> experiment.
> Rather than the directory listings, if the new initrd kernel module
> meta-package could be constructed (or just the image doing the
> installs) from something like IMAGE_INSTALL += "kernel-essential-
> boot-*'
> and that RPROVIDES was put into the packages when they were
> created .. we'd have the top down control and explicit configuration
> I'm looking for.

I think the package rprovides would have to be unique but you could do
that with kernel-essential-boot-XXX. Installing globs of packages
doesn't work well at the package manager level but we do have support
for things like the dev/dbg/locale globbing (*-dev and friends) at the
image construction level so that much is possible, albeit for a quite
difference usecase atm.

Cheers,

Richard

Re: [OE-core] [PATCH v3 03/11] kernel.bbclass: add kernel-initrd-modules meta package

[Mikko Rapeli]

Hi,

On Fri, Apr 11, 2025 at 09:39:31AM -0400, Bruce Ashfield wrote:
> On Fri, Apr 11, 2025 at 9:12 AM Mikko Rapeli <mikko.rapeli@linaro.org>
> wrote:
> > On Fri, Apr 11, 2025 at 08:52:24AM -0400, Bruce Ashfield wrote:
> > > On Fri, Apr 11, 2025 at 3:48 AM Mikko Rapeli <mikko.rapeli@linaro.org>
> > > wrote:
> > > > On Thu, Apr 10, 2025 at 09:15:02AM -0400, Bruce Ashfield wrote:
> > > > > On Thu, Apr 10, 2025 at 9:00 AM Mikko Rapeli via
> > lists.openembedded.org
> > > > > <mikko.rapeli=linaro.org@lists.openembedded.org> wrote:
> > > > >
> > > > > > On Thu, Apr 10, 2025 at 01:42:12PM +0100, Richard Purdie wrote:
> > > > > > > On Fri, 2025-04-04 at 19:29 +0300, Mikko Rapeli via
> > > > > > lists.openembedded.org wrote:
> > > > > > > > At the moment linux-yocto kernels for various architectures
> > > > > > > > are not very modular and a lot of drivers are built into the
> > kernel
> > > > > > > > even when they are not needed at runtime. These make the main
> > > > kernel
> > > > > > > > binary big and slow to boot. This also impacts udev in
> > userspace
> > > > > > > > which takes a long time processing events from all these built
> > in
> > > > > > drivers,
> > > > > > > > for example when udev runs in initrd.
> > > > > > > >
> > > > > > > > Then constructing the initrd is very device and kernel
> > > > configuration
> > > > > > specific.
> > > > > > > > initrd image needs explicitly define which binary packages to
> > > > install
> > > > > > > > to avoid pulling in complex dependencies. A full set of kernel
> > > > modules
> > > > > > > > via kernel-modules meta package is too big for initrd and most
> > of
> > > > the
> > > > > > > > drivers are not needed for use cases like "just load modules to
> > > > mount
> > > > > > > > main rootfs". Then the initrd configuration breaks if kernel
> > driver
> > > > > > > > is built into the kernel since the binary package doesn't
> > exist.
> > > > > > > >
> > > > > > > > Introduce kernel-initrd-modules meta package to solve these
> > > > problems.
> > > > > > > > The meta package adds dependencies to real kernel modules
> > based on
> > > > > > > > the kernel module file paths so that it will include several
> > > > > > > > kernel subsystems and their drivers which are often needed to
> > find
> > > > > > > > main rootfs from some block device. This works when drivers are
> > > > built
> > > > > > > > as modules but does not break if drivers are built into the
> > kernel.
> > > > > > > >
> > > > > > > > The resulting initrd is also smaller since only a subset of
> > drivers
> > > > > > > > are needed for "mount the rootfs" usecase. Tested on
> > genericarm64
> > > > > > > > kernel and qemu and AMD KV260 HW.
> > > > > > > >
> > > > > > > > Signed-off-by: Mikko Rapeli <mikko.rapeli@linaro.org>
> > > > > > > > ---
> > > > > > > >  .../kernel-module-split.bbclass               | 48
> > > > +++++++++++++++++++
> > > > > > > >  meta/classes-recipe/kernel.bbclass            |  5 +-
> > > > > > > >  meta/classes-recipe/module.bbclass            | 37
> > ++++++++++++++
> > > > > > > >  3 files changed, 89 insertions(+), 1 deletion(-)
> > > > > > > >
> > > > > > > > diff --git a/meta/classes-recipe/kernel-module-split.bbclass
> > > > > > b/meta/classes-recipe/kernel-module-split.bbclass
> > > > > > > > index 9487365eb7..101c5cd959 100644
> > > > > > > > --- a/meta/classes-recipe/kernel-module-split.bbclass
> > > > > > > > +++ b/meta/classes-recipe/kernel-module-split.bbclass
> > > > > > > > @@ -42,6 +42,40 @@ KERNEL_MODULE_PACKAGE_PREFIX ?= ""
> > > > > > > >  KERNEL_MODULE_PACKAGE_SUFFIX ?= "-${KERNEL_VERSION}"
> > > > > > > >  KERNEL_MODULE_PROVIDE_VIRTUAL ?= "1"
> > > > > > > >
> > > > > > > > +# subset of kernel modules needed in initrd, to e.g. mount
> > rootfs
> > > > > > from block device
> > > > > > > > +KERNEL_INITRD_MODULES_META_PACKAGE ?= "${@
> > > > > > d.getVar("KERNEL_PACKAGE_NAME") or "kernel" }-initrd-modules"
> > > > > > > > +
> > > > > > > > +# match regex to path or file name. E.g. include all drivers
> > with
> > > > > > files in path /drivers/ata/
> > > > > > > > +KERNEL_INITRD_MODULES_REGEX ?= "(.*)(\
> > > > > > > > +/drivers/acpi/|\
> > > > > > > > +/drivers/ata/|\
> > > > > > > > +/drivers/block/|\
> > > > > > > > +/drivers/cdrom/|\
> > > > > > > > +/drivers/char/hw_random/|\
> > > > > > > > +/drivers/char/tpm/|\
> > > > > > > > +/drivers/char/|\
> > > > > > > > +/drivers/crypto/|\
> > > > > > > > +/drivers/dax/|\
> > > > > > > > +/drivers/firmware/arm_scmi/|\
> > > > > > > > +/drivers/gpu/drm/|\
> > > > > > > > +/drivers/md/|\
> > > > > > > > +/drivers/mmc/|\
> > > > > > > > +/drivers/mtd/|\
> > > > > > > > +/drivers/nvdimm/|\
> > > > > > > > +/drivers/nvme/|\
> > > > > > > > +/drivers/pci/|\
> > > > > > > > +/drivers/scsi/|\
> > > > > > > > +/drivers/tee/|\
> > > > > > > > +/drivers/tty/serial/|\
> > > > > > > > +/drivers/virtio/|\
> > > > > > > > +/drivers/watchdog/|\
> > > > > > > > +/kernel/arch/|\
> > > > > > > > +/kernel/block/|\
> > > > > > > > +/kernel/crypto/|\
> > > > > > > > +/kernel/fs/|\
> > > > > > > > +/kernel/lib/\
> > > > > > > > +)(.*)"
> > > > > > > > +
> > > > > > > >  python split_kernel_module_packages () {
> > > > > > > >      import re
> > > > > > > >
> > > > > > > > @@ -183,6 +217,20 @@ python split_kernel_module_packages () {
> > > > > > > >      modules = do_split_packages(d,
> > > > > > root='${nonarch_base_libdir}/modules', file_regex=module_regex,
> > > > > > output_pattern=module_pattern, description='%s kernel module',
> > > > > > postinst=postinst, postrm=postrm, recursive=True,
> > hook=frob_metadata,
> > > > > > extra_depends='%s-%s' % (kernel_package_name, kernel_version))
> > > > > > > >      if modules:
> > > > > > > >          d.appendVar('RDEPENDS:' + metapkg, ' '+'
> > '.join(modules))
> > > > > > > > +
> > > > > > > > +    initrd_metapkg =
> > > > d.getVar('KERNEL_INITRD_MODULES_META_PACKAGE')
> > > > > > or ""
> > > > > > > > +    initrd_module_regex =
> > d.getVar('KERNEL_INITRD_MODULES_REGEX')
> > > > or
> > > > > > ""
> > > > > > > > +    if (initrd_metapkg != "") and (initrd_module_regex != ""):
> > > > > > > > +        initrd_module_regex = re.compile(initrd_module_regex)
> > > > > > > > +        initrd_modules = []
> > > > > > > > +        for module in modules:
> > > > > > > > +            files = d.getVar('FILES:' + module)
> > > > > > > > +            m = re.match(initrd_module_regex, files)
> > > > > > > > +            if m:
> > > > > > > > +                initrd_modules.append(module)
> > > > > > > > +
> > > > > > > > +        if initrd_modules:
> > > > > > > > +            d.appendVar('RDEPENDS:' + initrd_metapkg, ' '+'
> > > > > > '.join(initrd_modules))
> > > > > > > >  }
> > > > > > > >
> > > > > > > >  do_package[vardeps] += '${@" ".join(map(lambda s:
> > "module_conf_"
> > > > + s,
> > > > > > (d.getVar("KERNEL_MODULE_PROBECONF") or "").split()))}'
> > > > > > > > diff --git a/meta/classes-recipe/kernel.bbclass
> > > > > > b/meta/classes-recipe/kernel.bbclass
> > > > > > > > index 36ce659762..3dcaebcaed 100644
> > > > > > > > --- a/meta/classes-recipe/kernel.bbclass
> > > > > > > > +++ b/meta/classes-recipe/kernel.bbclass
> > > > > > > > @@ -695,13 +695,14 @@ EXPORT_FUNCTIONS do_compile
> > > > do_transform_kernel
> > > > > > do_transform_bundled_initramfs d
> > > > > > > >
> > > > > > > >  # kernel-base becomes kernel-${KERNEL_VERSION}
> > > > > > > >  # kernel-image becomes kernel-image-${KERNEL_VERSION}
> > > > > > > > -PACKAGES = "${KERNEL_PACKAGE_NAME} ${KERNEL_PACKAGE_NAME}-base
> > > > > > ${KERNEL_PACKAGE_NAME}-vmlinux ${KERNEL_PACKAGE_NAME}-image
> > > > > > ${KERNEL_PACKAGE_NAME}-dev ${KERNEL_PACKAGE_NAME}-modules
> > > > > > ${KERNEL_PACKAGE_NAME}-dbg"
> > > > > > > > +PACKAGES = "${KERNEL_PACKAGE_NAME} ${KERNEL_PACKAGE_NAME}-base
> > > > > > ${KERNEL_PACKAGE_NAME}-vmlinux ${KERNEL_PACKAGE_NAME}-image
> > > > > > ${KERNEL_PACKAGE_NAME}-dev ${KERNEL_PACKAGE_NAME}-modules
> > > > > > ${KERNEL_PACKAGE_NAME}-initrd-modules ${KERNEL_PACKAGE_NAME}-dbg"
> > > > > > > >  FILES:${PN} = ""
> > > > > > > >  FILES:${KERNEL_PACKAGE_NAME}-base =
> > > > > > "${nonarch_base_libdir}/modules/${KERNEL_VERSION}/modules.order
> > > > > > ${nonarch_base_libdir}/modules/${KERNEL_VERSION}/modules.builtin
> > > > > >
> > > >
> > ${nonarch_base_libdir}/modules/${KERNEL_VERSION}/modules.builtin.modinfo"
> > > > > > > >  FILES:${KERNEL_PACKAGE_NAME}-image = ""
> > > > > > > >  FILES:${KERNEL_PACKAGE_NAME}-dev =
> > > > "/${KERNEL_IMAGEDEST}/System.map*
> > > > > > /${KERNEL_IMAGEDEST}/Module.symvers* /${KERNEL_IMAGEDEST}/config*
> > > > > > ${KERNEL_SRC_PATH}
> > > > ${nonarch_base_libdir}/modules/${KERNEL_VERSION}/build"
> > > > > > > >  FILES:${KERNEL_PACKAGE_NAME}-vmlinux =
> > > > > > "/${KERNEL_IMAGEDEST}/vmlinux-${KERNEL_VERSION_NAME}"
> > > > > > > >  FILES:${KERNEL_PACKAGE_NAME}-modules = ""
> > > > > > > > +FILES:${KERNEL_PACKAGE_NAME}-initrd-modules = ""
> > > > > > > >  FILES:${KERNEL_PACKAGE_NAME}-dbg = "/usr/lib/debug
> > /usr/src/debug"
> > > > > > > >  RDEPENDS:${KERNEL_PACKAGE_NAME} =
> > "${KERNEL_PACKAGE_NAME}-base (=
> > > > > > ${EXTENDPKGV})"
> > > > > > > >  # Allow machines to override this dependency if kernel image
> > > > files are
> > > > > > > > @@ -716,7 +717,9 @@ ALLOW_EMPTY:${KERNEL_PACKAGE_NAME} = "1"
> > > > > > > >  ALLOW_EMPTY:${KERNEL_PACKAGE_NAME}-base = "1"
> > > > > > > >  ALLOW_EMPTY:${KERNEL_PACKAGE_NAME}-image = "1"
> > > > > > > >  ALLOW_EMPTY:${KERNEL_PACKAGE_NAME}-modules = "1"
> > > > > > > > +ALLOW_EMPTY:${KERNEL_PACKAGE_NAME}-initrd-modules = "1"
> > > > > > > >  DESCRIPTION:${KERNEL_PACKAGE_NAME}-modules = "Kernel modules
> > meta
> > > > > > package"
> > > > > > > > +DESCRIPTION:${KERNEL_PACKAGE_NAME}-initrd-modules = "Kernel
> > initrd
> > > > > > modules meta package"
> > > > > > > >
> > > > > > > >  pkg_postinst:${KERNEL_PACKAGE_NAME}-base () {
> > > > > > > >     if [ ! -e "$D/lib/modules/${KERNEL_VERSION}" ]; then
> > > > > > > > diff --git a/meta/classes-recipe/module.bbclass
> > > > > > b/meta/classes-recipe/module.bbclass
> > > > > > > > index f2f0b25a2d..51f864f1f9 100644
> > > > > > > > --- a/meta/classes-recipe/module.bbclass
> > > > > > > > +++ b/meta/classes-recipe/module.bbclass
> > > > > > > > @@ -86,3 +86,40 @@ EXPORT_FUNCTIONS do_compile do_install
> > > > > > > >  KERNEL_MODULES_META_PACKAGE = "${PN}"
> > > > > > > >  FILES:${PN} = ""
> > > > > > > >  ALLOW_EMPTY:${PN} = "1"
> > > > > > > > +
> > > > > > > > +# subset of kernel modules needed in initrd, to e.g. mount
> > rootfs
> > > > > > from block device
> > > > > > > > +KERNEL_INITRD_MODULES_META_PACKAGE ?= "${@
> > > > > > d.getVar("KERNEL_PACKAGE_NAME") or "kernel" }-initrd-modules"
> > > > > > > > +
> > > > > > > > +# match regex to path or file name. E.g. include all drivers
> > with
> > > > > > files in path /drivers/ata/
> > > > > > > > +KERNEL_INITRD_MODULES_REGEX ?= "(.*)(\
> > > > > > > > +/drivers/acpi/|\
> > > > > > > > +/drivers/ata/|\
> > > > > > > > +/drivers/block/|\
> > > > > > > > +/drivers/cdrom/|\
> > > > > > > > +/drivers/char/hw_random/|\
> > > > > > > > +/drivers/char/tpm/|\
> > > > > > > > +/drivers/char/|\
> > > > > > > > +/drivers/crypto/|\
> > > > > > > > +/drivers/dax/|\
> > > > > > > > +/drivers/firmware/arm_scmi/|\
> > > > > > > > +/drivers/gpu/drm/|\
> > > > > > > > +/drivers/md/|\
> > > > > > > > +/drivers/mmc/|\
> > > > > > > > +/drivers/mtd/|\
> > > > > > > > +/drivers/nvdimm/|\
> > > > > > > > +/drivers/nvme/|\
> > > > > > > > +/drivers/pci/|\
> > > > > > > > +/drivers/scsi/|\
> > > > > > > > +/drivers/tee/|\
> > > > > > > > +/drivers/tty/serial/|\
> > > > > > > > +/drivers/virtio/|\
> > > > > > > > +/drivers/watchdog/|\
> > > > > > > > +/kernel/arch/|\
> > > > > > > > +/kernel/block/|\
> > > > > > > > +/kernel/crypto/|\
> > > > > > > > +/kernel/fs/|\
> > > > > > > > +/kernel/lib/\
> > > > > > > > +)(.*)"
> > > > > > > > +
> > > > > > > > +FILES:${PN}-initrd = ""
> > > > > > > > +ALLOW_EMPTY:${PN}-initrd = "1"
> > > > > > >
> > > > > > > What is the difference between the variable defined in
> > kernel-module-
> > > > > > > split.bbclass and this one in module.bbclass? Do we need/want to
> > > > > > > separate but seemingly similar definitions?
> > > > > >
> > > > > > One is for kernel compilation and in-tree drivers, the other is for
> > > > > > out-of-tree modules.
> > > > > >
> > > > > > The "kernel-modules" meta package is handled this way too, with
> > > > > > duplication in both.
> > > > > >
> > > > > > Bruce says this should be moved to linux-yocto kernel recipe,
> > > > > > which IMO breaks the use of kernel-initrd-modules for vendor kernel
> > > > recipes
> > > > > > outside of oe-core. I'd rather support them too to e.g. more easily
> > > > boot
> > > > > > qemu or run oeqa selftests with qemu.
> > > > > >
> > > > >
> > > > > That's not quite what I said (but it is close), I said it shouldn't
> > be
> > > > > defined
> > > > > at the base with no requirement opt-in from a recipe (even if this
> > way
> > > > > of constructing an initrd with the modules is not the default). It
> > is a (
> > > > > weak)
> > > > > binding to specific kernel versions and directory layouts, but it is
> > a
> > > > > binding
> > > > > none the less. If it sits at the base in the classes no one will ever
> > > > look
> > > > > at
> > > > > it or even know that it should be considered.
> > > > >
> > > > > My suggestion was not that it should only be in linux-yocto (but I'd
> > > > > insist on overriding it or doing it slightly differently in
> > linux-yocto),
> > > > > I was saying that it I think  that the two definitions are far to
> > similar
> > > > > and even if there remain two definitions, they should be moved
> > > > > into a .inc file.
> > > >
> > > > Actually the duplication is a bug. All duplication in module.bbclass
> > can be
> > > > removed since it includes kernel-module-split.bbclass. Both
> > kernel.bbclass
> > > > and
> > > > module.bbclass include kernel-module-split.bbclass. Sorry about this.
> > > > I must have stopped half way when moving things there.
> > > >
> > > > Sending v4 with this fixed soon.
> > > >
> > > > > Any kernel recipe that wants to build an initrd like this can opt-in
> > by
> > > > > including the .inc, and/or creating their own definition.
> > > >
> > > > This I don't get. I think the kernel.bbclass and module.bbclass should
> > > > work out of the box with sane defaults. The kernel recipes can override
> > > > and adjust these as they see fit. Yes there is a dependency to some
> > kernel
> > > > APIs (kernel module install paths) which can change, but those have
> > been
> > > > stable for, over 25 years (as long as I have been compiling kernels)?
> > > >
> > > > For full control, initrd recipe maintainers can define the exact set
> > > > of kernel and other binary packages to install which makes the recipe
> > > > kernel config and machine specific.
> > > >
> > > > I don't think moving the definitions to a linux-yocto side .inc file
> > > > and then using that as basis in non-core kernel recipes is good. The
> > > > kernel.bbclass and module.bbclass would not work independently anymore
> > > > and require meta/recipes-kernel/linux/ side .inc file for working
> > defaults.
> > > > Or should the .inc file live in meta/conf/distro/include?
> > > >
> > >
> > > Let me be clear. I am not saying "linux-yocto" here. I said a ".inc"
> > file.
> > >
> > > Put that .inc file in a common directory and call it something like
> > > initrd-kernel-<foo>.inc, recipes include that .inc file to opt into the
> > > behaviour and get the base definition if they want it.
> >
> > Ok I will do this in v5.
> >
> > > This modular based initrd isn't going to be the default, so it has
> > > to be opt-in anyway. So put the opt-in and the definitions in a .inc
> > > file, a recipe including it, opts-in.
> >
> > I think this should be the default on most machines which use
> > core-image-initramfs-boot in oe-core.
> 
> 
> I'll disagree on that point, but in the end, it isn't a hill that
> is worth climbing (for me). If that's the way the default policy
> goes, I'll just roll with it.
> 
> > genericarm64, beagleplay etc machines already for install of
> > "kernel-modules"
> > to all images, including core-image-initramfs-boot:
> >
> > $ git grep MACHINE_EXTRA_RRECOMMENDS meta/conf/machine
> > meta-yocto-bsp/conf/machine/ | grep kernel-modules
> > meta-yocto-bsp/conf/machine/beaglebone-yocto.conf:MACHINE_EXTRA_RRECOMMENDS
> > = "kernel-modules"
> > meta-yocto-bsp/conf/machine/genericarm64.conf:MACHINE_EXTRA_RRECOMMENDS +=
> > "kernel-modules"
> > meta-yocto-bsp/conf/machine/include/genericx86-common.inc:MACHINE_EXTRA_RRECOMMENDS
> > += "kernel-modules linux-firmware"
> > meta/conf/machine/include/loongarch/qemuloongarch.inc:MACHINE_EXTRA_RRECOMMENDS
> > += " kernel-modules"
> > meta/conf/machine/include/riscv/qemuriscv.inc:MACHINE_EXTRA_RRECOMMENDS +=
> > " kernel-modules"
> > meta/conf/machine/qemuppc64.conf:MACHINE_EXTRA_RRECOMMENDS += "
> > kernel-modules"
> >
> Right, and that was by design.
> 
> The philosophy has been that the kernel provider should understand
> and control its configuration (since we are talking about embedded
> devices here). Sure, those examples took the simplest path, and that
> was their decision / tradeoff.
> 
> We package all the modules individually (I'm stating the obvious,
> since we all know this) so that they can be individually installed
> and required for something that really wants to control the configuration
> tightly.
> 
> In any machine / BSP that I build, the configuration is on purpose
> and if I want to install individual modules, I'll do that, otherwise,
> I trust my configuration and take all the modules.
> 
> What you have is something in the middle, and why I still think it
> needs to be opt-in. BSP creators need to understand their
> configuration and tune it. Having something down at the packaging
> level pick and choose which modules on their behalf means that
> they are relying on something that needs to be discovered and
> tweaked (versus the "all of it" or "you chose your own" as it was
> before).

By making the kernel-initrd-modules meta package optional and opt-in,
we again make the initrd image recipe depend on the opt-in feature.

I need to bind the initrd recipe to a distro level feature and
then the same for kernel side changes because the "kernel-initrd-modules"
meta package may not exist and thus it can break the build. Solution
is another abstraction in distro features. I think producing the
"kernel-initrd-modules" meta package should be default in the kernel
bbclasses. It may not get used but the overhead is really small.

This is similar to "kernel-modules" meta package. It is always there
and can safely be in MACHINE_EXTRA_RRECOMMENDS without any additional
guards like a machine or distro feature. Also BSP layer image recipes
use this.

This is the interface between kernel recipes providing kernel and module
packages and the image recipe consuming them. I'd like the image recipe
consumer to be simpler and less dependent kernel config and driver packaging
details.

> > Some qemu machines don't and that causes issues since
> > initrd is not flexible to boot even slightly different configurations,
> > like block device emulation moved from scsi to virtio.
> > This causes issues with oeqa selftests when small kernel or qemuboot
> > differences break tests.
> >
> 
> And we'll continue to do that, as all the boot methods and kernels
> need to be tested. But I agree, there are pros and cons to the
> various methods.
> 
> > initrd itself is optional, but in core-image-initramfs-boot I made
> > including "kernel-initrd-modules" the default. To me this makes sense.
> >
> > Kernels for different machines can enable drivers as modules or as built-in
> > but the initrd config stays the same and will mostly just work. I think
> > this is a good default.
> >
> >
> It is just that behaviour which is why I'm saying it should be
> explicit and opt-in. If they change their configuration it should
> be with a direct line of sight to how the various components
> consume it.
> 
> Preferably not "I have a custom driver, I need it to boot, I'm
> now building it as a module" .. and then wondering why it isn't
> picked up in the initrd. If they had to opt-in, they'll already be
> aware of the mechanism that is selecting their modules over
> and above what their kernel configuration dictates.

If the custom and vendor specific driver installs to correct paths
which fall into block etc driver regex then these already get picked up by the
initrd regex then everything will just work by default. Compiling the driver
built-in or as module will just work with the default core-image-initramfs-boot
initrd and core-image-base etc images. Boot without initrd may fail but with it
things just work.

If this feature is opt-in or specific to linux-yocto recipe, it again makes the
initrd's machine and kernel config specific. The opt-in setup needs to be made
for kernel and for initrd.

For real products all details need to be reviewed and customized but developers
need "good enough and simple" starting points and that's where the
"kernel-modules" and "kernel-initrd-modules" meta packages help.

They can more easily boot the generic images, see what drivers got loaded at boot
and remove all the rest. Then move that setup into kernel config etc. They can
also test different block devices and file systems.

The amount of optimisation done depends on what the priorities are. Gain vs effort.

> > And then "kernel-initrd-modules" are much smaller than "kernel-modules".
> > Still too big for real products but better than nothing. For
> > genericarm64 this reduced initrd image size from 200 Mb to 54 Mb.
> 
> Definitely a valid point / improvement. I'm again back to saying it
> just has to be explicit. The same way that many (most?) people
> don't want or use linux-yocto as production, we have to design
> our configurations as something to be opt-in and something that
> is clear it needs to be tweaked for production.
> 
> We aren't far off in our view on this.  Most of this looks really
> good to me, and is a good step forward. I think that our
> different point of view is about the breadth of the types of
> kernels, machines, boot methods, products, etc, that are built
> on top and how to enable this mechanism.

If this feature is opt-in and not the default in kernel.bbclass, then IMO
the result is again machine/build/config specific initrd image recipes
which I wanted to avoid.

Cheers,

-Mikko

Re: [OE-core] [PATCH v3 03/11] kernel.bbclass: add kernel-initrd-modules meta package

[Bruce Ashfield]

[-- Attachment #1: Type: text/plain, Size: 26016 bytes --]

On Tue, Apr 22, 2025 at 6:18 AM Mikko Rapeli <mikko.rapeli@linaro.org>
wrote:

> Hi,
>
> On Fri, Apr 11, 2025 at 09:39:31AM -0400, Bruce Ashfield wrote:
> > On Fri, Apr 11, 2025 at 9:12 AM Mikko Rapeli <mikko.rapeli@linaro.org>
> > wrote:
> > > On Fri, Apr 11, 2025 at 08:52:24AM -0400, Bruce Ashfield wrote:
> > > > On Fri, Apr 11, 2025 at 3:48 AM Mikko Rapeli <
> mikko.rapeli@linaro.org>
> > > > wrote:
> > > > > On Thu, Apr 10, 2025 at 09:15:02AM -0400, Bruce Ashfield wrote:
> > > > > > On Thu, Apr 10, 2025 at 9:00 AM Mikko Rapeli via
> > > lists.openembedded.org
> > > > > > <mikko.rapeli=linaro.org@lists.openembedded.org> wrote:
> > > > > >
> > > > > > > On Thu, Apr 10, 2025 at 01:42:12PM +0100, Richard Purdie wrote:
> > > > > > > > On Fri, 2025-04-04 at 19:29 +0300, Mikko Rapeli via
> > > > > > > lists.openembedded.org wrote:
> > > > > > > > > At the moment linux-yocto kernels for various architectures
> > > > > > > > > are not very modular and a lot of drivers are built into
> the
> > > kernel
> > > > > > > > > even when they are not needed at runtime. These make the
> main
> > > > > kernel
> > > > > > > > > binary big and slow to boot. This also impacts udev in
> > > userspace
> > > > > > > > > which takes a long time processing events from all these
> built
> > > in
> > > > > > > drivers,
> > > > > > > > > for example when udev runs in initrd.
> > > > > > > > >
> > > > > > > > > Then constructing the initrd is very device and kernel
> > > > > configuration
> > > > > > > specific.
> > > > > > > > > initrd image needs explicitly define which binary packages
> to
> > > > > install
> > > > > > > > > to avoid pulling in complex dependencies. A full set of
> kernel
> > > > > modules
> > > > > > > > > via kernel-modules meta package is too big for initrd and
> most
> > > of
> > > > > the
> > > > > > > > > drivers are not needed for use cases like "just load
> modules to
> > > > > mount
> > > > > > > > > main rootfs". Then the initrd configuration breaks if
> kernel
> > > driver
> > > > > > > > > is built into the kernel since the binary package doesn't
> > > exist.
> > > > > > > > >
> > > > > > > > > Introduce kernel-initrd-modules meta package to solve these
> > > > > problems.
> > > > > > > > > The meta package adds dependencies to real kernel modules
> > > based on
> > > > > > > > > the kernel module file paths so that it will include
> several
> > > > > > > > > kernel subsystems and their drivers which are often needed
> to
> > > find
> > > > > > > > > main rootfs from some block device. This works when
> drivers are
> > > > > built
> > > > > > > > > as modules but does not break if drivers are built into the
> > > kernel.
> > > > > > > > >
> > > > > > > > > The resulting initrd is also smaller since only a subset of
> > > drivers
> > > > > > > > > are needed for "mount the rootfs" usecase. Tested on
> > > genericarm64
> > > > > > > > > kernel and qemu and AMD KV260 HW.
> > > > > > > > >
> > > > > > > > > Signed-off-by: Mikko Rapeli <mikko.rapeli@linaro.org>
> > > > > > > > > ---
> > > > > > > > >  .../kernel-module-split.bbclass               | 48
> > > > > +++++++++++++++++++
> > > > > > > > >  meta/classes-recipe/kernel.bbclass            |  5 +-
> > > > > > > > >  meta/classes-recipe/module.bbclass            | 37
> > > ++++++++++++++
> > > > > > > > >  3 files changed, 89 insertions(+), 1 deletion(-)
> > > > > > > > >
> > > > > > > > > diff --git
> a/meta/classes-recipe/kernel-module-split.bbclass
> > > > > > > b/meta/classes-recipe/kernel-module-split.bbclass
> > > > > > > > > index 9487365eb7..101c5cd959 100644
> > > > > > > > > --- a/meta/classes-recipe/kernel-module-split.bbclass
> > > > > > > > > +++ b/meta/classes-recipe/kernel-module-split.bbclass
> > > > > > > > > @@ -42,6 +42,40 @@ KERNEL_MODULE_PACKAGE_PREFIX ?= ""
> > > > > > > > >  KERNEL_MODULE_PACKAGE_SUFFIX ?= "-${KERNEL_VERSION}"
> > > > > > > > >  KERNEL_MODULE_PROVIDE_VIRTUAL ?= "1"
> > > > > > > > >
> > > > > > > > > +# subset of kernel modules needed in initrd, to e.g. mount
> > > rootfs
> > > > > > > from block device
> > > > > > > > > +KERNEL_INITRD_MODULES_META_PACKAGE ?= "${@
> > > > > > > d.getVar("KERNEL_PACKAGE_NAME") or "kernel" }-initrd-modules"
> > > > > > > > > +
> > > > > > > > > +# match regex to path or file name. E.g. include all
> drivers
> > > with
> > > > > > > files in path /drivers/ata/
> > > > > > > > > +KERNEL_INITRD_MODULES_REGEX ?= "(.*)(\
> > > > > > > > > +/drivers/acpi/|\
> > > > > > > > > +/drivers/ata/|\
> > > > > > > > > +/drivers/block/|\
> > > > > > > > > +/drivers/cdrom/|\
> > > > > > > > > +/drivers/char/hw_random/|\
> > > > > > > > > +/drivers/char/tpm/|\
> > > > > > > > > +/drivers/char/|\
> > > > > > > > > +/drivers/crypto/|\
> > > > > > > > > +/drivers/dax/|\
> > > > > > > > > +/drivers/firmware/arm_scmi/|\
> > > > > > > > > +/drivers/gpu/drm/|\
> > > > > > > > > +/drivers/md/|\
> > > > > > > > > +/drivers/mmc/|\
> > > > > > > > > +/drivers/mtd/|\
> > > > > > > > > +/drivers/nvdimm/|\
> > > > > > > > > +/drivers/nvme/|\
> > > > > > > > > +/drivers/pci/|\
> > > > > > > > > +/drivers/scsi/|\
> > > > > > > > > +/drivers/tee/|\
> > > > > > > > > +/drivers/tty/serial/|\
> > > > > > > > > +/drivers/virtio/|\
> > > > > > > > > +/drivers/watchdog/|\
> > > > > > > > > +/kernel/arch/|\
> > > > > > > > > +/kernel/block/|\
> > > > > > > > > +/kernel/crypto/|\
> > > > > > > > > +/kernel/fs/|\
> > > > > > > > > +/kernel/lib/\
> > > > > > > > > +)(.*)"
> > > > > > > > > +
> > > > > > > > >  python split_kernel_module_packages () {
> > > > > > > > >      import re
> > > > > > > > >
> > > > > > > > > @@ -183,6 +217,20 @@ python split_kernel_module_packages
> () {
> > > > > > > > >      modules = do_split_packages(d,
> > > > > > > root='${nonarch_base_libdir}/modules', file_regex=module_regex,
> > > > > > > output_pattern=module_pattern, description='%s kernel module',
> > > > > > > postinst=postinst, postrm=postrm, recursive=True,
> > > hook=frob_metadata,
> > > > > > > extra_depends='%s-%s' % (kernel_package_name, kernel_version))
> > > > > > > > >      if modules:
> > > > > > > > >          d.appendVar('RDEPENDS:' + metapkg, ' '+'
> > > '.join(modules))
> > > > > > > > > +
> > > > > > > > > +    initrd_metapkg =
> > > > > d.getVar('KERNEL_INITRD_MODULES_META_PACKAGE')
> > > > > > > or ""
> > > > > > > > > +    initrd_module_regex =
> > > d.getVar('KERNEL_INITRD_MODULES_REGEX')
> > > > > or
> > > > > > > ""
> > > > > > > > > +    if (initrd_metapkg != "") and (initrd_module_regex !=
> ""):
> > > > > > > > > +        initrd_module_regex =
> re.compile(initrd_module_regex)
> > > > > > > > > +        initrd_modules = []
> > > > > > > > > +        for module in modules:
> > > > > > > > > +            files = d.getVar('FILES:' + module)
> > > > > > > > > +            m = re.match(initrd_module_regex, files)
> > > > > > > > > +            if m:
> > > > > > > > > +                initrd_modules.append(module)
> > > > > > > > > +
> > > > > > > > > +        if initrd_modules:
> > > > > > > > > +            d.appendVar('RDEPENDS:' + initrd_metapkg, '
> '+'
> > > > > > > '.join(initrd_modules))
> > > > > > > > >  }
> > > > > > > > >
> > > > > > > > >  do_package[vardeps] += '${@" ".join(map(lambda s:
> > > "module_conf_"
> > > > > + s,
> > > > > > > (d.getVar("KERNEL_MODULE_PROBECONF") or "").split()))}'
> > > > > > > > > diff --git a/meta/classes-recipe/kernel.bbclass
> > > > > > > b/meta/classes-recipe/kernel.bbclass
> > > > > > > > > index 36ce659762..3dcaebcaed 100644
> > > > > > > > > --- a/meta/classes-recipe/kernel.bbclass
> > > > > > > > > +++ b/meta/classes-recipe/kernel.bbclass
> > > > > > > > > @@ -695,13 +695,14 @@ EXPORT_FUNCTIONS do_compile
> > > > > do_transform_kernel
> > > > > > > do_transform_bundled_initramfs d
> > > > > > > > >
> > > > > > > > >  # kernel-base becomes kernel-${KERNEL_VERSION}
> > > > > > > > >  # kernel-image becomes kernel-image-${KERNEL_VERSION}
> > > > > > > > > -PACKAGES = "${KERNEL_PACKAGE_NAME}
> ${KERNEL_PACKAGE_NAME}-base
> > > > > > > ${KERNEL_PACKAGE_NAME}-vmlinux ${KERNEL_PACKAGE_NAME}-image
> > > > > > > ${KERNEL_PACKAGE_NAME}-dev ${KERNEL_PACKAGE_NAME}-modules
> > > > > > > ${KERNEL_PACKAGE_NAME}-dbg"
> > > > > > > > > +PACKAGES = "${KERNEL_PACKAGE_NAME}
> ${KERNEL_PACKAGE_NAME}-base
> > > > > > > ${KERNEL_PACKAGE_NAME}-vmlinux ${KERNEL_PACKAGE_NAME}-image
> > > > > > > ${KERNEL_PACKAGE_NAME}-dev ${KERNEL_PACKAGE_NAME}-modules
> > > > > > > ${KERNEL_PACKAGE_NAME}-initrd-modules
> ${KERNEL_PACKAGE_NAME}-dbg"
> > > > > > > > >  FILES:${PN} = ""
> > > > > > > > >  FILES:${KERNEL_PACKAGE_NAME}-base =
> > > > > > > "${nonarch_base_libdir}/modules/${KERNEL_VERSION}/modules.order
> > > > > > >
> ${nonarch_base_libdir}/modules/${KERNEL_VERSION}/modules.builtin
> > > > > > >
> > > > >
> > >
> ${nonarch_base_libdir}/modules/${KERNEL_VERSION}/modules.builtin.modinfo"
> > > > > > > > >  FILES:${KERNEL_PACKAGE_NAME}-image = ""
> > > > > > > > >  FILES:${KERNEL_PACKAGE_NAME}-dev =
> > > > > "/${KERNEL_IMAGEDEST}/System.map*
> > > > > > > /${KERNEL_IMAGEDEST}/Module.symvers*
> /${KERNEL_IMAGEDEST}/config*
> > > > > > > ${KERNEL_SRC_PATH}
> > > > > ${nonarch_base_libdir}/modules/${KERNEL_VERSION}/build"
> > > > > > > > >  FILES:${KERNEL_PACKAGE_NAME}-vmlinux =
> > > > > > > "/${KERNEL_IMAGEDEST}/vmlinux-${KERNEL_VERSION_NAME}"
> > > > > > > > >  FILES:${KERNEL_PACKAGE_NAME}-modules = ""
> > > > > > > > > +FILES:${KERNEL_PACKAGE_NAME}-initrd-modules = ""
> > > > > > > > >  FILES:${KERNEL_PACKAGE_NAME}-dbg = "/usr/lib/debug
> > > /usr/src/debug"
> > > > > > > > >  RDEPENDS:${KERNEL_PACKAGE_NAME} =
> > > "${KERNEL_PACKAGE_NAME}-base (=
> > > > > > > ${EXTENDPKGV})"
> > > > > > > > >  # Allow machines to override this dependency if kernel
> image
> > > > > files are
> > > > > > > > > @@ -716,7 +717,9 @@ ALLOW_EMPTY:${KERNEL_PACKAGE_NAME} =
> "1"
> > > > > > > > >  ALLOW_EMPTY:${KERNEL_PACKAGE_NAME}-base = "1"
> > > > > > > > >  ALLOW_EMPTY:${KERNEL_PACKAGE_NAME}-image = "1"
> > > > > > > > >  ALLOW_EMPTY:${KERNEL_PACKAGE_NAME}-modules = "1"
> > > > > > > > > +ALLOW_EMPTY:${KERNEL_PACKAGE_NAME}-initrd-modules = "1"
> > > > > > > > >  DESCRIPTION:${KERNEL_PACKAGE_NAME}-modules = "Kernel
> modules
> > > meta
> > > > > > > package"
> > > > > > > > > +DESCRIPTION:${KERNEL_PACKAGE_NAME}-initrd-modules =
> "Kernel
> > > initrd
> > > > > > > modules meta package"
> > > > > > > > >
> > > > > > > > >  pkg_postinst:${KERNEL_PACKAGE_NAME}-base () {
> > > > > > > > >     if [ ! -e "$D/lib/modules/${KERNEL_VERSION}" ]; then
> > > > > > > > > diff --git a/meta/classes-recipe/module.bbclass
> > > > > > > b/meta/classes-recipe/module.bbclass
> > > > > > > > > index f2f0b25a2d..51f864f1f9 100644
> > > > > > > > > --- a/meta/classes-recipe/module.bbclass
> > > > > > > > > +++ b/meta/classes-recipe/module.bbclass
> > > > > > > > > @@ -86,3 +86,40 @@ EXPORT_FUNCTIONS do_compile do_install
> > > > > > > > >  KERNEL_MODULES_META_PACKAGE = "${PN}"
> > > > > > > > >  FILES:${PN} = ""
> > > > > > > > >  ALLOW_EMPTY:${PN} = "1"
> > > > > > > > > +
> > > > > > > > > +# subset of kernel modules needed in initrd, to e.g. mount
> > > rootfs
> > > > > > > from block device
> > > > > > > > > +KERNEL_INITRD_MODULES_META_PACKAGE ?= "${@
> > > > > > > d.getVar("KERNEL_PACKAGE_NAME") or "kernel" }-initrd-modules"
> > > > > > > > > +
> > > > > > > > > +# match regex to path or file name. E.g. include all
> drivers
> > > with
> > > > > > > files in path /drivers/ata/
> > > > > > > > > +KERNEL_INITRD_MODULES_REGEX ?= "(.*)(\
> > > > > > > > > +/drivers/acpi/|\
> > > > > > > > > +/drivers/ata/|\
> > > > > > > > > +/drivers/block/|\
> > > > > > > > > +/drivers/cdrom/|\
> > > > > > > > > +/drivers/char/hw_random/|\
> > > > > > > > > +/drivers/char/tpm/|\
> > > > > > > > > +/drivers/char/|\
> > > > > > > > > +/drivers/crypto/|\
> > > > > > > > > +/drivers/dax/|\
> > > > > > > > > +/drivers/firmware/arm_scmi/|\
> > > > > > > > > +/drivers/gpu/drm/|\
> > > > > > > > > +/drivers/md/|\
> > > > > > > > > +/drivers/mmc/|\
> > > > > > > > > +/drivers/mtd/|\
> > > > > > > > > +/drivers/nvdimm/|\
> > > > > > > > > +/drivers/nvme/|\
> > > > > > > > > +/drivers/pci/|\
> > > > > > > > > +/drivers/scsi/|\
> > > > > > > > > +/drivers/tee/|\
> > > > > > > > > +/drivers/tty/serial/|\
> > > > > > > > > +/drivers/virtio/|\
> > > > > > > > > +/drivers/watchdog/|\
> > > > > > > > > +/kernel/arch/|\
> > > > > > > > > +/kernel/block/|\
> > > > > > > > > +/kernel/crypto/|\
> > > > > > > > > +/kernel/fs/|\
> > > > > > > > > +/kernel/lib/\
> > > > > > > > > +)(.*)"
> > > > > > > > > +
> > > > > > > > > +FILES:${PN}-initrd = ""
> > > > > > > > > +ALLOW_EMPTY:${PN}-initrd = "1"
> > > > > > > >
> > > > > > > > What is the difference between the variable defined in
> > > kernel-module-
> > > > > > > > split.bbclass and this one in module.bbclass? Do we
> need/want to
> > > > > > > > separate but seemingly similar definitions?
> > > > > > >
> > > > > > > One is for kernel compilation and in-tree drivers, the other
> is for
> > > > > > > out-of-tree modules.
> > > > > > >
> > > > > > > The "kernel-modules" meta package is handled this way too, with
> > > > > > > duplication in both.
> > > > > > >
> > > > > > > Bruce says this should be moved to linux-yocto kernel recipe,
> > > > > > > which IMO breaks the use of kernel-initrd-modules for vendor
> kernel
> > > > > recipes
> > > > > > > outside of oe-core. I'd rather support them too to e.g. more
> easily
> > > > > boot
> > > > > > > qemu or run oeqa selftests with qemu.
> > > > > > >
> > > > > >
> > > > > > That's not quite what I said (but it is close), I said it
> shouldn't
> > > be
> > > > > > defined
> > > > > > at the base with no requirement opt-in from a recipe (even if
> this
> > > way
> > > > > > of constructing an initrd with the modules is not the default).
> It
> > > is a (
> > > > > > weak)
> > > > > > binding to specific kernel versions and directory layouts, but
> it is
> > > a
> > > > > > binding
> > > > > > none the less. If it sits at the base in the classes no one will
> ever
> > > > > look
> > > > > > at
> > > > > > it or even know that it should be considered.
> > > > > >
> > > > > > My suggestion was not that it should only be in linux-yocto (but
> I'd
> > > > > > insist on overriding it or doing it slightly differently in
> > > linux-yocto),
> > > > > > I was saying that it I think  that the two definitions are far to
> > > similar
> > > > > > and even if there remain two definitions, they should be moved
> > > > > > into a .inc file.
> > > > >
> > > > > Actually the duplication is a bug. All duplication in
> module.bbclass
> > > can be
> > > > > removed since it includes kernel-module-split.bbclass. Both
> > > kernel.bbclass
> > > > > and
> > > > > module.bbclass include kernel-module-split.bbclass. Sorry about
> this.
> > > > > I must have stopped half way when moving things there.
> > > > >
> > > > > Sending v4 with this fixed soon.
> > > > >
> > > > > > Any kernel recipe that wants to build an initrd like this can
> opt-in
> > > by
> > > > > > including the .inc, and/or creating their own definition.
> > > > >
> > > > > This I don't get. I think the kernel.bbclass and module.bbclass
> should
> > > > > work out of the box with sane defaults. The kernel recipes can
> override
> > > > > and adjust these as they see fit. Yes there is a dependency to some
> > > kernel
> > > > > APIs (kernel module install paths) which can change, but those have
> > > been
> > > > > stable for, over 25 years (as long as I have been compiling
> kernels)?
> > > > >
> > > > > For full control, initrd recipe maintainers can define the exact
> set
> > > > > of kernel and other binary packages to install which makes the
> recipe
> > > > > kernel config and machine specific.
> > > > >
> > > > > I don't think moving the definitions to a linux-yocto side .inc
> file
> > > > > and then using that as basis in non-core kernel recipes is good.
> The
> > > > > kernel.bbclass and module.bbclass would not work independently
> anymore
> > > > > and require meta/recipes-kernel/linux/ side .inc file for working
> > > defaults.
> > > > > Or should the .inc file live in meta/conf/distro/include?
> > > > >
> > > >
> > > > Let me be clear. I am not saying "linux-yocto" here. I said a ".inc"
> > > file.
> > > >
> > > > Put that .inc file in a common directory and call it something like
> > > > initrd-kernel-<foo>.inc, recipes include that .inc file to opt into
> the
> > > > behaviour and get the base definition if they want it.
> > >
> > > Ok I will do this in v5.
> > >
> > > > This modular based initrd isn't going to be the default, so it has
> > > > to be opt-in anyway. So put the opt-in and the definitions in a .inc
> > > > file, a recipe including it, opts-in.
> > >
> > > I think this should be the default on most machines which use
> > > core-image-initramfs-boot in oe-core.
> >
> >
> > I'll disagree on that point, but in the end, it isn't a hill that
> > is worth climbing (for me). If that's the way the default policy
> > goes, I'll just roll with it.
> >
> > > genericarm64, beagleplay etc machines already for install of
> > > "kernel-modules"
> > > to all images, including core-image-initramfs-boot:
> > >
> > > $ git grep MACHINE_EXTRA_RRECOMMENDS meta/conf/machine
> > > meta-yocto-bsp/conf/machine/ | grep kernel-modules
> > >
> meta-yocto-bsp/conf/machine/beaglebone-yocto.conf:MACHINE_EXTRA_RRECOMMENDS
> > > = "kernel-modules"
> > >
> meta-yocto-bsp/conf/machine/genericarm64.conf:MACHINE_EXTRA_RRECOMMENDS +=
> > > "kernel-modules"
> > >
> meta-yocto-bsp/conf/machine/include/genericx86-common.inc:MACHINE_EXTRA_RRECOMMENDS
> > > += "kernel-modules linux-firmware"
> > >
> meta/conf/machine/include/loongarch/qemuloongarch.inc:MACHINE_EXTRA_RRECOMMENDS
> > > += " kernel-modules"
> > >
> meta/conf/machine/include/riscv/qemuriscv.inc:MACHINE_EXTRA_RRECOMMENDS +=
> > > " kernel-modules"
> > > meta/conf/machine/qemuppc64.conf:MACHINE_EXTRA_RRECOMMENDS += "
> > > kernel-modules"
> > >
> > Right, and that was by design.
> >
> > The philosophy has been that the kernel provider should understand
> > and control its configuration (since we are talking about embedded
> > devices here). Sure, those examples took the simplest path, and that
> > was their decision / tradeoff.
> >
> > We package all the modules individually (I'm stating the obvious,
> > since we all know this) so that they can be individually installed
> > and required for something that really wants to control the configuration
> > tightly.
> >
> > In any machine / BSP that I build, the configuration is on purpose
> > and if I want to install individual modules, I'll do that, otherwise,
> > I trust my configuration and take all the modules.
> >
> > What you have is something in the middle, and why I still think it
> > needs to be opt-in. BSP creators need to understand their
> > configuration and tune it. Having something down at the packaging
> > level pick and choose which modules on their behalf means that
> > they are relying on something that needs to be discovered and
> > tweaked (versus the "all of it" or "you chose your own" as it was
> > before).
>
> By making the kernel-initrd-modules meta package optional and opt-in,
> we again make the initrd image recipe depend on the opt-in feature.
>
>
That's exactly what I'm looking for and consider it a good thing :)

I need to bind the initrd recipe to a distro level feature and
> then the same for kernel side changes because the "kernel-initrd-modules"
> meta package may not exist and thus it can break the build. Solution
> is another abstraction in distro features. I think producing the
> "kernel-initrd-modules" meta package should be default in the kernel
> bbclasses. It may not get used but the overhead is really small.
>
> This is similar to "kernel-modules" meta package. It is always there
> and can safely be in MACHINE_EXTRA_RRECOMMENDS without any additional
> guards like a machine or distro feature. Also BSP layer image recipes
> use this.
>

Except that it is much different in that it is not the BSP kernel
configuration
that is controlling what is chosen for the meta-package. It is not the
meta package itself that I have an issue with.


>
> This is the interface between kernel recipes providing kernel and module
> packages and the image recipe consuming them. I'd like the image recipe
> consumer to be simpler and less dependent kernel config and driver
> packaging
> details.
>

It is the selection mechanism that I disagree with. This is one
area that we need to be very explicit and have that fine grained control.


>
> > > Some qemu machines don't and that causes issues since
> > > initrd is not flexible to boot even slightly different configurations,
> > > like block device emulation moved from scsi to virtio.
> > > This causes issues with oeqa selftests when small kernel or qemuboot
> > > differences break tests.
> > >
> >
> > And we'll continue to do that, as all the boot methods and kernels
> > need to be tested. But I agree, there are pros and cons to the
> > various methods.
> >
> > > initrd itself is optional, but in core-image-initramfs-boot I made
> > > including "kernel-initrd-modules" the default. To me this makes sense.
> > >
> > > Kernels for different machines can enable drivers as modules or as
> built-in
> > > but the initrd config stays the same and will mostly just work. I think
> > > this is a good default.
> > >
> > >
> > It is just that behaviour which is why I'm saying it should be
> > explicit and opt-in. If they change their configuration it should
> > be with a direct line of sight to how the various components
> > consume it.
> >
> > Preferably not "I have a custom driver, I need it to boot, I'm
> > now building it as a module" .. and then wondering why it isn't
> > picked up in the initrd. If they had to opt-in, they'll already be
> > aware of the mechanism that is selecting their modules over
> > and above what their kernel configuration dictates.
>
> If the custom and vendor specific driver installs to correct paths
> which fall into block etc driver regex then these already get picked up by
> the
> initrd regex then everything will just work by default. Compiling the
> driver
> built-in or as module will just work with the default
> core-image-initramfs-boot
> initrd and core-image-base etc images. Boot without initrd may fail but
> with it
> things just work.
>

That vendor needs to understand what they are relying on. The same
way that their packages from any other recipe don't automatically get
built and used in an image with them explicitly asking for them in their
image recipes.

That is my point, I don't think this should just "automatically work". It
should have a simple way to opt-in, but behind the scenes magic in
this particular area is just going to cause support issues.


> If this feature is opt-in or specific to linux-yocto recipe, it again
> makes the
> initrd's machine and kernel config specific. The opt-in setup needs to be
> made
> for kernel and for initrd.


> For real products all details need to be reviewed and customized but
> developers
> need "good enough and simple" starting points and that's where the
> "kernel-modules" and "kernel-initrd-modules" meta packages help.
>

After 14 years of working for an OSV, I'm familiar with how a real
product is put together. I've also supported many customers through
the issues I'm describing above. I'm not just describing this theoretically,
I've also spent the hours trying to figure out silent boot death, and
the zillion variations of that.


> They can more easily boot the generic images, see what drivers got loaded
> at boot
> and remove all the rest. Then move that setup into kernel config etc. They
> can
> also test different block devices and file systems.
>
> The amount of optimisation done depends on what the priorities are. Gain
> vs effort.
>
> > > And then "kernel-initrd-modules" are much smaller than
> "kernel-modules".
> > > Still too big for real products but better than nothing. For
> > > genericarm64 this reduced initrd image size from 200 Mb to 54 Mb.
> >
> > Definitely a valid point / improvement. I'm again back to saying it
> > just has to be explicit. The same way that many (most?) people
> > don't want or use linux-yocto as production, we have to design
> > our configurations as something to be opt-in and something that
> > is clear it needs to be tweaked for production.
> >
> > We aren't far off in our view on this.  Most of this looks really
> > good to me, and is a good step forward. I think that our
> > different point of view is about the breadth of the types of
> > kernels, machines, boot methods, products, etc, that are built
> > on top and how to enable this mechanism.
>
> If this feature is opt-in and not the default in kernel.bbclass, then IMO
> the result is again machine/build/config specific initrd image recipes
> which I wanted to avoid.
>

Having a distro feature that enables it, and then having the defaults
kick in, shouldn't be too high of a bar for someone to look, read the
descriptions and decide that's what they want. After that opt-in, everything
should look pretty much like you are proposing.

Bruce


> Cheers,
>
> -Mikko
>


-- 
- Thou shalt not follow the NULL pointer, for chaos and madness await thee
at its end
- "Use the force Harry" - Gandalf, Star Trek II

[-- Attachment #2: Type: text/html, Size: 38172 bytes --]

Re: [OE-core] [PATCH v3 03/11] kernel.bbclass: add kernel-initrd-modules meta package

[Mikko Rapeli]

Hi,

On Thu, Apr 10, 2025 at 04:00:50PM +0300, Mikko Rapeli via lists.openembedded.org wrote:
> On Thu, Apr 10, 2025 at 01:42:12PM +0100, Richard Purdie wrote:
> > On Fri, 2025-04-04 at 19:29 +0300, Mikko Rapeli via lists.openembedded.org wrote:
> > > At the moment linux-yocto kernels for various architectures
> > > are not very modular and a lot of drivers are built into the kernel
> > > even when they are not needed at runtime. These make the main kernel
> > > binary big and slow to boot. This also impacts udev in userspace
> > > which takes a long time processing events from all these built in drivers,
> > > for example when udev runs in initrd.
> > > 
> > > Then constructing the initrd is very device and kernel configuration specific.
> > > initrd image needs explicitly define which binary packages to install
> > > to avoid pulling in complex dependencies. A full set of kernel modules
> > > via kernel-modules meta package is too big for initrd and most of the
> > > drivers are not needed for use cases like "just load modules to mount
> > > main rootfs". Then the initrd configuration breaks if kernel driver
> > > is built into the kernel since the binary package doesn't exist.
> > > 
> > > Introduce kernel-initrd-modules meta package to solve these problems.
> > > The meta package adds dependencies to real kernel modules based on
> > > the kernel module file paths so that it will include several
> > > kernel subsystems and their drivers which are often needed to find
> > > main rootfs from some block device. This works when drivers are built
> > > as modules but does not break if drivers are built into the kernel.
> > > 
> > > The resulting initrd is also smaller since only a subset of drivers
> > > are needed for "mount the rootfs" usecase. Tested on genericarm64
> > > kernel and qemu and AMD KV260 HW.
> > > 
> > > Signed-off-by: Mikko Rapeli <mikko.rapeli@linaro.org>
> > > ---
> > > �.../kernel-module-split.bbclass�������������� | 48 +++++++++++++++++++
> > > �meta/classes-recipe/kernel.bbclass����������� |� 5 +-
> > > �meta/classes-recipe/module.bbclass����������� | 37 ++++++++++++++
> > > �3 files changed, 89 insertions(+), 1 deletion(-)
> > > 
> > > diff --git a/meta/classes-recipe/kernel-module-split.bbclass b/meta/classes-recipe/kernel-module-split.bbclass
> > > index 9487365eb7..101c5cd959 100644
> > > --- a/meta/classes-recipe/kernel-module-split.bbclass
> > > +++ b/meta/classes-recipe/kernel-module-split.bbclass
> > > @@ -42,6 +42,40 @@ KERNEL_MODULE_PACKAGE_PREFIX ?= ""
> > > �KERNEL_MODULE_PACKAGE_SUFFIX ?= "-${KERNEL_VERSION}"
> > > �KERNEL_MODULE_PROVIDE_VIRTUAL ?= "1"
> > > �
> > > +# subset of kernel modules needed in initrd, to e.g. mount rootfs from block device
> > > +KERNEL_INITRD_MODULES_META_PACKAGE ?= "${@ d.getVar("KERNEL_PACKAGE_NAME") or "kernel" }-initrd-modules"
> > > +
> > > +# match regex to path or file name. E.g. include all drivers with files in path /drivers/ata/
> > > +KERNEL_INITRD_MODULES_REGEX ?= "(.*)(\
> > > +/drivers/acpi/|\
> > > +/drivers/ata/|\
> > > +/drivers/block/|\
> > > +/drivers/cdrom/|\
> > > +/drivers/char/hw_random/|\
> > > +/drivers/char/tpm/|\
> > > +/drivers/char/|\
> > > +/drivers/crypto/|\
> > > +/drivers/dax/|\
> > > +/drivers/firmware/arm_scmi/|\
> > > +/drivers/gpu/drm/|\
> > > +/drivers/md/|\
> > > +/drivers/mmc/|\
> > > +/drivers/mtd/|\
> > > +/drivers/nvdimm/|\
> > > +/drivers/nvme/|\
> > > +/drivers/pci/|\
> > > +/drivers/scsi/|\
> > > +/drivers/tee/|\
> > > +/drivers/tty/serial/|\
> > > +/drivers/virtio/|\
> > > +/drivers/watchdog/|\
> > > +/kernel/arch/|\
> > > +/kernel/block/|\
> > > +/kernel/crypto/|\
> > > +/kernel/fs/|\
> > > +/kernel/lib/\
> > > +)(.*)"
> > > +
> > > �python split_kernel_module_packages () {
> > > ���� import re
> > > �
> > > @@ -183,6 +217,20 @@ python split_kernel_module_packages () {
> > > ���� modules = do_split_packages(d, root='${nonarch_base_libdir}/modules', file_regex=module_regex, output_pattern=module_pattern, description='%s kernel module', postinst=postinst, postrm=postrm, recursive=True, hook=frob_metadata, extra_depends='%s-%s' % (kernel_package_name, kernel_version))
> > > ���� if modules:
> > > �������� d.appendVar('RDEPENDS:' + metapkg, ' '+' '.join(modules))
> > > +
> > > +��� initrd_metapkg = d.getVar('KERNEL_INITRD_MODULES_META_PACKAGE') or ""
> > > +��� initrd_module_regex = d.getVar('KERNEL_INITRD_MODULES_REGEX') or ""
> > > +��� if (initrd_metapkg != "") and (initrd_module_regex != ""):
> > > +������� initrd_module_regex = re.compile(initrd_module_regex)
> > > +������� initrd_modules = []
> > > +������� for module in modules:
> > > +����������� files = d.getVar('FILES:' + module)
> > > +����������� m = re.match(initrd_module_regex, files)
> > > +����������� if m:
> > > +��������������� initrd_modules.append(module)
> > > +
> > > +������� if initrd_modules:
> > > +����������� d.appendVar('RDEPENDS:' + initrd_metapkg, ' '+' '.join(initrd_modules))
> > > �}
> > > �
> > > �do_package[vardeps] += '${@" ".join(map(lambda s: "module_conf_" + s, (d.getVar("KERNEL_MODULE_PROBECONF") or "").split()))}'
> > > diff --git a/meta/classes-recipe/kernel.bbclass b/meta/classes-recipe/kernel.bbclass
> > > index 36ce659762..3dcaebcaed 100644
> > > --- a/meta/classes-recipe/kernel.bbclass
> > > +++ b/meta/classes-recipe/kernel.bbclass
> > > @@ -695,13 +695,14 @@ EXPORT_FUNCTIONS do_compile do_transform_kernel do_transform_bundled_initramfs d
> > > �
> > > �# kernel-base becomes kernel-${KERNEL_VERSION}
> > > �# kernel-image becomes kernel-image-${KERNEL_VERSION}
> > > -PACKAGES = "${KERNEL_PACKAGE_NAME} ${KERNEL_PACKAGE_NAME}-base ${KERNEL_PACKAGE_NAME}-vmlinux ${KERNEL_PACKAGE_NAME}-image ${KERNEL_PACKAGE_NAME}-dev ${KERNEL_PACKAGE_NAME}-modules ${KERNEL_PACKAGE_NAME}-dbg"
> > > +PACKAGES = "${KERNEL_PACKAGE_NAME} ${KERNEL_PACKAGE_NAME}-base ${KERNEL_PACKAGE_NAME}-vmlinux ${KERNEL_PACKAGE_NAME}-image ${KERNEL_PACKAGE_NAME}-dev ${KERNEL_PACKAGE_NAME}-modules ${KERNEL_PACKAGE_NAME}-initrd-modules ${KERNEL_PACKAGE_NAME}-dbg"
> > > �FILES:${PN} = ""
> > > �FILES:${KERNEL_PACKAGE_NAME}-base = "${nonarch_base_libdir}/modules/${KERNEL_VERSION}/modules.order ${nonarch_base_libdir}/modules/${KERNEL_VERSION}/modules.builtin ${nonarch_base_libdir}/modules/${KERNEL_VERSION}/modules.builtin.modinfo"
> > > �FILES:${KERNEL_PACKAGE_NAME}-image = ""
> > > �FILES:${KERNEL_PACKAGE_NAME}-dev = "/${KERNEL_IMAGEDEST}/System.map* /${KERNEL_IMAGEDEST}/Module.symvers* /${KERNEL_IMAGEDEST}/config* ${KERNEL_SRC_PATH} ${nonarch_base_libdir}/modules/${KERNEL_VERSION}/build"
> > > �FILES:${KERNEL_PACKAGE_NAME}-vmlinux = "/${KERNEL_IMAGEDEST}/vmlinux-${KERNEL_VERSION_NAME}"
> > > �FILES:${KERNEL_PACKAGE_NAME}-modules = ""
> > > +FILES:${KERNEL_PACKAGE_NAME}-initrd-modules = ""
> > > �FILES:${KERNEL_PACKAGE_NAME}-dbg = "/usr/lib/debug /usr/src/debug"
> > > �RDEPENDS:${KERNEL_PACKAGE_NAME} = "${KERNEL_PACKAGE_NAME}-base (= ${EXTENDPKGV})"
> > > �# Allow machines to override this dependency if kernel image files are
> > > @@ -716,7 +717,9 @@ ALLOW_EMPTY:${KERNEL_PACKAGE_NAME} = "1"
> > > �ALLOW_EMPTY:${KERNEL_PACKAGE_NAME}-base = "1"
> > > �ALLOW_EMPTY:${KERNEL_PACKAGE_NAME}-image = "1"
> > > �ALLOW_EMPTY:${KERNEL_PACKAGE_NAME}-modules = "1"
> > > +ALLOW_EMPTY:${KERNEL_PACKAGE_NAME}-initrd-modules = "1"
> > > �DESCRIPTION:${KERNEL_PACKAGE_NAME}-modules = "Kernel modules meta package"
> > > +DESCRIPTION:${KERNEL_PACKAGE_NAME}-initrd-modules = "Kernel initrd modules meta package"
> > > �
> > > �pkg_postinst:${KERNEL_PACKAGE_NAME}-base () {
> > > �	if [ ! -e "$D/lib/modules/${KERNEL_VERSION}" ]; then
> > > diff --git a/meta/classes-recipe/module.bbclass b/meta/classes-recipe/module.bbclass
> > > index f2f0b25a2d..51f864f1f9 100644
> > > --- a/meta/classes-recipe/module.bbclass
> > > +++ b/meta/classes-recipe/module.bbclass
> > > @@ -86,3 +86,40 @@ EXPORT_FUNCTIONS do_compile do_install
> > > �KERNEL_MODULES_META_PACKAGE = "${PN}"
> > > �FILES:${PN} = ""
> > > �ALLOW_EMPTY:${PN} = "1"
> > > +
> > > +# subset of kernel modules needed in initrd, to e.g. mount rootfs from block device
> > > +KERNEL_INITRD_MODULES_META_PACKAGE ?= "${@ d.getVar("KERNEL_PACKAGE_NAME") or "kernel" }-initrd-modules"
> > > +
> > > +# match regex to path or file name. E.g. include all drivers with files in path /drivers/ata/
> > > +KERNEL_INITRD_MODULES_REGEX ?= "(.*)(\
> > > +/drivers/acpi/|\
> > > +/drivers/ata/|\
> > > +/drivers/block/|\
> > > +/drivers/cdrom/|\
> > > +/drivers/char/hw_random/|\
> > > +/drivers/char/tpm/|\
> > > +/drivers/char/|\
> > > +/drivers/crypto/|\
> > > +/drivers/dax/|\
> > > +/drivers/firmware/arm_scmi/|\
> > > +/drivers/gpu/drm/|\
> > > +/drivers/md/|\
> > > +/drivers/mmc/|\
> > > +/drivers/mtd/|\
> > > +/drivers/nvdimm/|\
> > > +/drivers/nvme/|\
> > > +/drivers/pci/|\
> > > +/drivers/scsi/|\
> > > +/drivers/tee/|\
> > > +/drivers/tty/serial/|\
> > > +/drivers/virtio/|\
> > > +/drivers/watchdog/|\
> > > +/kernel/arch/|\
> > > +/kernel/block/|\
> > > +/kernel/crypto/|\
> > > +/kernel/fs/|\
> > > +/kernel/lib/\
> > > +)(.*)"
> > > +
> > > +FILES:${PN}-initrd = ""
> > > +ALLOW_EMPTY:${PN}-initrd = "1"
> > 
> > What is the difference between the variable defined in kernel-module-
> > split.bbclass and this one in module.bbclass? Do we need/want to
> > separate but seemingly similar definitions?
> 
> One is for kernel compilation and in-tree drivers, the other is for
> out-of-tree modules.
> 
> The "kernel-modules" meta package is handled this way too, with
> duplication in both.

Sorry, I was wrong. KERNEL_INITRD_MODULES_REGEX duplication is a bug.
I will remove this from module.bbclass. It includes kernel-module-split.bbclass
so defition can be taken from there, just like for kernel.bbclass users.

Cheers,

-Mikko

[PATCH v3 04/11] core-image-initramfs-boot: add option to build systemd based initrd

[Mikko Rapeli]

If "systemd-initramfs" is in DISTRO_FEATURES then convert
core-image-initramfs-boot from shell scripts to systemd.
The resulting initramfs is much bigger than shell script one but
supports much more features like disk encryption and TPM devices.
Also includes udev which can load any drivers needed to mount
rootfs.

Signed-off-by: Mikko Rapeli <mikko.rapeli@linaro.org>
---
 .../images/core-image-initramfs-boot.bb       | 20 ++++++++++++++++---
 1 file changed, 17 insertions(+), 3 deletions(-)

diff --git a/meta/recipes-core/images/core-image-initramfs-boot.bb b/meta/recipes-core/images/core-image-initramfs-boot.bb
index 7258944751..c66c28db76 100644
--- a/meta/recipes-core/images/core-image-initramfs-boot.bb
+++ b/meta/recipes-core/images/core-image-initramfs-boot.bb
@@ -4,7 +4,23 @@ LICENSE = "MIT"
 
 INITRAMFS_SCRIPTS ?= "initramfs-framework-base initramfs-module-udev"
 
-PACKAGE_INSTALL = "${INITRAMFS_SCRIPTS} ${VIRTUAL-RUNTIME_base-utils} base-passwd"
+inherit image
+
+PACKAGE_INSTALL = " \
+    ${VIRTUAL-RUNTIME_base-utils} \
+    ${@bb.utils.contains('DISTRO_FEATURES', 'systemd-initramfs', ' \
+        base-files \
+        coreutils \
+        e2fsprogs-mke2fs \
+        os-release-initrd \
+        util-linux-blkid \
+        util-linux-mount \
+        util-linux-umount \
+        ${VIRTUAL-RUNTIME_init_manager} \
+        ${VIRTUAL-RUNTIME_dev_manager} \
+    ', '${INITRAMFS_SCRIPTS}', d)} \
+    base-passwd \
+"
 
 # Ensure the initramfs only contains the bare minimum
 IMAGE_FEATURES = ""
@@ -18,5 +34,3 @@ IMAGE_FSTYPES = "${INITRAMFS_FSTYPES}"
 IMAGE_NAME_SUFFIX ?= ""
 IMAGE_ROOTFS_SIZE = "8192"
 IMAGE_ROOTFS_EXTRA_SPACE = "0"
-
-inherit image
-- 
2.43.0

Re: [OE-core] [PATCH v3 04/11] core-image-initramfs-boot: add option to build systemd based initrd

[Koen Kooi]

Op 4 apr 2025, om 18:29 heeft Mikko Rapeli via lists.openembedded.org <mikko.rapeli=linaro.org@lists.openembedded.org> het volgende geschreven:
> 
> If "systemd-initramfs" is in DISTRO_FEATURES then convert
> core-image-initramfs-boot from shell scripts to systemd.
> The resulting initramfs is much bigger than shell script one but
> supports much more features like disk encryption and TPM devices.
> Also includes udev which can load any drivers needed to mount
> rootfs.

Are packaged based kernel updates finally working with this?

regards,

Koen

> 
> Signed-off-by: Mikko Rapeli <mikko.rapeli@linaro.org>
> ---
> .../images/core-image-initramfs-boot.bb       | 20 ++++++++++++++++---
> 1 file changed, 17 insertions(+), 3 deletions(-)
> 
> diff --git a/meta/recipes-core/images/core-image-initramfs-boot.bb b/meta/recipes-core/images/core-image-initramfs-boot.bb
> index 7258944751..c66c28db76 100644
> --- a/meta/recipes-core/images/core-image-initramfs-boot.bb
> +++ b/meta/recipes-core/images/core-image-initramfs-boot.bb
> @@ -4,7 +4,23 @@ LICENSE = "MIT"
> 
> INITRAMFS_SCRIPTS ?= "initramfs-framework-base initramfs-module-udev"
> 
> -PACKAGE_INSTALL = "${INITRAMFS_SCRIPTS} ${VIRTUAL-RUNTIME_base-utils} base-passwd"
> +inherit image
> +
> +PACKAGE_INSTALL = " \
> +    ${VIRTUAL-RUNTIME_base-utils} \
> +    ${@bb.utils.contains('DISTRO_FEATURES', 'systemd-initramfs', ' \
> +        base-files \
> +        coreutils \
> +        e2fsprogs-mke2fs \
> +        os-release-initrd \
> +        util-linux-blkid \
> +        util-linux-mount \
> +        util-linux-umount \
> +        ${VIRTUAL-RUNTIME_init_manager} \
> +        ${VIRTUAL-RUNTIME_dev_manager} \
> +    ', '${INITRAMFS_SCRIPTS}', d)} \
> +    base-passwd \
> +"
> 
> # Ensure the initramfs only contains the bare minimum
> IMAGE_FEATURES = ""
> @@ -18,5 +34,3 @@ IMAGE_FSTYPES = "${INITRAMFS_FSTYPES}"
> IMAGE_NAME_SUFFIX ?= ""
> IMAGE_ROOTFS_SIZE = "8192"
> IMAGE_ROOTFS_EXTRA_SPACE = "0"
> -
> -inherit image
> -- 
> 2.43.0
> 
> 
> -=-=-=-=-=-=-=-=-=-=-=-
> Links: You receive all messages sent to this group.
> View/Reply Online (#214355): https://lists.openembedded.org/g/openembedded-core/message/214355
> Mute This Topic: https://lists.openembedded.org/mt/112087527/9418801
> Group Owner: openembedded-core+owner@lists.openembedded.org
> Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [koen.kooi@oss.qualcomm.com]
> -=-=-=-=-=-=-=-=-=-=-=-
> 

Re: [OE-core] [PATCH v3 04/11] core-image-initramfs-boot: add option to build systemd based initrd

[Mikko Rapeli]

Hi,

On Mon, Apr 07, 2025 at 08:01:41AM +0200, Koen Kooi wrote:
> Op 4 apr 2025, om 18:29 heeft Mikko Rapeli via lists.openembedded.org <mikko.rapeli=linaro.org@lists.openembedded.org> het volgende geschreven:
> > 
> > If "systemd-initramfs" is in DISTRO_FEATURES then convert
> > core-image-initramfs-boot from shell scripts to systemd.
> > The resulting initramfs is much bigger than shell script one but
> > supports much more features like disk encryption and TPM devices.
> > Also includes udev which can load any drivers needed to mount
> > rootfs.
> 
> Are packaged based kernel updates finally working with this?

Sorry, I don't get this question. What is package based kernel updates?

Cheers,

-Mikko

> regards,
> 
> Koen
> 
> > 
> > Signed-off-by: Mikko Rapeli <mikko.rapeli@linaro.org>
> > ---
> > .../images/core-image-initramfs-boot.bb       | 20 ++++++++++++++++---
> > 1 file changed, 17 insertions(+), 3 deletions(-)
> > 
> > diff --git a/meta/recipes-core/images/core-image-initramfs-boot.bb b/meta/recipes-core/images/core-image-initramfs-boot.bb
> > index 7258944751..c66c28db76 100644
> > --- a/meta/recipes-core/images/core-image-initramfs-boot.bb
> > +++ b/meta/recipes-core/images/core-image-initramfs-boot.bb
> > @@ -4,7 +4,23 @@ LICENSE = "MIT"
> > 
> > INITRAMFS_SCRIPTS ?= "initramfs-framework-base initramfs-module-udev"
> > 
> > -PACKAGE_INSTALL = "${INITRAMFS_SCRIPTS} ${VIRTUAL-RUNTIME_base-utils} base-passwd"
> > +inherit image
> > +
> > +PACKAGE_INSTALL = " \
> > +    ${VIRTUAL-RUNTIME_base-utils} \
> > +    ${@bb.utils.contains('DISTRO_FEATURES', 'systemd-initramfs', ' \
> > +        base-files \
> > +        coreutils \
> > +        e2fsprogs-mke2fs \
> > +        os-release-initrd \
> > +        util-linux-blkid \
> > +        util-linux-mount \
> > +        util-linux-umount \
> > +        ${VIRTUAL-RUNTIME_init_manager} \
> > +        ${VIRTUAL-RUNTIME_dev_manager} \
> > +    ', '${INITRAMFS_SCRIPTS}', d)} \
> > +    base-passwd \
> > +"
> > 
> > # Ensure the initramfs only contains the bare minimum
> > IMAGE_FEATURES = ""
> > @@ -18,5 +34,3 @@ IMAGE_FSTYPES = "${INITRAMFS_FSTYPES}"
> > IMAGE_NAME_SUFFIX ?= ""
> > IMAGE_ROOTFS_SIZE = "8192"
> > IMAGE_ROOTFS_EXTRA_SPACE = "0"
> > -
> > -inherit image
> > -- 
> > 2.43.0
> > 
> > 
> > -=-=-=-=-=-=-=-=-=-=-=-
> > Links: You receive all messages sent to this group.
> > View/Reply Online (#214355): https://lists.openembedded.org/g/openembedded-core/message/214355
> > Mute This Topic: https://lists.openembedded.org/mt/112087527/9418801
> > Group Owner: openembedded-core+owner@lists.openembedded.org
> > Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [koen.kooi@oss.qualcomm.com]
> > -=-=-=-=-=-=-=-=-=-=-=-
> > 

Re: [OE-core] [PATCH v3 04/11] core-image-initramfs-boot: add option to build systemd based initrd

[Koen Kooi]

> Op 7 apr 2025, om 08:12 heeft Mikko Rapeli <mikko.rapeli@linaro.org> het volgende geschreven:
> 
> Hi,
> 
> On Mon, Apr 07, 2025 at 08:01:41AM +0200, Koen Kooi wrote:
>> Op 4 apr 2025, om 18:29 heeft Mikko Rapeli via lists.openembedded.org <mikko.rapeli=linaro.org@lists.openembedded.org> het volgende geschreven:
>>> 
>>> If "systemd-initramfs" is in DISTRO_FEATURES then convert
>>> core-image-initramfs-boot from shell scripts to systemd.
>>> The resulting initramfs is much bigger than shell script one but
>>> supports much more features like disk encryption and TPM devices.
>>> Also includes udev which can load any drivers needed to mount
>>> rootfs.
>> 
>> Are packaged based kernel updates finally working with this?
> 
> Sorry, I don't get this question. What is package based kernel updates?

Using package management to update a kernel, e.g, 'opkg update ; opkg upgrade'.

regards,

Koen


> 
> Cheers,
> 
> -Mikko
> 
>> regards,
>> 
>> Koen
>> 
>>> 
>>> Signed-off-by: Mikko Rapeli <mikko.rapeli@linaro.org>
>>> ---
>>> .../images/core-image-initramfs-boot.bb       | 20 ++++++++++++++++---
>>> 1 file changed, 17 insertions(+), 3 deletions(-)
>>> 
>>> diff --git a/meta/recipes-core/images/core-image-initramfs-boot.bb b/meta/recipes-core/images/core-image-initramfs-boot.bb
>>> index 7258944751..c66c28db76 100644
>>> --- a/meta/recipes-core/images/core-image-initramfs-boot.bb
>>> +++ b/meta/recipes-core/images/core-image-initramfs-boot.bb
>>> @@ -4,7 +4,23 @@ LICENSE = "MIT"
>>> 
>>> INITRAMFS_SCRIPTS ?= "initramfs-framework-base initramfs-module-udev"
>>> 
>>> -PACKAGE_INSTALL = "${INITRAMFS_SCRIPTS} ${VIRTUAL-RUNTIME_base-utils} base-passwd"
>>> +inherit image
>>> +
>>> +PACKAGE_INSTALL = " \
>>> +    ${VIRTUAL-RUNTIME_base-utils} \
>>> +    ${@bb.utils.contains('DISTRO_FEATURES', 'systemd-initramfs', ' \
>>> +        base-files \
>>> +        coreutils \
>>> +        e2fsprogs-mke2fs \
>>> +        os-release-initrd \
>>> +        util-linux-blkid \
>>> +        util-linux-mount \
>>> +        util-linux-umount \
>>> +        ${VIRTUAL-RUNTIME_init_manager} \
>>> +        ${VIRTUAL-RUNTIME_dev_manager} \
>>> +    ', '${INITRAMFS_SCRIPTS}', d)} \
>>> +    base-passwd \
>>> +"
>>> 
>>> # Ensure the initramfs only contains the bare minimum
>>> IMAGE_FEATURES = ""
>>> @@ -18,5 +34,3 @@ IMAGE_FSTYPES = "${INITRAMFS_FSTYPES}"
>>> IMAGE_NAME_SUFFIX ?= ""
>>> IMAGE_ROOTFS_SIZE = "8192"
>>> IMAGE_ROOTFS_EXTRA_SPACE = "0"
>>> -
>>> -inherit image
>>> -- 
>>> 2.43.0
>>> 
>>> 
>>> -=-=-=-=-=-=-=-=-=-=-=-
>>> Links: You receive all messages sent to this group.
>>> View/Reply Online (#214355): https://lists.openembedded.org/g/openembedded-core/message/214355
>>> Mute This Topic: https://lists.openembedded.org/mt/112087527/9418801
>>> Group Owner: openembedded-core+owner@lists.openembedded.org
>>> Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [koen.kooi@oss.qualcomm.com]
>>> -=-=-=-=-=-=-=-=-=-=-=-

Re: [OE-core] [PATCH v3 04/11] core-image-initramfs-boot: add option to build systemd based initrd

[Mikko Rapeli]

Hi,

On Mon, Apr 07, 2025 at 10:58:12AM +0200, Koen Kooi wrote:
> 
> 
> > Op 7 apr 2025, om 08:12 heeft Mikko Rapeli <mikko.rapeli@linaro.org> het volgende geschreven:
> > 
> > Hi,
> > 
> > On Mon, Apr 07, 2025 at 08:01:41AM +0200, Koen Kooi wrote:
> >> Op 4 apr 2025, om 18:29 heeft Mikko Rapeli via lists.openembedded.org <mikko.rapeli=linaro.org@lists.openembedded.org> het volgende geschreven:
> >>> 
> >>> If "systemd-initramfs" is in DISTRO_FEATURES then convert
> >>> core-image-initramfs-boot from shell scripts to systemd.
> >>> The resulting initramfs is much bigger than shell script one but
> >>> supports much more features like disk encryption and TPM devices.
> >>> Also includes udev which can load any drivers needed to mount
> >>> rootfs.
> >> 
> >> Are packaged based kernel updates finally working with this?
> > 
> > Sorry, I don't get this question. What is package based kernel updates?
> 
> Using package management to update a kernel, e.g, 'opkg update ; opkg upgrade'.

Yocto project in general does not test binary package update paths. These
patches are still tied to the yocto build environment and don't generate
initrd on the running systemd based on files in the rootfs. That support
is currently not available in yocto, AFAIK.

These changes only enable building systemd based initrd image from the yocto
build environment.

One of the usecases which I'm testing is UEFI secure boot where
kernel and initrd are signed with keys which are not availeble
in the rootfs. The keys are only available on the yocto build
machine. The UEFI firmware (u-boot based,
https://gitlab.com/Linaro/trustedsubstrate/meta-ts ) checks
that kernel and initrd in the UKI binary are signed with
expected keys before allowing boot to continue. systemd
based initrd is then able to use TPM in more advance ways
that shell script based yocto initrd framework to e.g.
encrypt rootfs.

Cheers,

-Mikko

Re: [OE-core] [PATCH v3 04/11] core-image-initramfs-boot: add option to build systemd based initrd

[Richard Purdie]

On Fri, 2025-04-04 at 19:29 +0300, Mikko Rapeli via lists.openembedded.org wrote:
> If "systemd-initramfs" is in DISTRO_FEATURES then convert
> core-image-initramfs-boot from shell scripts to systemd.
> The resulting initramfs is much bigger than shell script one but
> supports much more features like disk encryption and TPM devices.
> Also includes udev which can load any drivers needed to mount
> rootfs.
> 
> Signed-off-by: Mikko Rapeli <mikko.rapeli@linaro.org>
> ---
>  .../images/core-image-initramfs-boot.bb       | 20 ++++++++++++++++---
>  1 file changed, 17 insertions(+), 3 deletions(-)
> 
> diff --git a/meta/recipes-core/images/core-image-initramfs-boot.bb b/meta/recipes-core/images/core-image-initramfs-boot.bb
> index 7258944751..c66c28db76 100644
> --- a/meta/recipes-core/images/core-image-initramfs-boot.bb
> +++ b/meta/recipes-core/images/core-image-initramfs-boot.bb
> @@ -4,7 +4,23 @@ LICENSE = "MIT"
>  
>  INITRAMFS_SCRIPTS ?= "initramfs-framework-base initramfs-module-udev"
>  
> -PACKAGE_INSTALL = "${INITRAMFS_SCRIPTS} ${VIRTUAL-RUNTIME_base-utils} base-passwd"
> +inherit image
> +
> +PACKAGE_INSTALL = " \
> +    ${VIRTUAL-RUNTIME_base-utils} \
> +    ${@bb.utils.contains('DISTRO_FEATURES', 'systemd-initramfs', ' \
> +        base-files \
> +        coreutils \
> +        e2fsprogs-mke2fs \
> +        os-release-initrd \
> +        util-linux-blkid \
> +        util-linux-mount \
> +        util-linux-umount \
> +        ${VIRTUAL-RUNTIME_init_manager} \
> +        ${VIRTUAL-RUNTIME_dev_manager} \
> +    ', '${INITRAMFS_SCRIPTS}', d)} \
> +    base-passwd \
> +"
>  
>  # Ensure the initramfs only contains the bare minimum
>  IMAGE_FEATURES = ""
> @@ -18,5 +34,3 @@ IMAGE_FSTYPES = "${INITRAMFS_FSTYPES}"
>  IMAGE_NAME_SUFFIX ?= ""
>  IMAGE_ROOTFS_SIZE = "8192"
>  IMAGE_ROOTFS_EXTRA_SPACE = "0"
> -
> -inherit image

Given this effectively completely changes the image, would we be better
just defining a different image recipe for the systemd based initramfs?

Cheers,

Richard

Re: [OE-core] [PATCH v3 04/11] core-image-initramfs-boot: add option to build systemd based initrd

[Mikko Rapeli]

Hi,

On Thu, Apr 10, 2025 at 01:45:13PM +0100, Richard Purdie wrote:
> On Fri, 2025-04-04 at 19:29 +0300, Mikko Rapeli via lists.openembedded.org wrote:
> > If "systemd-initramfs" is in DISTRO_FEATURES then convert
> > core-image-initramfs-boot from shell scripts to systemd.
> > The resulting initramfs is much bigger than shell script one but
> > supports much more features like disk encryption and TPM devices.
> > Also includes udev which can load any drivers needed to mount
> > rootfs.
> > 
> > Signed-off-by: Mikko Rapeli <mikko.rapeli@linaro.org>
> > ---
> > �.../images/core-image-initramfs-boot.bb������ | 20 ++++++++++++++++---
> > �1 file changed, 17 insertions(+), 3 deletions(-)
> > 
> > diff --git a/meta/recipes-core/images/core-image-initramfs-boot.bb b/meta/recipes-core/images/core-image-initramfs-boot.bb
> > index 7258944751..c66c28db76 100644
> > --- a/meta/recipes-core/images/core-image-initramfs-boot.bb
> > +++ b/meta/recipes-core/images/core-image-initramfs-boot.bb
> > @@ -4,7 +4,23 @@ LICENSE = "MIT"
> > �
> > �INITRAMFS_SCRIPTS ?= "initramfs-framework-base initramfs-module-udev"
> > �
> > -PACKAGE_INSTALL = "${INITRAMFS_SCRIPTS} ${VIRTUAL-RUNTIME_base-utils} base-passwd"
> > +inherit image
> > +
> > +PACKAGE_INSTALL = " \
> > +��� ${VIRTUAL-RUNTIME_base-utils} \
> > +��� ${@bb.utils.contains('DISTRO_FEATURES', 'systemd-initramfs', ' \
> > +������� base-files \
> > +������� coreutils \
> > +������� e2fsprogs-mke2fs \
> > +������� os-release-initrd \
> > +������� util-linux-blkid \
> > +������� util-linux-mount \
> > +������� util-linux-umount \
> > +������� ${VIRTUAL-RUNTIME_init_manager} \
> > +������� ${VIRTUAL-RUNTIME_dev_manager} \
> > +��� ', '${INITRAMFS_SCRIPTS}', d)} \
> > +��� base-passwd \
> > +"
> > �
> > �# Ensure the initramfs only contains the bare minimum
> > �IMAGE_FEATURES = ""
> > @@ -18,5 +34,3 @@ IMAGE_FSTYPES = "${INITRAMFS_FSTYPES}"
> > �IMAGE_NAME_SUFFIX ?= ""
> > �IMAGE_ROOTFS_SIZE = "8192"
> > �IMAGE_ROOTFS_EXTRA_SPACE = "0"
> > -
> > -inherit image
> 
> Given this effectively completely changes the image, would we be better
> just defining a different image recipe for the systemd based initramfs?

I don't know. At least for testing purposes switching with
DISTRO_FEATURE is relatively easy. Though exact same thing
would work with INITRAMFS_IMAGE variable. I just started
with this approach but can change it if you prefer a
separate recipe.

For upper level layers it may be tricky if they need to modify
something but need to deal with two different
image recipe names and can't just have all in a single
bbappend.

Cheers,

-Mikko

[PATCH v3 05/11] core-image-initramfs-boot: don't install RRECOMMENDS to reduce size

[Mikko Rapeli]

Disables recommends to only install important packages.
Disable machine specific additions which are meant for
full rootfs boot. For example on genericarm64, full
set of kernel modules and WiFi related firmware is
in the machine recommends and those are not needed when
booting to rootfs from an initrd. These reduce systemd
initrd size from 200Mb to 54Mb.

Since recommends are not automatically installed anymore,
explicitly add initramfs-module-rootfs, busybox-udhcpc and libkmod
to shell script based initrd. initramfs-module-rootfs is needed to
mount the rootfs. Installing busybox-udhcpc and libkmod
for backwards compatibility.

Not installing openssl-conf, openssl-ossl-module-legacy or
ldconfig packages since they don't seem essential in initrd
to mount the rootfs.

Signed-off-by: Mikko Rapeli <mikko.rapeli@linaro.org>
---
 meta/recipes-core/images/core-image-initramfs-boot.bb | 11 ++++++++++-
 1 file changed, 10 insertions(+), 1 deletion(-)

diff --git a/meta/recipes-core/images/core-image-initramfs-boot.bb b/meta/recipes-core/images/core-image-initramfs-boot.bb
index c66c28db76..99388476ac 100644
--- a/meta/recipes-core/images/core-image-initramfs-boot.bb
+++ b/meta/recipes-core/images/core-image-initramfs-boot.bb
@@ -2,7 +2,7 @@ SUMMARY = "Basic initramfs to boot a fully-featured rootfs"
 DESCRIPTION = "Small initramfs that contains just udev and init, to find the real rootfs."
 LICENSE = "MIT"
 
-INITRAMFS_SCRIPTS ?= "initramfs-framework-base initramfs-module-udev"
+INITRAMFS_SCRIPTS ?= "initramfs-framework-base initramfs-module-udev initramfs-module-rootfs"
 
 inherit image
 
@@ -20,8 +20,17 @@ PACKAGE_INSTALL = " \
         ${VIRTUAL-RUNTIME_dev_manager} \
     ', '${INITRAMFS_SCRIPTS}', d)} \
     base-passwd \
+    busybox-udhcpc \
+    libkmod \
 "
 
+# reduce size
+NO_RECOMMENDATIONS = "1"
+
+# don't install automatically, pick manually instead
+MACHINE_EXTRA_RDEPENDS = ""
+MACHINE_EXTRA_RRECOMMENDS = ""
+
 # Ensure the initramfs only contains the bare minimum
 IMAGE_FEATURES = ""
 IMAGE_LINGUAS = ""
-- 
2.43.0

Re: [OE-core] [PATCH v3 05/11] core-image-initramfs-boot: don't install RRECOMMENDS to reduce size

[Richard Purdie]

On Fri, 2025-04-04 at 19:29 +0300, Mikko Rapeli via
lists.openembedded.org wrote:
> Disables recommends to only install important packages.
> Disable machine specific additions which are meant for
> full rootfs boot. For example on genericarm64, full
> set of kernel modules and WiFi related firmware is
> in the machine recommends and those are not needed when
> booting to rootfs from an initrd. These reduce systemd
> initrd size from 200Mb to 54Mb.
> 
> Since recommends are not automatically installed anymore,
> explicitly add initramfs-module-rootfs, busybox-udhcpc and libkmod
> to shell script based initrd. initramfs-module-rootfs is needed to
> mount the rootfs. Installing busybox-udhcpc and libkmod
> for backwards compatibility.
> 
> Not installing openssl-conf, openssl-ossl-module-legacy or
> ldconfig packages since they don't seem essential in initrd
> to mount the rootfs.
> 
> Signed-off-by: Mikko Rapeli <mikko.rapeli@linaro.org>
> ---
>  meta/recipes-core/images/core-image-initramfs-boot.bb | 11
> ++++++++++-
>  1 file changed, 10 insertions(+), 1 deletion(-)
> 
> diff --git a/meta/recipes-core/images/core-image-initramfs-boot.bb
> b/meta/recipes-core/images/core-image-initramfs-boot.bb
> index c66c28db76..99388476ac 100644
> --- a/meta/recipes-core/images/core-image-initramfs-boot.bb
> +++ b/meta/recipes-core/images/core-image-initramfs-boot.bb
> @@ -2,7 +2,7 @@ SUMMARY = "Basic initramfs to boot a fully-featured
> rootfs"
>  DESCRIPTION = "Small initramfs that contains just udev and init, to
> find the real rootfs."
>  LICENSE = "MIT"
>  
> -INITRAMFS_SCRIPTS ?= "initramfs-framework-base initramfs-module-
> udev"
> +INITRAMFS_SCRIPTS ?= "initramfs-framework-base initramfs-module-udev
> initramfs-module-rootfs"
>  
>  inherit image
>  
> @@ -20,8 +20,17 @@ PACKAGE_INSTALL = " \
>          ${VIRTUAL-RUNTIME_dev_manager} \
>      ', '${INITRAMFS_SCRIPTS}', d)} \
>      base-passwd \
> +    busybox-udhcpc \
> +    libkmod \
>  "
>  
> +# reduce size
> +NO_RECOMMENDATIONS = "1"
> +
> +# don't install automatically, pick manually instead
> +MACHINE_EXTRA_RDEPENDS = ""

I'd probably accept that removing the rrecommends below is probably ok
for the initramfs but I'm not convinced removing rdepends is a good
move. If that works, are the things in question really rdepends for the
machine?

> +MACHINE_EXTRA_RRECOMMENDS = ""
> +
>  # Ensure the initramfs only contains the bare minimum
>  IMAGE_FEATURES = ""
>  IMAGE_LINGUAS = ""

Cheers,

Richard

Re: [OE-core] [PATCH v3 05/11] core-image-initramfs-boot: don't install RRECOMMENDS to reduce size

[Mikko Rapeli]

Hi,

On Thu, Apr 10, 2025 at 01:47:27PM +0100, Richard Purdie wrote:
> On Fri, 2025-04-04 at 19:29 +0300, Mikko Rapeli via
> lists.openembedded.org wrote:
> > Disables recommends to only install important packages.
> > Disable machine specific additions which are meant for
> > full rootfs boot. For example on genericarm64, full
> > set of kernel modules and WiFi related firmware is
> > in the machine recommends and those are not needed when
> > booting to rootfs from an initrd. These reduce systemd
> > initrd size from 200Mb to 54Mb.
> > 
> > Since recommends are not automatically installed anymore,
> > explicitly add initramfs-module-rootfs, busybox-udhcpc and libkmod
> > to shell script based initrd. initramfs-module-rootfs is needed to
> > mount the rootfs. Installing busybox-udhcpc and libkmod
> > for backwards compatibility.
> > 
> > Not installing openssl-conf, openssl-ossl-module-legacy or
> > ldconfig packages since they don't seem essential in initrd
> > to mount the rootfs.
> > 
> > Signed-off-by: Mikko Rapeli <mikko.rapeli@linaro.org>
> > ---
> > �meta/recipes-core/images/core-image-initramfs-boot.bb | 11
> > ++++++++++-
> > �1 file changed, 10 insertions(+), 1 deletion(-)
> > 
> > diff --git a/meta/recipes-core/images/core-image-initramfs-boot.bb
> > b/meta/recipes-core/images/core-image-initramfs-boot.bb
> > index c66c28db76..99388476ac 100644
> > --- a/meta/recipes-core/images/core-image-initramfs-boot.bb
> > +++ b/meta/recipes-core/images/core-image-initramfs-boot.bb
> > @@ -2,7 +2,7 @@ SUMMARY = "Basic initramfs to boot a fully-featured
> > rootfs"
> > �DESCRIPTION = "Small initramfs that contains just udev and init, to
> > find the real rootfs."
> > �LICENSE = "MIT"
> > �
> > -INITRAMFS_SCRIPTS ?= "initramfs-framework-base initramfs-module-
> > udev"
> > +INITRAMFS_SCRIPTS ?= "initramfs-framework-base initramfs-module-udev
> > initramfs-module-rootfs"
> > �
> > �inherit image
> > �
> > @@ -20,8 +20,17 @@ PACKAGE_INSTALL = " \
> > �������� ${VIRTUAL-RUNTIME_dev_manager} \
> > ���� ', '${INITRAMFS_SCRIPTS}', d)} \
> > ���� base-passwd \
> > +��� busybox-udhcpc \
> > +��� libkmod \
> > �"
> > �
> > +# reduce size
> > +NO_RECOMMENDATIONS = "1"
> > +
> > +# don't install automatically, pick manually instead
> > +MACHINE_EXTRA_RDEPENDS = ""
> 
> I'd probably accept that removing the rrecommends below is probably ok
> for the initramfs but I'm not convinced removing rdepends is a good
> move. If that works, are the things in question really rdepends for the
> machine?

If MACHINE_EXTRA_RDEPENDS is for:

"A list of machine-specific packages to install as part of the image
being built that are __not essential for the machine to boot__. However,
the build process for more fully-featured images depends on the packages
being present."

Then I would think they are not needed for initramfs usecases.

Cheers,

-Mikko

[PATCH v3 06/11] core-image-initramfs-boot: install kernel-initrd-modules by default

[Mikko Rapeli]

Most real machines in core set

MACHINE_EXTRA_RRECOMMENDS = "kernel-modules"

which means that all images including initrd have all kernel
modules by default. Only default qemu machines don't do this
and instead the kernel configs there seem to include enough
drivers built-in to mount the rootfs, and this may be
reflected in qemu machine configuration e.g. which
block device emulation is used.

Since for initrd "boot to rootfs" usecase full set
of kernel modules way too much, use the subset
from kernel-initrd-modules which should work
on all machines. If not, then the KERNEL_INITRD_MODULES_REGEX
needs to be fixed for the machine or for everyone
to include any missing driver classes.

Same could be achieved by introducing a
MACHINE_EXTRA_INITRD or similar variable for machine
configs to define extra packages for initrd usecase
of mounting target rootfs. I have not done this for now
since currently only user is kernel-initrd-modules.
Installing kernel-initrd-modules by default enables
the machine specific kernel configs to move drivers
from built-in to modules. The other e.g. firmware packages
installed via MACHINE_EXTRA variables in core machines
are not needed to mount the rootfs.

Signed-off-by: Mikko Rapeli <mikko.rapeli@linaro.org>
---
 meta/recipes-core/images/core-image-initramfs-boot.bb | 1 +
 1 file changed, 1 insertion(+)

diff --git a/meta/recipes-core/images/core-image-initramfs-boot.bb b/meta/recipes-core/images/core-image-initramfs-boot.bb
index 99388476ac..743e0da132 100644
--- a/meta/recipes-core/images/core-image-initramfs-boot.bb
+++ b/meta/recipes-core/images/core-image-initramfs-boot.bb
@@ -21,6 +21,7 @@ PACKAGE_INSTALL = " \
     ', '${INITRAMFS_SCRIPTS}', d)} \
     base-passwd \
     busybox-udhcpc \
+    kernel-initrd-modules \
     libkmod \
 "
 
-- 
2.43.0

[PATCH v3 07/11] oeqa selftest uki.py: add aarch64/arm test with systemd based initrd

[Mikko Rapeli]

Use core-image-initramfs-boot with systemd to boot via UKI on
arm/aarch64. Tested on qemuarm, qemuarm64 and genericarm64
on aarch64 build host. The machines have different image
and qemuboot configs so they need to be configured in test.

Signed-off-by: Mikko Rapeli <mikko.rapeli@linaro.org>
---
 meta/lib/oeqa/selftest/cases/uki.py | 76 +++++++++++++++++++++++++++++
 1 file changed, 76 insertions(+)

diff --git a/meta/lib/oeqa/selftest/cases/uki.py b/meta/lib/oeqa/selftest/cases/uki.py
index 9a1aa4e269..4830fb3403 100644
--- a/meta/lib/oeqa/selftest/cases/uki.py
+++ b/meta/lib/oeqa/selftest/cases/uki.py
@@ -139,3 +139,79 @@ IMAGE_CLASSES:remove = 'testimage'
             cmd = "echo $( cat /sys/firmware/efi/efivars/LoaderEntrySelected-4a67b082-0a4c-41cf-b6c7-440b29bb8c4f ) | grep '%s'" % (uki_filename)
             status, output = qemu.run_serial(cmd)
             self.assertEqual(1, status, 'Failed to run command "%s": %s' % (cmd, output))
+
+    @skipIfNotArch(['aarch64', 'arm'])
+    @OETestTag("runqemu")
+    def test_uki_boot_systemd_initrd(self):
+        """Build and boot into UEFI firmware (u-boot), systemd-boot, initrd with systemd, rootfs with systemd"""
+        image = "core-image-base"
+        runqemu_params = get_bb_var('TEST_RUNQEMUPARAMS', image) or ""
+        cmd = "runqemu %s nographic serial wic" % (runqemu_params)
+
+        self.write_config("""
+# efi firmware must load systemd-boot, not grub
+EFI_PROVIDER = "systemd-boot"
+
+# image format must be wic, needs esp partition for firmware etc
+IMAGE_FSTYPES:pn-%s:append = " wic"
+WKS_FILE = "efi-uki-bootdisk.wks.in"
+
+# efi, uki and systemd features must be enabled
+INIT_MANAGER = "systemd"
+DISTRO_FEATURES += "systemd-initramfs"
+MACHINE_FEATURES:append = " efi"
+IMAGE_CLASSES:append:pn-core-image-base = " uki"
+
+# uki embeds also an initrd
+INITRAMFS_IMAGE = "core-image-initramfs-boot"
+
+# runqemu must not load kernel separately, it's in the uki
+QB_KERNEL_ROOT = ""
+QB_DEFAULT_KERNEL = "none"
+
+# u-boot, not all qemu* machines set this correctly
+QB_DEFAULT_BIOS = "u-boot.bin"
+# machines may not set this correctly
+QB_DEFAULT_FSTYPE = "wic"
+
+# u-boot needs to find ESP partition so use virtio block device instead of default scsi
+QB_ROOTFS_OPT = "-drive id=root,file=@ROOTFS@,if=none,format=raw -device virtio-blk-pci,drive=root"
+QB_DRIVE_TYPE = "/dev/vd"
+
+# boot command line provided via uki, not via bootloader
+UKI_CMDLINE = "rootwait root=LABEL=root"
+# enable if debug output is needed
+# UKI_CMDLINE += "systemd.log_level=debug systemd.log_target=console systemd.journald.forward_to_console=1"
+
+# disable kvm, breaks boot
+QEMU_USE_KVM = ""
+
+IMAGE_CLASSES:remove = 'testimage'
+""" % (image))
+
+        uki_filename = get_bb_var('UKI_FILENAME', image)
+
+        bitbake(image + " u-boot")
+        with runqemu(image, ssh=False, launch_cmd=cmd) as qemu:
+            self.assertTrue(qemu.runner.logged, "Failed: %s" % cmd)
+
+            # Verify from efivars that firmware was:
+            # aarch64
+            cmd = "echo $( cat /sys/firmware/efi/efivars/LoaderFirmwareInfo-4a67b082-0a4c-41cf-b6c7-440b29bb8c4f ) | grep 'Das U-Boot'"
+            status, output = qemu.run_serial(cmd)
+            self.assertEqual(1, status, 'Failed to run command "%s": %s' % (cmd, output))
+
+            # Check that systemd-boot was the loader
+            cmd = "echo $( cat /sys/firmware/efi/efivars/LoaderInfo-4a67b082-0a4c-41cf-b6c7-440b29bb8c4f ) | grep systemd-boot"
+            status, output = qemu.run_serial(cmd)
+            self.assertEqual(1, status, 'Failed to run command "%s": %s' % (cmd, output))
+
+            # Check that systemd-stub was used
+            cmd = "echo $( cat /sys/firmware/efi/efivars/StubInfo-4a67b082-0a4c-41cf-b6c7-440b29bb8c4f ) | grep systemd-stub"
+            status, output = qemu.run_serial(cmd)
+            self.assertEqual(1, status, 'Failed to run command "%s": %s' % (cmd, output))
+
+            # Check that the compiled uki file was booted into
+            cmd = "echo $( cat /sys/firmware/efi/efivars/LoaderEntrySelected-4a67b082-0a4c-41cf-b6c7-440b29bb8c4f ) | grep '%s'" % (uki_filename)
+            status, output = qemu.run_serial(cmd)
+            self.assertEqual(1, status, 'Failed to run command "%s": %s' % (cmd, output))
-- 
2.43.0

[PATCH v3 08/11] test_efi_plugin_plain_systemd-boot: don't set console

[Mikko Rapeli]

This effectively disables the boot time serial console
so that kernel and initrd logs are not visible which
makes debugging boot failures hard. The logs are
not too verbose, around 270 lines, and can be reduced
with kernel side settings if needed. For example
"loglevel=4" on kernel command line reduces the
output to only warning messages.

Signed-off-by: Mikko Rapeli <mikko.rapeli@linaro.org>
---
 meta-selftest/wic/test_efi_plugin_plain_systemd-boot.wks | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meta-selftest/wic/test_efi_plugin_plain_systemd-boot.wks b/meta-selftest/wic/test_efi_plugin_plain_systemd-boot.wks
index 2745c19e85..83f136ac15 100644
--- a/meta-selftest/wic/test_efi_plugin_plain_systemd-boot.wks
+++ b/meta-selftest/wic/test_efi_plugin_plain_systemd-boot.wks
@@ -2,4 +2,4 @@
 part /boot --source bootimg-efi --sourceparams="loader=systemd-boot,initrd=${INITRAMFS_IMAGE}-${MACHINE}.${INITRAMFS_FSTYPES}" --active --align 1024 --use-uuid
 part / --source rootfs --fstype=ext4 --align 1024 --use-uuid
 
-bootloader  --timeout=0 --append="console=ttyS0,115200n8"
+bootloader  --timeout=0
-- 
2.43.0

[PATCH v3 09/11] image_types_wic.bbclass: capture verbose wic output by default

[Mikko Rapeli]

Call wic with --debug to capture logs from wic internals
so that it's clear which partitions get created and which
files get copied where. wic plugins contain for example
race conditions which don't install files at all and thus
images fail to boot and it's not possible to debug these without
something in wic task logs.

For example core-image-initramfs-boot do_image_wic
log is now 576 lines which is not excessive but very
important when debugging problems, especially race
conditions which are only hit in some builds in CI.

Signed-off-by: Mikko Rapeli <mikko.rapeli@linaro.org>
---
 meta/classes-recipe/image_types_wic.bbclass | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meta/classes-recipe/image_types_wic.bbclass b/meta/classes-recipe/image_types_wic.bbclass
index 1b422b6280..10888bc12b 100644
--- a/meta/classes-recipe/image_types_wic.bbclass
+++ b/meta/classes-recipe/image_types_wic.bbclass
@@ -72,7 +72,7 @@ IMAGE_CMD:wic () {
 	if [ -z "$wks" ]; then
 		bbfatal "No kickstart files from WKS_FILES were found: ${WKS_FILES}. Please set WKS_FILE or WKS_FILES appropriately."
 	fi
-	BUILDDIR="${TOPDIR}" PSEUDO_UNLOAD=1 wic create "$wks" --vars "${STAGING_DIR}/${MACHINE}/imgdata/" -e "${IMAGE_BASENAME}" -o "$build_wic/" -w "$tmp_wic" ${WIC_CREATE_EXTRA_ARGS}
+	BUILDDIR="${TOPDIR}" PSEUDO_UNLOAD=1 wic create --debug "$wks" --vars "${STAGING_DIR}/${MACHINE}/imgdata/" -e "${IMAGE_BASENAME}" -o "$build_wic/" -w "$tmp_wic" ${WIC_CREATE_EXTRA_ARGS}
 
 	# look to see if the user specifies a custom imager
 	IMAGER=direct
-- 
2.43.0

Re: [OE-core] [PATCH v3 09/11] image_types_wic.bbclass: capture verbose wic output by default

[Trevor Woerner]

On Fri 2025-04-04 @ 07:29:30 PM, Mikko Rapeli via lists.openembedded.org wrote:
> Call wic with --debug to capture logs from wic internals
> so that it's clear which partitions get created and which
> files get copied where. wic plugins contain for example
> race conditions which don't install files at all and thus
> images fail to boot and it's not possible to debug these without
> something in wic task logs.
> 
> For example core-image-initramfs-boot do_image_wic
> log is now 576 lines which is not excessive but very
> important when debugging problems, especially race
> conditions which are only hit in some builds in CI.
> 
> Signed-off-by: Mikko Rapeli <mikko.rapeli@linaro.org>
> ---
>  meta/classes-recipe/image_types_wic.bbclass | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/meta/classes-recipe/image_types_wic.bbclass b/meta/classes-recipe/image_types_wic.bbclass
> index 1b422b6280..10888bc12b 100644
> --- a/meta/classes-recipe/image_types_wic.bbclass
> +++ b/meta/classes-recipe/image_types_wic.bbclass
> @@ -72,7 +72,7 @@ IMAGE_CMD:wic () {
>  	if [ -z "$wks" ]; then
>  		bbfatal "No kickstart files from WKS_FILES were found: ${WKS_FILES}. Please set WKS_FILE or WKS_FILES appropriately."
>  	fi
> -	BUILDDIR="${TOPDIR}" PSEUDO_UNLOAD=1 wic create "$wks" --vars "${STAGING_DIR}/${MACHINE}/imgdata/" -e "${IMAGE_BASENAME}" -o "$build_wic/" -w "$tmp_wic" ${WIC_CREATE_EXTRA_ARGS}
> +	BUILDDIR="${TOPDIR}" PSEUDO_UNLOAD=1 wic create --debug "$wks" --vars "${STAGING_DIR}/${MACHINE}/imgdata/" -e "${IMAGE_BASENAME}" -o "$build_wic/" -w "$tmp_wic" ${WIC_CREATE_EXTRA_ARGS}
>  
>  	# look to see if the user specifies a custom imager
>  	IMAGER=direct

When I need to debug a wic issue, I add "--debug" to WIC_CREATE_EXTRA_ARGS in
my conf/local.conf, debug the issue, then submit the patch which modifies the
layer without any debugging remnants left behind. I can then either leave wic
debugging turned on, or turn it off for my builds as I see fit. Turning on
debugging by default for everyone using wic is not what we should be doing.
It will slow down builds, and will inflate log files... by miniscule amounts,
sure, but not the direction we should be taking.

If you feel there are messages that should be logged on every wic invocation
(on which I doubt there will be consensus) then they should be moved out from
behind a --debug flag. The whole point of a debug flag is to identify messages
that do not need to be logged on every build, but only under special
circumstances. Lots of software projects have debug flags; I can't think of any
that turn their debug flags on by default.

Re: [OE-core] [PATCH v3 09/11] image_types_wic.bbclass: capture verbose wic output by default

[Mikko Rapeli]

Hi,

On Mon, Apr 14, 2025 at 04:43:58PM -0400, Trevor Woerner wrote:
> On Fri 2025-04-04 @ 07:29:30 PM, Mikko Rapeli via lists.openembedded.org wrote:
> > Call wic with --debug to capture logs from wic internals
> > so that it's clear which partitions get created and which
> > files get copied where. wic plugins contain for example
> > race conditions which don't install files at all and thus
> > images fail to boot and it's not possible to debug these without
> > something in wic task logs.
> > 
> > For example core-image-initramfs-boot do_image_wic
> > log is now 576 lines which is not excessive but very
> > important when debugging problems, especially race
> > conditions which are only hit in some builds in CI.
> > 
> > Signed-off-by: Mikko Rapeli <mikko.rapeli@linaro.org>
> > ---
> >  meta/classes-recipe/image_types_wic.bbclass | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> > 
> > diff --git a/meta/classes-recipe/image_types_wic.bbclass b/meta/classes-recipe/image_types_wic.bbclass
> > index 1b422b6280..10888bc12b 100644
> > --- a/meta/classes-recipe/image_types_wic.bbclass
> > +++ b/meta/classes-recipe/image_types_wic.bbclass
> > @@ -72,7 +72,7 @@ IMAGE_CMD:wic () {
> >  	if [ -z "$wks" ]; then
> >  		bbfatal "No kickstart files from WKS_FILES were found: ${WKS_FILES}. Please set WKS_FILE or WKS_FILES appropriately."
> >  	fi
> > -	BUILDDIR="${TOPDIR}" PSEUDO_UNLOAD=1 wic create "$wks" --vars "${STAGING_DIR}/${MACHINE}/imgdata/" -e "${IMAGE_BASENAME}" -o "$build_wic/" -w "$tmp_wic" ${WIC_CREATE_EXTRA_ARGS}
> > +	BUILDDIR="${TOPDIR}" PSEUDO_UNLOAD=1 wic create --debug "$wks" --vars "${STAGING_DIR}/${MACHINE}/imgdata/" -e "${IMAGE_BASENAME}" -o "$build_wic/" -w "$tmp_wic" ${WIC_CREATE_EXTRA_ARGS}
> >  
> >  	# look to see if the user specifies a custom imager
> >  	IMAGER=direct
> 
> When I need to debug a wic issue, I add "--debug" to WIC_CREATE_EXTRA_ARGS in
> my conf/local.conf, debug the issue, then submit the patch which modifies the
> layer without any debugging remnants left behind. I can then either leave wic
> debugging turned on, or turn it off for my builds as I see fit. Turning on
> debugging by default for everyone using wic is not what we should be doing.
> It will slow down builds, and will inflate log files... by miniscule amounts,
> sure, but not the direction we should be taking.

I just disagree. Default logging should not be excessive but logs should
show at high level what the task and tools executed there are doing.
wic logs without --debug are completely useless in understanding what
happened when image was created. wic logs with --debug are not excessive
but show which partitions got created and which files copied where.
Full rootfs content is not shown so logging is not excessive.

> If you feel there are messages that should be logged on every wic invocation
> (on which I doubt there will be consensus) then they should be moved out from
> behind a --debug flag. The whole point of a debug flag is to identify messages
> that do not need to be logged on every build, but only under special
> circumstances. Lots of software projects have debug flags; I can't think of any
> that turn their debug flags on by default.

I want to see which files wic copies and where, e.g. ESP boot partition, and
which partitions it created. Without --debug wic does not log these.

Some people want all logs to be empty by default, I want them to be usable
when things go wrong in builds which I did not start or even fully control.

Cheers,

-Mikko

Re: [OE-core] [PATCH v3 09/11] image_types_wic.bbclass: capture verbose wic output by default

[Alexander Kanavin]

On Tue, 15 Apr 2025 at 07:20, Mikko Rapeli via lists.openembedded.org
<mikko.rapeli=linaro.org@lists.openembedded.org> wrote:

> Some people want all logs to be empty by default, I want them to be usable
> when things go wrong in builds which I did not start or even fully control.

Then maybe some of the debug messages should have their level raised to info?

Alex

[PATCH v3 10/11] wic bootimg-efi.py: fail build if no binaries installed

[Mikko Rapeli]

With systemd-boot, some builds included correct EFI
bootloader binaries and some not. Thus some builds
booted and some not. Check that some boot binary
was installed so that build fails if none were installed.

Signed-off-by: Mikko Rapeli <mikko.rapeli@linaro.org>
---
 scripts/lib/wic/plugins/source/bootimg-efi.py | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/scripts/lib/wic/plugins/source/bootimg-efi.py b/scripts/lib/wic/plugins/source/bootimg-efi.py
index 96c710bf77..20b1c36a46 100644
--- a/scripts/lib/wic/plugins/source/bootimg-efi.py
+++ b/scripts/lib/wic/plugins/source/bootimg-efi.py
@@ -341,6 +341,9 @@ class BootimgEFIPlugin(SourcePlugin):
                     cp_cmd = "cp -v -p %s/%s %s/EFI/BOOT/%s" % (kernel_dir, mod, hdddir, mod[8:])
                     out = exec_cmd(cp_cmd, True)
                     logger.debug("systemd-boot files:\n%s" % out)
+                # must have installed at least one EFI bootloader
+                out = exec_cmd("ls %s/EFI/BOOT/boot*.efi" % (hdddir), True)
+                logger.debug("Installed systemd-boot files:\n%s" % out)
             elif source_params['loader'] == 'uefi-kernel':
                 kernel = get_bitbake_var("KERNEL_IMAGETYPE")
                 if not kernel:
-- 
2.43.0

Re: [OE-core] [PATCH v3 10/11] wic bootimg-efi.py: fail build if no binaries installed

[Trevor Woerner]

On Fri 2025-04-04 @ 07:29:31 PM, Mikko Rapeli via lists.openembedded.org wrote:
> With systemd-boot, some builds included correct EFI
> bootloader binaries and some not. Thus some builds
> booted and some not. Check that some boot binary
> was installed so that build fails if none were installed.
> 
> Signed-off-by: Mikko Rapeli <mikko.rapeli@linaro.org>
> ---
>  scripts/lib/wic/plugins/source/bootimg-efi.py | 3 +++
>  1 file changed, 3 insertions(+)
> 
> diff --git a/scripts/lib/wic/plugins/source/bootimg-efi.py b/scripts/lib/wic/plugins/source/bootimg-efi.py
> index 96c710bf77..20b1c36a46 100644
> --- a/scripts/lib/wic/plugins/source/bootimg-efi.py
> +++ b/scripts/lib/wic/plugins/source/bootimg-efi.py
> @@ -341,6 +341,9 @@ class BootimgEFIPlugin(SourcePlugin):
>                      cp_cmd = "cp -v -p %s/%s %s/EFI/BOOT/%s" % (kernel_dir, mod, hdddir, mod[8:])
>                      out = exec_cmd(cp_cmd, True)
>                      logger.debug("systemd-boot files:\n%s" % out)
> +                # must have installed at least one EFI bootloader
> +                out = exec_cmd("ls %s/EFI/BOOT/boot*.efi" % (hdddir), True)
> +                logger.debug("Installed systemd-boot files:\n%s" % out)
>              elif source_params['loader'] == 'uefi-kernel':
>                  kernel = get_bitbake_var("KERNEL_IMAGETYPE")
>                  if not kernel:

At first glance I do not see how this code is checking for an invalid
scenario, and then failing the build should it be detected. Or are you
expecting the build to fail if the "ls" fails?

Re: [OE-core] [PATCH v3 10/11] wic bootimg-efi.py: fail build if no binaries installed

[Mikko Rapeli]

Hi,

On Mon, Apr 14, 2025 at 04:51:18PM -0400, Trevor Woerner wrote:
> On Fri 2025-04-04 @ 07:29:31 PM, Mikko Rapeli via lists.openembedded.org wrote:
> > With systemd-boot, some builds included correct EFI
> > bootloader binaries and some not. Thus some builds
> > booted and some not. Check that some boot binary
> > was installed so that build fails if none were installed.
> > 
> > Signed-off-by: Mikko Rapeli <mikko.rapeli@linaro.org>
> > ---
> >  scripts/lib/wic/plugins/source/bootimg-efi.py | 3 +++
> >  1 file changed, 3 insertions(+)
> > 
> > diff --git a/scripts/lib/wic/plugins/source/bootimg-efi.py b/scripts/lib/wic/plugins/source/bootimg-efi.py
> > index 96c710bf77..20b1c36a46 100644
> > --- a/scripts/lib/wic/plugins/source/bootimg-efi.py
> > +++ b/scripts/lib/wic/plugins/source/bootimg-efi.py
> > @@ -341,6 +341,9 @@ class BootimgEFIPlugin(SourcePlugin):
> >                      cp_cmd = "cp -v -p %s/%s %s/EFI/BOOT/%s" % (kernel_dir, mod, hdddir, mod[8:])
> >                      out = exec_cmd(cp_cmd, True)
> >                      logger.debug("systemd-boot files:\n%s" % out)
> > +                # must have installed at least one EFI bootloader
> > +                out = exec_cmd("ls %s/EFI/BOOT/boot*.efi" % (hdddir), True)
> > +                logger.debug("Installed systemd-boot files:\n%s" % out)
> >              elif source_params['loader'] == 'uefi-kernel':
> >                  kernel = get_bitbake_var("KERNEL_IMAGETYPE")
> >                  if not kernel:
> 
> At first glance I do not see how this code is checking for an invalid
> scenario, and then failing the build should it be detected. Or are you
> expecting the build to fail if the "ls" fails?

Yes, the shell commands run in "set -e" and failing "ls" will fail the build.

Cheers,

-Mikko

[PATCH v3 11/11] image_types_wic.bbclass: depend on grub-efi and systemd-boot on aarch64, systemd-boot on arm

[Mikko Rapeli]

On x86 family builds, grub and systemd-boot are always included and thus
get built and deployed before wic image builds. On aarch64 builds
that was not the case. Result is that some builds added systemd-boot binaries
to the wic image ESP partition and some not, though bugs in wic plugins
contributed here too since missing files were silently ignored.
Boot of such images fails since firmware is not able to load the
default EFI binaries.

Adding EFI_PROVIDER to WKS_FILE_DEPENDS_BOOTLOADERS is not possible
because of parsing order so adding grub-efi and systemd-boot
to aarch64 and systemd-boot to arm depends
which makes sure their do_deploy is always executed
before wic image is generated. Thus systemd-boot and grub
binaries will get copied from deploy directory to the wic
image ESP partition, and boot of the images succeeds.

Signed-off-by: Mikko Rapeli <mikko.rapeli@linaro.org>
---
 meta/classes-recipe/image_types_wic.bbclass | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/meta/classes-recipe/image_types_wic.bbclass b/meta/classes-recipe/image_types_wic.bbclass
index 10888bc12b..b2f450026d 100644
--- a/meta/classes-recipe/image_types_wic.bbclass
+++ b/meta/classes-recipe/image_types_wic.bbclass
@@ -113,6 +113,8 @@ WKS_FILE_DEPENDS_DEFAULT += "bmaptool-native cdrtools-native btrfs-tools-native
 # Unified kernel images need objcopy
 WKS_FILE_DEPENDS_DEFAULT += "virtual/cross-binutils"
 WKS_FILE_DEPENDS_BOOTLOADERS = ""
+WKS_FILE_DEPENDS_BOOTLOADERS:aarch64 = "grub-efi systemd-boot"
+WKS_FILE_DEPENDS_BOOTLOADERS:arm = "systemd-boot"
 WKS_FILE_DEPENDS_BOOTLOADERS:x86 = "syslinux grub-efi systemd-boot os-release"
 WKS_FILE_DEPENDS_BOOTLOADERS:x86-64 = "syslinux systemd-boot os-release"
 WKS_FILE_DEPENDS_BOOTLOADERS:x86-x32 = "syslinux grub-efi"
-- 
2.43.0

Re: [OE-core] [PATCH v3 11/11] image_types_wic.bbclass: depend on grub-efi and systemd-boot on aarch64, systemd-boot on arm

[Trevor Woerner]

On Fri 2025-04-04 @ 07:29:32 PM, Mikko Rapeli via lists.openembedded.org wrote:
> On x86 family builds, grub and systemd-boot are always included and thus
> get built and deployed before wic image builds. On aarch64 builds
> that was not the case. Result is that some builds added systemd-boot binaries
> to the wic image ESP partition and some not, though bugs in wic plugins
> contributed here too since missing files were silently ignored.
> Boot of such images fails since firmware is not able to load the
> default EFI binaries.
> 
> Adding EFI_PROVIDER to WKS_FILE_DEPENDS_BOOTLOADERS is not possible
> because of parsing order so adding grub-efi and systemd-boot
> to aarch64 and systemd-boot to arm depends
> which makes sure their do_deploy is always executed
> before wic image is generated. Thus systemd-boot and grub
> binaries will get copied from deploy directory to the wic
> image ESP partition, and boot of the images succeeds.
> 
> Signed-off-by: Mikko Rapeli <mikko.rapeli@linaro.org>
> ---
>  meta/classes-recipe/image_types_wic.bbclass | 2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/meta/classes-recipe/image_types_wic.bbclass b/meta/classes-recipe/image_types_wic.bbclass
> index 10888bc12b..b2f450026d 100644
> --- a/meta/classes-recipe/image_types_wic.bbclass
> +++ b/meta/classes-recipe/image_types_wic.bbclass
> @@ -113,6 +113,8 @@ WKS_FILE_DEPENDS_DEFAULT += "bmaptool-native cdrtools-native btrfs-tools-native
>  # Unified kernel images need objcopy
>  WKS_FILE_DEPENDS_DEFAULT += "virtual/cross-binutils"
>  WKS_FILE_DEPENDS_BOOTLOADERS = ""
> +WKS_FILE_DEPENDS_BOOTLOADERS:aarch64 = "grub-efi systemd-boot"
> +WKS_FILE_DEPENDS_BOOTLOADERS:arm = "systemd-boot"
>  WKS_FILE_DEPENDS_BOOTLOADERS:x86 = "syslinux grub-efi systemd-boot os-release"
>  WKS_FILE_DEPENDS_BOOTLOADERS:x86-64 = "syslinux systemd-boot os-release"
>  WKS_FILE_DEPENDS_BOOTLOADERS:x86-x32 = "syslinux grub-efi"

Will this not add grub-efi and systemd-boot to any arm-based (64- or 32-bit)
images that are built? I realize that many arm builds are moving towards
grub-efi and systemd-boot, but I'm pretty sure there still exist many that use
U-Boot by itself, and for these builds adding extra, unused code will not be
appreciated.

If anything, this should be behind one or more appropriate *_FEATUREs.

Re: [OE-core] [PATCH v3 11/11] image_types_wic.bbclass: depend on grub-efi and systemd-boot on aarch64, systemd-boot on arm

[Mikko Rapeli]

Hi,

On Mon, Apr 14, 2025 at 04:48:50PM -0400, Trevor Woerner wrote:
> On Fri 2025-04-04 @ 07:29:32 PM, Mikko Rapeli via lists.openembedded.org wrote:
> > On x86 family builds, grub and systemd-boot are always included and thus
> > get built and deployed before wic image builds. On aarch64 builds
> > that was not the case. Result is that some builds added systemd-boot binaries
> > to the wic image ESP partition and some not, though bugs in wic plugins
> > contributed here too since missing files were silently ignored.
> > Boot of such images fails since firmware is not able to load the
> > default EFI binaries.
> > 
> > Adding EFI_PROVIDER to WKS_FILE_DEPENDS_BOOTLOADERS is not possible
> > because of parsing order so adding grub-efi and systemd-boot
> > to aarch64 and systemd-boot to arm depends
> > which makes sure their do_deploy is always executed
> > before wic image is generated. Thus systemd-boot and grub
> > binaries will get copied from deploy directory to the wic
> > image ESP partition, and boot of the images succeeds.
> > 
> > Signed-off-by: Mikko Rapeli <mikko.rapeli@linaro.org>
> > ---
> >  meta/classes-recipe/image_types_wic.bbclass | 2 ++
> >  1 file changed, 2 insertions(+)
> > 
> > diff --git a/meta/classes-recipe/image_types_wic.bbclass b/meta/classes-recipe/image_types_wic.bbclass
> > index 10888bc12b..b2f450026d 100644
> > --- a/meta/classes-recipe/image_types_wic.bbclass
> > +++ b/meta/classes-recipe/image_types_wic.bbclass
> > @@ -113,6 +113,8 @@ WKS_FILE_DEPENDS_DEFAULT += "bmaptool-native cdrtools-native btrfs-tools-native
> >  # Unified kernel images need objcopy
> >  WKS_FILE_DEPENDS_DEFAULT += "virtual/cross-binutils"
> >  WKS_FILE_DEPENDS_BOOTLOADERS = ""
> > +WKS_FILE_DEPENDS_BOOTLOADERS:aarch64 = "grub-efi systemd-boot"
> > +WKS_FILE_DEPENDS_BOOTLOADERS:arm = "systemd-boot"
> >  WKS_FILE_DEPENDS_BOOTLOADERS:x86 = "syslinux grub-efi systemd-boot os-release"
> >  WKS_FILE_DEPENDS_BOOTLOADERS:x86-64 = "syslinux systemd-boot os-release"
> >  WKS_FILE_DEPENDS_BOOTLOADERS:x86-x32 = "syslinux grub-efi"
> 
> Will this not add grub-efi and systemd-boot to any arm-based (64- or 32-bit)
> images that are built? I realize that many arm builds are moving towards
> grub-efi and systemd-boot, but I'm pretty sure there still exist many that use
> U-Boot by itself, and for these builds adding extra, unused code will not be
> appreciated.
> 
> If anything, this should be behind one or more appropriate *_FEATUREs.

Sadly this variable is in DEPENDS and thus parsed early and thus can't contain
complex statements, not even ${EFI_PROVIDER}. If this is not done, result is build failure
from wic (with patch from this series applied) or worse silently missing EFI bootloader files
from wic images and a boot hang. And these on only some builds which did not run
do_deploy of grub-efi/systemd-boot before do_image_wic.

Here I copy existing behavior from other archs which I presume had similar issues.

If you don't use grub or systemd-boot, then WKS_FILE_DEPENDS can be set to empty
in distro, machine, image etc configs.

Cheers,

-Mikko

Re: [OE-core] [PATCH v3 00/11] systemd based initrd and modular kernel support

[Mathieu Dubois-Briand]

On Fri Apr 4, 2025 at 6:29 PM CEST, Mikko Rapeli via lists.openembedded.org wrote:
> systemd based initrd supports more security, encryption etc features
> than custom shell script ones but oe-core lacks support for it.
> Convert core-image-initramfs-boot to create systemd based initrd
> if "systemd-initramfs" is set in DISTRO_FEATURES. Includes a test
> for this initrd to mount rootfs via Unified Kernel Image uki.py.
>
> Sadly the boot time is really slow, e.g. over 30 seconds with
> systemd based initrd. One of the major reasons is the large
> amount of kernel modules built into the linux-yocto kernel and
> processing of their udev events in userspace. Thus add
> kernel-initrd-modules meta package to easily install
> subset of all kernel modules to initrd. The subset
> supports "mount rootfs from any block device" but
> doesn't include graphics, UBS etc support. Without this
> generated meta package, initrd recipe needs to manually define
> which exact kernel modules to include which breaks if
> those modules are built into the kernel. Thus the initrd
> becomes machine and kernel config specific and hard to maintain.
> With this meta package a generic initrd can be created.
>
> Separate changes to linux-yocto compile a lot more drivers
> as modules but they depend on these initrd changes.
>

Hi Mikko,

Thanks for your patch.

I believe one of these wic related patches is responsible of some
oe-selftest failures we can see on the autobuilder:

2025-04-06 15:51:49,317 - oe-selftest - INFO - wic.Wic.test_permissions (subunit.RemotedTestCase)
2025-04-06 15:51:49,318 - oe-selftest - INFO -  ... FAIL

...

ERROR: When reparsing /tmp/selftest-fetchsrayuxoq/test.bb:do_checkuri, the basehash value changed from 84b9e23a83a764e7a5d8a96ee523199e2b1c604f4280a45030e248de0ff52962 to 4123da244f465feffecb2b4fd2b132b64851981ec2fb70bf9445df8b0ea6a69e. The metadata is not deterministic and this needs to be fixed.
ERROR: The following commands may help:
ERROR: $ bitbake test -cdo_checkuri -Snone
ERROR: Then:
ERROR: $ bitbake test -cdo_checkuri -Sprintdiff

ERROR: When reparsing /tmp/selftest-fetchsrayuxoq/test.bb:do_fetch, the basehash value changed from 6d55d6743729b615749dc016857d7e5f9c884a8b92f0d57f68e743f4910333d3 to fa7d6ea0563b60362418d2a6c5e41a6684183d01ec578b65abd0c64a9cfba7cf. The metadata is not deterministic and this needs to be fixed.
ERROR: The following commands may help:
ERROR: $ bitbake test -cdo_fetch -Snone
ERROR: Then:
ERROR: $ bitbake test -cdo_fetch -Sprintdiff

ERROR: When reparsing /tmp/selftest-fetchsrayuxoq/test.bb:do_unpack, the basehash value changed from ae9d94aafc721d891f8754df82ed90da8191357178f3db64221a49d5c1de3bcd to 1ac8f87a71db151b8eb2ae8d13f9a6ea1a0c884ef98555d61d2c2fe07a476a8a. The metadata is not deterministic and this needs to be fixed.
ERROR: The following commands may help:
ERROR: $ bitbake test -cdo_unpack -Snone
ERROR: Then:
ERROR: $ bitbake test -cdo_unpack -Sprintdiff

...

https://autobuilder.yoctoproject.org/valkyrie/#/builders/23/builds/1391

Can you have a look at this please?

-- 
Mathieu Dubois-Briand, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com

Re: [OE-core] [PATCH v3 00/11] systemd based initrd and modular kernel support

[Mikko Rapeli]

Hi,

On Mon, Apr 07, 2025 at 09:53:45AM +0200, Mathieu Dubois-Briand wrote:
> On Fri Apr 4, 2025 at 6:29 PM CEST, Mikko Rapeli via lists.openembedded.org wrote:
> > systemd based initrd supports more security, encryption etc features
> > than custom shell script ones but oe-core lacks support for it.
> > Convert core-image-initramfs-boot to create systemd based initrd
> > if "systemd-initramfs" is set in DISTRO_FEATURES. Includes a test
> > for this initrd to mount rootfs via Unified Kernel Image uki.py.
> >
> > Sadly the boot time is really slow, e.g. over 30 seconds with
> > systemd based initrd. One of the major reasons is the large
> > amount of kernel modules built into the linux-yocto kernel and
> > processing of their udev events in userspace. Thus add
> > kernel-initrd-modules meta package to easily install
> > subset of all kernel modules to initrd. The subset
> > supports "mount rootfs from any block device" but
> > doesn't include graphics, UBS etc support. Without this
> > generated meta package, initrd recipe needs to manually define
> > which exact kernel modules to include which breaks if
> > those modules are built into the kernel. Thus the initrd
> > becomes machine and kernel config specific and hard to maintain.
> > With this meta package a generic initrd can be created.
> >
> > Separate changes to linux-yocto compile a lot more drivers
> > as modules but they depend on these initrd changes.
> >
> 
> Hi Mikko,
> 
> Thanks for your patch.
> 
> I believe one of these wic related patches is responsible of some
> oe-selftest failures we can see on the autobuilder:
> 
> 2025-04-06 15:51:49,317 - oe-selftest - INFO - wic.Wic.test_permissions (subunit.RemotedTestCase)
> 2025-04-06 15:51:49,318 - oe-selftest - INFO -  ... FAIL
> 
> ...
> 
> ERROR: When reparsing /tmp/selftest-fetchsrayuxoq/test.bb:do_checkuri, the basehash value changed from 84b9e23a83a764e7a5d8a96ee523199e2b1c604f4280a45030e248de0ff52962 to 4123da244f465feffecb2b4fd2b132b64851981ec2fb70bf9445df8b0ea6a69e. The metadata is not deterministic and this needs to be fixed.
> ERROR: The following commands may help:
> ERROR: $ bitbake test -cdo_checkuri -Snone
> ERROR: Then:
> ERROR: $ bitbake test -cdo_checkuri -Sprintdiff
> 
> ERROR: When reparsing /tmp/selftest-fetchsrayuxoq/test.bb:do_fetch, the basehash value changed from 6d55d6743729b615749dc016857d7e5f9c884a8b92f0d57f68e743f4910333d3 to fa7d6ea0563b60362418d2a6c5e41a6684183d01ec578b65abd0c64a9cfba7cf. The metadata is not deterministic and this needs to be fixed.
> ERROR: The following commands may help:
> ERROR: $ bitbake test -cdo_fetch -Snone
> ERROR: Then:
> ERROR: $ bitbake test -cdo_fetch -Sprintdiff
> 
> ERROR: When reparsing /tmp/selftest-fetchsrayuxoq/test.bb:do_unpack, the basehash value changed from ae9d94aafc721d891f8754df82ed90da8191357178f3db64221a49d5c1de3bcd to 1ac8f87a71db151b8eb2ae8d13f9a6ea1a0c884ef98555d61d2c2fe07a476a8a. The metadata is not deterministic and this needs to be fixed.
> ERROR: The following commands may help:
> ERROR: $ bitbake test -cdo_unpack -Snone
> ERROR: Then:
> ERROR: $ bitbake test -cdo_unpack -Sprintdiff
> 
> ...
> 
> https://autobuilder.yoctoproject.org/valkyrie/#/builders/23/builds/1391
> 
> Can you have a look at this please?

I can have a look but how can these patches change the basehash'es when testing?

I've seen some of the wic selftets failing on x86_64 build machine with zfs
but changes to fix this was rejected multiple times.

Then I've seen some of these failing with odd pseudo failures on aarch64
build machine.

With my patches the end result was the same.

I ran wic and uki selftests on x86_64 and aarch64 build machines for targets qemuarm64,
qemuarm and genericx86-64.

The wic patches have actually nothing to do with this series except I ran into bugs
in wic which resulted in unbootable images, e.g. the UEFI bootloader binaries
missing from ESP partition. These were impacting some builds but not all
which was really troubling.

Cheers,

-Mikko

Re: [OE-core] [PATCH v3 00/11] systemd based initrd and modular kernel support

[Mathieu Dubois-Briand]

On Mon Apr 7, 2025 at 10:10 AM CEST, Mikko Rapeli wrote:
> Hi,
>
> On Mon, Apr 07, 2025 at 09:53:45AM +0200, Mathieu Dubois-Briand wrote:
>> On Fri Apr 4, 2025 at 6:29 PM CEST, Mikko Rapeli via lists.openembedded.org wrote:
>> > systemd based initrd supports more security, encryption etc features
>> > than custom shell script ones but oe-core lacks support for it.
>> > Convert core-image-initramfs-boot to create systemd based initrd
>> > if "systemd-initramfs" is set in DISTRO_FEATURES. Includes a test
>> > for this initrd to mount rootfs via Unified Kernel Image uki.py.
>> >
>> > Sadly the boot time is really slow, e.g. over 30 seconds with
>> > systemd based initrd. One of the major reasons is the large
>> > amount of kernel modules built into the linux-yocto kernel and
>> > processing of their udev events in userspace. Thus add
>> > kernel-initrd-modules meta package to easily install
>> > subset of all kernel modules to initrd. The subset
>> > supports "mount rootfs from any block device" but
>> > doesn't include graphics, UBS etc support. Without this
>> > generated meta package, initrd recipe needs to manually define
>> > which exact kernel modules to include which breaks if
>> > those modules are built into the kernel. Thus the initrd
>> > becomes machine and kernel config specific and hard to maintain.
>> > With this meta package a generic initrd can be created.
>> >
>> > Separate changes to linux-yocto compile a lot more drivers
>> > as modules but they depend on these initrd changes.
>> >
>> 
>> Hi Mikko,
>> 
>> Thanks for your patch.
>> 
>> I believe one of these wic related patches is responsible of some
>> oe-selftest failures we can see on the autobuilder:
>> 
>> 2025-04-06 15:51:49,317 - oe-selftest - INFO - wic.Wic.test_permissions (subunit.RemotedTestCase)
>> 2025-04-06 15:51:49,318 - oe-selftest - INFO -  ... FAIL
>> 
>> ...
>> 
>> ERROR: When reparsing /tmp/selftest-fetchsrayuxoq/test.bb:do_checkuri, the basehash value changed from 84b9e23a83a764e7a5d8a96ee523199e2b1c604f4280a45030e248de0ff52962 to 4123da244f465feffecb2b4fd2b132b64851981ec2fb70bf9445df8b0ea6a69e. The metadata is not deterministic and this needs to be fixed.
>> ERROR: The following commands may help:
>> ERROR: $ bitbake test -cdo_checkuri -Snone
>> ERROR: Then:
>> ERROR: $ bitbake test -cdo_checkuri -Sprintdiff
>> 
>> ERROR: When reparsing /tmp/selftest-fetchsrayuxoq/test.bb:do_fetch, the basehash value changed from 6d55d6743729b615749dc016857d7e5f9c884a8b92f0d57f68e743f4910333d3 to fa7d6ea0563b60362418d2a6c5e41a6684183d01ec578b65abd0c64a9cfba7cf. The metadata is not deterministic and this needs to be fixed.
>> ERROR: The following commands may help:
>> ERROR: $ bitbake test -cdo_fetch -Snone
>> ERROR: Then:
>> ERROR: $ bitbake test -cdo_fetch -Sprintdiff
>> 
>> ERROR: When reparsing /tmp/selftest-fetchsrayuxoq/test.bb:do_unpack, the basehash value changed from ae9d94aafc721d891f8754df82ed90da8191357178f3db64221a49d5c1de3bcd to 1ac8f87a71db151b8eb2ae8d13f9a6ea1a0c884ef98555d61d2c2fe07a476a8a. The metadata is not deterministic and this needs to be fixed.
>> ERROR: The following commands may help:
>> ERROR: $ bitbake test -cdo_unpack -Snone
>> ERROR: Then:
>> ERROR: $ bitbake test -cdo_unpack -Sprintdiff
>> 
>> ...
>> 
>> https://autobuilder.yoctoproject.org/valkyrie/#/builders/23/builds/1391
>> 
>> Can you have a look at this please?
>
> I can have a look but how can these patches change the basehash'es when testing?
>
> I've seen some of the wic selftets failing on x86_64 build machine with zfs
> but changes to fix this was rejected multiple times.
>
> Then I've seen some of these failing with odd pseudo failures on aarch64
> build machine.
>
> With my patches the end result was the same.
>
> I ran wic and uki selftests on x86_64 and aarch64 build machines for targets qemuarm64,
> qemuarm and genericx86-64.
>
> The wic patches have actually nothing to do with this series except I ran into bugs
> in wic which resulted in unbootable images, e.g. the UEFI bootloader binaries
> missing from ESP partition. These were impacting some builds but not all
> which was really troubling.
>
> Cheers,
>
> -Mikko

Ok, I am running some git bisect locally anyway, I will keep you updated
a bit later today.


-- 
Mathieu Dubois-Briand, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com

Re: [OE-core] [PATCH v3 00/11] systemd based initrd and modular kernel support

[Mikko Rapeli]

On Mon, Apr 07, 2025 at 10:51:43AM +0200, Mathieu Dubois-Briand wrote:
> On Mon Apr 7, 2025 at 10:10 AM CEST, Mikko Rapeli wrote:
> > Hi,
> >
> > On Mon, Apr 07, 2025 at 09:53:45AM +0200, Mathieu Dubois-Briand wrote:
> >> On Fri Apr 4, 2025 at 6:29 PM CEST, Mikko Rapeli via lists.openembedded.org wrote:
> >> > systemd based initrd supports more security, encryption etc features
> >> > than custom shell script ones but oe-core lacks support for it.
> >> > Convert core-image-initramfs-boot to create systemd based initrd
> >> > if "systemd-initramfs" is set in DISTRO_FEATURES. Includes a test
> >> > for this initrd to mount rootfs via Unified Kernel Image uki.py.
> >> >
> >> > Sadly the boot time is really slow, e.g. over 30 seconds with
> >> > systemd based initrd. One of the major reasons is the large
> >> > amount of kernel modules built into the linux-yocto kernel and
> >> > processing of their udev events in userspace. Thus add
> >> > kernel-initrd-modules meta package to easily install
> >> > subset of all kernel modules to initrd. The subset
> >> > supports "mount rootfs from any block device" but
> >> > doesn't include graphics, UBS etc support. Without this
> >> > generated meta package, initrd recipe needs to manually define
> >> > which exact kernel modules to include which breaks if
> >> > those modules are built into the kernel. Thus the initrd
> >> > becomes machine and kernel config specific and hard to maintain.
> >> > With this meta package a generic initrd can be created.
> >> >
> >> > Separate changes to linux-yocto compile a lot more drivers
> >> > as modules but they depend on these initrd changes.
> >> >
> >> 
> >> Hi Mikko,
> >> 
> >> Thanks for your patch.
> >> 
> >> I believe one of these wic related patches is responsible of some
> >> oe-selftest failures we can see on the autobuilder:
> >> 
> >> 2025-04-06 15:51:49,317 - oe-selftest - INFO - wic.Wic.test_permissions (subunit.RemotedTestCase)
> >> 2025-04-06 15:51:49,318 - oe-selftest - INFO -  ... FAIL
> >> 
> >> ...
> >> 
> >> ERROR: When reparsing /tmp/selftest-fetchsrayuxoq/test.bb:do_checkuri, the basehash value changed from 84b9e23a83a764e7a5d8a96ee523199e2b1c604f4280a45030e248de0ff52962 to 4123da244f465feffecb2b4fd2b132b64851981ec2fb70bf9445df8b0ea6a69e. The metadata is not deterministic and this needs to be fixed.
> >> ERROR: The following commands may help:
> >> ERROR: $ bitbake test -cdo_checkuri -Snone
> >> ERROR: Then:
> >> ERROR: $ bitbake test -cdo_checkuri -Sprintdiff
> >> 
> >> ERROR: When reparsing /tmp/selftest-fetchsrayuxoq/test.bb:do_fetch, the basehash value changed from 6d55d6743729b615749dc016857d7e5f9c884a8b92f0d57f68e743f4910333d3 to fa7d6ea0563b60362418d2a6c5e41a6684183d01ec578b65abd0c64a9cfba7cf. The metadata is not deterministic and this needs to be fixed.
> >> ERROR: The following commands may help:
> >> ERROR: $ bitbake test -cdo_fetch -Snone
> >> ERROR: Then:
> >> ERROR: $ bitbake test -cdo_fetch -Sprintdiff
> >> 
> >> ERROR: When reparsing /tmp/selftest-fetchsrayuxoq/test.bb:do_unpack, the basehash value changed from ae9d94aafc721d891f8754df82ed90da8191357178f3db64221a49d5c1de3bcd to 1ac8f87a71db151b8eb2ae8d13f9a6ea1a0c884ef98555d61d2c2fe07a476a8a. The metadata is not deterministic and this needs to be fixed.
> >> ERROR: The following commands may help:
> >> ERROR: $ bitbake test -cdo_unpack -Snone
> >> ERROR: Then:
> >> ERROR: $ bitbake test -cdo_unpack -Sprintdiff
> >> 
> >> ...
> >> 
> >> https://autobuilder.yoctoproject.org/valkyrie/#/builders/23/builds/1391
> >> 
> >> Can you have a look at this please?
> >
> > I can have a look but how can these patches change the basehash'es when testing?
> >
> > I've seen some of the wic selftets failing on x86_64 build machine with zfs
> > but changes to fix this was rejected multiple times.
> >
> > Then I've seen some of these failing with odd pseudo failures on aarch64
> > build machine.
> >
> > With my patches the end result was the same.
> >
> > I ran wic and uki selftests on x86_64 and aarch64 build machines for targets qemuarm64,
> > qemuarm and genericx86-64.
> >
> > The wic patches have actually nothing to do with this series except I ran into bugs
> > in wic which resulted in unbootable images, e.g. the UEFI bootloader binaries
> > missing from ESP partition. These were impacting some builds but not all
> > which was really troubling.
> >
> > Cheers,
> >
> > -Mikko
> 
> Ok, I am running some git bisect locally anyway, I will keep you updated
> a bit later today.

I ran wic.Wic.test_permissions and it passed without this series
on aarch64 build machine and genericarm64 target machine:

NOTE: Reconnecting to bitbake server...
NOTE: Retrying server connection (#1)... (08:13:45.320086)
NOTE: Reconnecting to bitbake server...
NOTE: Reconnecting to bitbake server...
NOTE: Retrying server connection (#1)... (08:13:45.320086)
NOTE: Retrying server connection (#1)... (08:13:45.320086)
NOTE: Starting bitbake server...
hint: Using 'master' as the name for the initial branch. This default branch name
hint: is subject to change. To configure the initial branch name to use in all
hint: of your new repositories, which will suppress this warning, call:
hint: 
hint:   git config --global init.defaultBranch <name>
hint: 
hint: Names commonly chosen instead of 'master' are 'main', 'trunk' and
hint: 'development'. The just-created branch can be renamed via this command:
hint: 
hint:   git branch -m <name>
2025-04-07 08:13:46,418 - oe-selftest - INFO - Adding: "include selftest.inc" in /home/mcfrisk/src/base/poky/build_genericarm64-st/conf/local.conf
2025-04-07 08:13:46,418 - oe-selftest - INFO - Adding: "include bblayers.inc" in bblayers.conf
2025-04-07 08:13:46,418 - oe-selftest - INFO - test_permissions (wic.Wic.test_permissions)
2025-04-07 08:24:47,941 - oe-selftest - INFO -  ... ok
2025-04-07 08:24:54,376 - oe-selftest - INFO - ----------------------------------------------------------------------
2025-04-07 08:24:54,376 - oe-selftest - INFO - Ran 1 test in 668.167s
2025-04-07 08:24:54,376 - oe-selftest - INFO - OK
2025-04-07 08:25:00,978 - oe-selftest - INFO - RESULTS:
2025-04-07 08:25:00,978 - oe-selftest - INFO - RESULTS - wic.Wic.test_permissions: PASSED (661.52s)
2025-04-07 08:25:00,979 - oe-selftest - INFO - SUMMARY:
2025-04-07 08:25:00,979 - oe-selftest - INFO - oe-selftest () - Ran 1 test in 668.168s
2025-04-07 08:25:00,979 - oe-selftest - INFO - oe-selftest - OK - All required tests passed (successes=1, skipped=0, failures=0, errors=0)

Then with patches from this series (and a few more which I sent out separately,
should be unrelated) it failed with pseudo errors:

2025-04-07 08:32:12,107 - oe-selftest - INFO - Changing cwd to /home/mcfrisk/src/base/poky/build_genericarm64
2025-04-07 08:32:12,107 - oe-selftest - INFO - Adding layer libraries:
2025-04-07 08:32:12,107 - oe-selftest - INFO -  /home/mcfrisk/src/base/poky/meta/lib
2025-04-07 08:32:12,107 - oe-selftest - INFO -  /home/mcfrisk/src/base/poky/meta-yocto-bsp/lib
2025-04-07 08:32:12,107 - oe-selftest - INFO -  /home/mcfrisk/src/base/poky/meta-selftest/lib
2025-04-07 08:32:12,108 - oe-selftest - INFO - Checking base configuration is valid/parsable
NOTE: Reconnecting to bitbake server...
NOTE: Retrying server connection (#1)... (08:32:12.728357)
NOTE: Reconnecting to bitbake server...
NOTE: Reconnecting to bitbake server...
NOTE: Retrying server connection (#1)... (08:32:12.728357)
NOTE: Retrying server connection (#1)... (08:32:12.728357)
NOTE: Starting bitbake server...
hint: Using 'master' as the name for the initial branch. This default branch name
hint: is subject to change. To configure the initial branch name to use in all
hint: of your new repositories, which will suppress this warning, call:
hint: 
hint:   git config --global init.defaultBranch <name>
hint: 
hint: Names commonly chosen instead of 'master' are 'main', 'trunk' and
hint: 'development'. The just-created branch can be renamed via this command:
hint: 
hint:   git branch -m <name>
2025-04-07 08:32:13,824 - oe-selftest - INFO - Adding: "include selftest.inc" in /home/mcfrisk/src/base/poky/build_genericarm64-st/conf/local.conf
2025-04-07 08:32:13,824 - oe-selftest - INFO - Adding: "include bblayers.inc" in bblayers.conf
2025-04-07 08:32:13,824 - oe-selftest - INFO - test_permissions (wic.Wic.test_permissions)
2025-04-07 09:10:05,405 - oe-selftest - INFO -  ... FAIL
2025-04-07 09:10:05,488 - oe-selftest - INFO - Traceback (most recent call last):
  File "/home/mcfrisk/src/base/poky/meta/lib/oeqa/selftest/cases/wic.py", line 677, in test_permissions
    bitbake('core-image-minimal')
  File "/home/mcfrisk/src/base/poky/meta/lib/oeqa/utils/commands.py", line 236, in bitbake
    return runCmd(cmd, ignore_status, timeout, output_log=output_log, **options)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/home/mcfrisk/src/base/poky/meta/lib/oeqa/utils/commands.py", line 214, in runCmd
    raise AssertionError("Command '%s' returned non-zero exit status %d:\n%s" % (command, result.status, exc_output))
AssertionError: Command 'bitbake  core-image-minimal' returned non-zero exit status 1:
Loading cache...done.
Loaded 1976 entries from dependency cache.
NOTE: Resolving any missing task queue dependencies

Build Configuration:
BB_VERSION           = "2.12.0"
BUILD_SYS            = "aarch64-linux"
NATIVELSBSTRING      = "universal"
TARGET_SYS           = "aarch64-poky-linux"
MACHINE              = "genericarm64"
DISTRO               = "poky-altcfg"
DISTRO_VERSION       = "5.2"
TUNE_FEATURES        = "aarch64 armv8a crc"
TARGET_FPU           = ""
meta                 
meta-poky            
meta-yocto-bsp       = "HEAD:a75117f79e4771927b89125e464e38acdc9c556e"
meta-selftest        = "master:fd26cf3cc0e6e590b56e331971cdf884d1b881b9"

Initialising tasks...Sstate summary: Wanted 539 Local 536 Mirrors 0 Missed 3 Current 1968 (99% match, 99% complete)
Removing 3 stale sstate objects for arch genericarm64...done.
NOTE: Executing Tasks
NOTE: Running task 5157 of 5259 (/home/mcfrisk/src/base/poky/meta/recipes-core/images/core-image-minimal.bb:do_image_wic)
NOTE: recipe core-image-minimal-1.0-r0: task do_image_wic: Started
ERROR: core-image-minimal-1.0-r0 do_image_wic: Execution of '/home/mcfrisk/src/base/poky/build_genericarm64-st/tmp/work/genericarm64-poky-linux/core-image-minimal/1.0/temp/run.do_image_wic.117565' failed with exit code 134
ERROR: Logfile of failure stored in: /home/mcfrisk/src/base/poky/build_genericarm64-st/tmp/work/genericarm64-poky-linux/core-image-minimal/1.0/temp/log.do_image_wic.117565
Log data follows:
| DEBUG: Executing python function extend_recipe_sysroot
| NOTE: Direct dependencies are ['/home/mcfrisk/src/base/poky/meta/recipes-bsp/grub/grub-efi_2.12.bb:do_populate_sysroot', '/home/mcfrisk/src/base/poky/meta/recipes-core/gli
bc/cross-localedef-native_2.41.bb:do_populate_sysroot', '/home/mcfrisk/src/base/poky/meta/recipes-core/glibc/ldconfig-native_2.12.1.bb:do_populate_sysroot', '/home/mcfrisk/src/base/poky/meta/recipes-core/systemd/systemd-boot_257.4.bb:do_populate_sysroot', '/home/mcfrisk/src/base/poky/meta/recipes-devtools/binutils/binutils-cross_2.44.bb:do_popu
late_sysroot', '/home/mcfrisk/src/base/poky/meta/recipes-devtools/cdrtools/cdrtools-native_3.01.bb:do_populate_sysroot', '/home/mcfrisk/src/base/poky/meta/recipes-devtools/qemu/qemuwrapper-cross_1.0.bb:do_populate_sysroot', '/home/mcfrisk/src/base/poky/meta/recipes-kernel/kmod/depmodwrapper-cross_1.0.bb:do_populate_sysroot', 'virtual:native:/home/mcfrisk/src/base/poky/meta/recipes-core/update-rc.d/update-rc.d_0.8.bb:do_populate_sysroot', 'virtual:native:/home/mcfrisk/src/base/poky/meta/recipes-devtools/btrfs-tools
/btrfs-tools_6.14.bb:do_populate_sysroot', 'virtual:native:/home/mcfrisk/src/base/poky/meta/recipes-devtools/dosfstools/dosfstools_4.2.bb:do_populate_sysroot', 'virtual:native:/home/mcfrisk/src/base/poky/meta/recipes-devtools/e2fsprogs/e2fsprogs_1.47.1.bb:do_populate_sysroot', 'virtual:native:/home/mcfrisk/src/base/poky/meta/recipes-devtools/er
ofs-utils/erofs-utils_1.8.5.bb:do_populate_sysroot', 'virtual:native:/home/mcfrisk/src/base/poky/meta/recipes-devtools/fdisk/gptfdisk_1.0.10.bb:do_populate_sysroot', 'virtual:native:/home/mcfrisk/src/base/poky/meta/recipes-devtools/makedevs/makedevs_1.0.1.bb:do_populate_sysroot', 'virtual:native:/home/mcfrisk/src/base/poky/meta/recipes-devtools/mtools/mtools_4.0.48.bb:do_populate_sysroot', 'virtual:native:/home/mcfrisk/src/base/poky/meta/recipes-devtools/opkg-utils/opkg-utils_0.7.0.bb:do_populate_sysroot', 'virtua
l:native:/home/mcfrisk/src/base/poky/meta/recipes-devtools/opkg/opkg_0.7.0.bb:do_populate_sysroot', 'virtual:native:/home/mcfrisk/src/base/poky/meta/recipes-devtools/pseudo/pseudo_git.bb:do_populate_sysroot', 'virtual:native:/home/mcfrisk/src/base/poky/meta/recipes-devtools/squashfs-tools/squashfs-tools_git.bb:do_populate_sysroot', 'virtual:nat
ive:/home/mcfrisk/src/base/poky/meta/recipes-extended/parted/parted_3.6.bb:do_populate_sysroot', 'virtual:native:/home/mcfrisk/src/base/poky/meta/recipes-extended/pigz/pigz_
2.8.bb:do_populate_sysroot', 'virtual:native:/home/mcfrisk/src/base/poky/meta/recipes-support/bmaptool/bmaptool_git.bb:do_populate_sysroot']
| NOTE: Installed into sysroot: []
| NOTE: Skipping as already exists in sysroot: ['grub-efi', 'gettext-minimal-native', 'cross-localedef-native', 'glibc', 'ldconfig-native', 'libxcrypt', 'ncurses', 'systemd-
boot', 'systemd-systemctl-native', 'util-linux-libuuid', 'util-linux', 'zlib', 'binutils-cross-aarch64', 'cdrtools-native', 'cmake-native', 'gcc-runtime', 'libgcc', 'libtool-native', 'm4-native', 'opkg-utils', 'qemu-helper-native', 'qemu-native', 'qemu-system-native', 'qemuwrapper-cross', 'libpam', 'texinfo-dummy-native', 'depmodwrapper-cross', 'linux-libc-headers', 'bash-completion', 'libcap-ng', 'libcap', 'sqlite3', 'openssl-native', 'libslirp-native', 'coreutils-native', 'expat-native', 'gettext-native', 'glib-
2.0-native', 'libxml2-native', 'ncurses-native', 'readline-native', 'update-rc.d-native', 'util-linux-libuuid-native', 'util-linux-native', 'zlib-native', 'btrfs-tools-nativ
e', 'chrpath-native', 'dosfstools-native', 'e2fsprogs-native', 'elfutils-native', 'erofs-utils-native', 'gptfdisk-native', 'flex-native', 'gnu-config-native', 'json-c-native
', 'libedit-native', 'llvm-native', 'make-native', 'makedevs-native', 'mtools-native', 'opkg-utils-native', 'opkg-native', 'perl-native', 'pseudo-native', 'python3-build-native', 'python3-calver-native', 'python3-editables-native', 'python3-flit-core-native', 'python3-hatchling-native', 'python3-installer-native', 'python3-jinja2-native', 'pyth
on3-mako-native', 'python3-markupsafe-native', 'python3-packaging-native', 'python3-pathspec-native', 'python3-pip-native', 'python3-pluggy-native', 'python3-pygments-native
', 'python3-pyparsing-native', 'python3-pyproject-hooks-native', 'python3-setuptools-scm-native', 'python3-setuptools-native', 'python3-six-native', 'python3-trove-classifiers-native', 'python3-typing-extensions-native', 'python3-wheel-native', 'python3-native', 'squashfs-tools-native', 'unfs3-native', 'bzip2-native', 'cpio-native', 'diffutils-
native', 'libarchive-native', 'libidn2-native', 'libnsl2-native', 'libsolv-native', 'libtirpc-native', 'parted-native', 'pigz-native', 'shadow-native', 'unzip-native', 'xz-native', 'zstd-native', 'libdrm-native', 'libepoxy-native', 'libsdl2-native', 'mesa-native', 'virglrenderer-native', 'wayland-protocols-native', 'wayland-native', 'xrandr-nat
ive', 'libpciaccess-native', 'libpthread-stubs-native', 'libx11-native', 'libxau-native', 'libxcb-native', 'libxdamage-native', 'libxdmcp-native', 'libxext-native', 'libxfixes-native', 'libxrandr-native', 'libxrender-native', 'libxshmfence-native', 'libxxf86vm-native', 'pixman-native', 'xtrans-native', 'xcb-proto-native', 'xorgproto-native', 'makedepend-native', 'util-macros-native', 'dtc-native', 'kmod-native', 'alsa-lib-native', 'libpng-native', 'acl-native', 'attr-native', 'bmaptool-native', 'curl-native', 'deb
ianutils-native', 'gdbm-native', 'gmp-native', 'gnutls-native', 'libtasn1-native', 'libbsd-native', 'libcap-ng-native', 'libcap-native', 'libffi-native', 'libgcrypt-native', 'libgpg-error-native', 'libmd-native', 'libmicrohttpd-native', 'libpcre2-native', 'libunistring-native', 'lz4-native', 'lzo-native', 'nettle-native', 'popt-native', 'shared
-mime-info-native', 'sqlite3-native']
| DEBUG: Python function extend_recipe_sysroot finished
| DEBUG: Executing python function set_image_size
| DEBUG: 159546.400000 = 122728 * 1.300000
| DEBUG: 163642.400000 = max(159546.400000, 8192)[159546.400000] + 4096
| DEBUG: 163643.000000 = int(163642.400000)
| DEBUG: 163643 = aligned(163643)
| DEBUG: returning 163643
| DEBUG: Python function set_image_size finished
| DEBUG: Executing shell function do_image_wic
| abort()ing pseudo client by server request. See https://wiki.yoctoproject.org/wiki/Pseudo_Abort for more details on this.
| Check logfile: /home/mcfrisk/src/base/poky/build_genericarm64-st/tmp/work/genericarm64-poky-linux/core-image-minimal/1.0/pseudo//pseudo.log
| WARNING: exit code 134 from a shell command.
| Aborted
NOTE: recipe core-image-minimal-1.0-r0: task do_image_wic: Failed
ERROR: Task (/home/mcfrisk/src/base/poky/meta/recipes-core/images/core-image-minimal.bb:do_image_wic) failed with exit code '1' 
Pseudo log:
path mismatch [2 links]: ino 43965780 db '/home/mcfrisk/src/base/poky/build_genericarm64-st/tmp/work/genericarm64-poky-linux/core-image-minimal/1.0/rootfs/boot/loader/loader.conf' req '/home/mcfrisk/src/base/poky/build_genericarm64-st/tmp/work/genericarm64-poky-linux/core-image-minimal/1.0/tmp-wic/rootfs1/boot/loader/loader.conf'.
Setup complete, sending SIGUSR1 to pid 117389.

NOTE: Tasks Summary: Attempted 5254 tasks of which 5253 didn't need to be rerun and 1 failed.

Summary: 1 task failed:
  /home/mcfrisk/src/base/poky/meta/recipes-core/images/core-image-minimal.bb:do_image_wic
    log: /home/mcfrisk/src/base/poky/build_genericarm64-st/tmp/work/genericarm64-poky-linux/core-image-minimal/1.0/temp/log.do_image_wic.117565
Summary: There was 1 ERROR message, returning a non-zero exit code.

2025-04-07 09:10:05,488 - oe-selftest - INFO - ======================================================================
2025-04-07 09:10:05,488 - oe-selftest - INFO - FAIL: test_permissions (wic.Wic.test_permissions)
2025-04-07 09:10:05,489 - oe-selftest - INFO - ----------------------------------------------------------------------
2025-04-07 09:10:05,489 - oe-selftest - INFO - Traceback (most recent call last):
  File "/home/mcfrisk/src/base/poky/meta/lib/oeqa/selftest/cases/wic.py", line 677, in test_permissions
    bitbake('core-image-minimal')
  File "/home/mcfrisk/src/base/poky/meta/lib/oeqa/utils/commands.py", line 236, in bitbake
    return runCmd(cmd, ignore_status, timeout, output_log=output_log, **options)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/home/mcfrisk/src/base/poky/meta/lib/oeqa/utils/commands.py", line 214, in runCmd
    raise AssertionError("Command '%s' returned non-zero exit status %d:\n%s" % (command, result.status, exc_output))
AssertionError: Command 'bitbake  core-image-minimal' returned non-zero exit status 1:
Loading cache...done.
Loaded 1976 entries from dependency cache.
NOTE: Resolving any missing task queue dependencies

Build Configuration:
BB_VERSION           = "2.12.0"
BUILD_SYS            = "aarch64-linux"
NATIVELSBSTRING      = "universal"
TARGET_SYS           = "aarch64-poky-linux"
MACHINE              = "genericarm64"
DISTRO               = "poky-altcfg"
DISTRO_VERSION       = "5.2"
TUNE_FEATURES        = "aarch64 armv8a crc"
TARGET_FPU           = ""
meta                 
meta-poky            
meta-yocto-bsp       = "HEAD:a75117f79e4771927b89125e464e38acdc9c556e"
meta-selftest        = "master:fd26cf3cc0e6e590b56e331971cdf884d1b881b9"

Initialising tasks...Sstate summary: Wanted 539 Local 536 Mirrors 0 Missed 3 Current 1968 (99% match, 99% complete)
Removing 3 stale sstate objects for arch genericarm64...done.
NOTE: Executing Tasks
NOTE: Running task 5157 of 5259 (/home/mcfrisk/src/base/poky/meta/recipes-core/images/core-image-minimal.bb:do_image_wic)
NOTE: recipe core-image-minimal-1.0-r0: task do_image_wic: Started
ERROR: core-image-minimal-1.0-r0 do_image_wic: Execution of '/home/mcfrisk/src/base/poky/build_genericarm64-st/tmp/work/genericarm64-poky-linux/core-image-minimal/1.0/temp/r
un.do_image_wic.117565' failed with exit code 134
ERROR: Logfile of failure stored in: /home/mcfrisk/src/base/poky/build_genericarm64-st/tmp/work/genericarm64-poky-linux/core-image-minimal/1.0/temp/log.do_image_wic.117565
Log data follows:
| DEBUG: Executing python function extend_recipe_sysroot
| NOTE: Direct dependencies are ['/home/mcfrisk/src/base/poky/meta/recipes-bsp/grub/grub-efi_2.12.bb:do_populate_sysroot', '/home/mcfrisk/src/base/poky/meta/recipes-core/glibc/cross-localedef-native_2.41.bb:do_populate_sysroot', '/home/mcfrisk/src/base/poky/meta/recipes-core/glibc/ldconfig-native_2.12.1.bb:do_populate_sysroot', '/home/mcfrisk/s
rc/base/poky/meta/recipes-core/systemd/systemd-boot_257.4.bb:do_populate_sysroot', '/home/mcfrisk/src/base/poky/meta/recipes-devtools/binutils/binutils-cross_2.44.bb:do_populate_sysroot', '/home/mcfrisk/src/base/poky/meta/recipes-devtools/cdrtools/cdrtools-native_3.01.bb:do_populate_sysroot', '/home/mcfrisk/src/base/poky/meta/recipes-devtools/qemu/qemuwrapper-cross_1.0.bb:do_populate_sysroot', '/home/mcfrisk/src/base/poky/meta/recipes-kernel/kmod/depmodwrapper-cross_1.0.bb:do_populate_sysroot', 'virtual:native:/ho
me/mcfrisk/src/base/poky/meta/recipes-core/update-rc.d/update-rc.d_0.8.bb:do_populate_sysroot', 'virtual:native:/home/mcfrisk/src/base/poky/meta/recipes-devtools/btrfs-tools/btrfs-tools_6.14.bb:do_populate_sysroot', 'virtual:native:/home/mcfrisk/src/base/poky/meta/recipes-devtools/dosfstools/dosfstools_4.2.bb:do_populate_sysroot', 'virtual:nati
ve:/home/mcfrisk/src/base/poky/meta/recipes-devtools/e2fsprogs/e2fsprogs_1.47.1.bb:do_populate_sysroot', 'virtual:native:/home/mcfrisk/src/base/poky/meta/recipes-devtools/erofs-utils/erofs-utils_1.8.5.bb:do_populate_sysroot', 'virtual:native:/home/mcfrisk/src/base/poky/meta/recipes-devtools/fdisk/gptfdisk_1.0.10.bb:do_populate_sysroot', 'virtual:native:/home/mcfrisk/src/base/poky/meta/recipes-devtools/makedevs/makedevs_1.0.1.bb:do_populate_sysroot', 'virtual:native:/home/mcfrisk/src/base/poky/meta/recipes-devtools/mtools/mtools_4.0.48.bb:do_populate_sysroot', 'virtual:native:/home/mcfrisk/src/base/poky/meta/recipes-devtools/opkg-utils/opkg-utils_0.7.0.bb:do_populate_sysroot', 'virtua
l:native:/home/mcfrisk/src/base/poky/meta/recipes-devtools/opkg/opkg_0.7.0.bb:do_populate_sysroot', 'virtual:native:/home/mcfrisk/src/base/poky/meta/recipes-devtools/pseudo/
pseudo_git.bb:do_populate_sysroot', 'virtual:native:/home/mcfrisk/src/base/poky/meta/recipes-devtools/squashfs-tools/squashfs-tools_git.bb:do_populate_sysroot', 'virtual:native:/home/mcfrisk/src/base/poky/meta/recipes-extended/parted/parted_3.6.bb:do_populate_sysroot', 'virtual:native:/home/mcfrisk/src/base/poky/meta/recipes-extended/pigz/pigz_2.8.bb:do_populate_sysroot', 'virtual:native:/home/mcfrisk/src/base/poky/meta/recipes-support/bmaptool/bmaptool_git.bb:do_populate_sysroot']
| NOTE: Installed into sysroot: []
| NOTE: Skipping as already exists in sysroot: ['grub-efi', 'gettext-minimal-native', 'cross-localedef-native', 'glibc', 'ldconfig-native', 'libxcrypt', 'ncurses', 'systemd-boot', 'systemd-systemctl-native', 'util-linux-libuuid', 'util-linux', 'zlib', 'binutils-cross-aarch64', 'cdrtools-native', 'cmake-native', 'gcc-runtime', 'libgcc', 'libtool
-native', 'm4-native', 'opkg-utils', 'qemu-helper-native', 'qemu-native', 'qemu-system-native', 'qemuwrapper-cross', 'libpam', 'texinfo-dummy-native', 'depmodwrapper-cross', 'linux-libc-headers', 'bash-completion', 'libcap-ng', 'libcap', 'sqlite3', 'openssl-native', 'libslirp-native', 'coreutils-native', 'expat-native', 'gettext-native', 'glib-
2.0-native', 'libxml2-native', 'ncurses-native', 'readline-native', 'update-rc.d-native', 'util-linux-libuuid-native', 'util-linux-native', 'zlib-native', 'btrfs-tools-native', 'chrpath-native', 'dosfstools-native', 'e2fsprogs-native', 'elfutils-native', 'erofs-utils-native', 'gptfdisk-native', 'flex-native', 'gnu-config-native', 'json-c-native', 'libedit-native', 'llvm-native', 'make-native', 'makedevs-native', 'mtools-native', 'opkg-utils-native', 'opkg-native', 'perl-native', 'pseudo-native', 'python3-build-nat
ive', 'python3-calver-native', 'python3-editables-native', 'python3-flit-core-native', 'python3-hatchling-native', 'python3-installer-native', 'python3-jinja2-native', 'python3-mako-native', 'python3-markupsafe-native', 'python3-packaging-native', 'python3-pathspec-native', 'python3-pip-native', 'python3-pluggy-native', 'python3-pygments-native
', 'python3-pyparsing-native', 'python3-pyproject-hooks-native', 'python3-setuptools-scm-native', 'python3-setuptools-native', 'python3-six-native', 'python3-trove-classifiers-native', 'python3-typing-extensions-native', 'python3-wheel-native', 'python3-native', 'squashfs-tools-native', 'unfs3-native', 'bzip2-native', 'cpio-native', 'diffutils-native', 'libarchive-native', 'libidn2-native', 'libnsl2-native', 'libsolv-native', 'libtirpc-native', 'parted-native', 'pigz-native', 'shadow-native', 'unzip-native', 'xz-n
ative', 'zstd-native', 'libdrm-native', 'libepoxy-native', 'libsdl2-native', 'mesa-native', 'virglrenderer-native', 'wayland-protocols-native', 'wayland-native', 'xrandr-native', 'libpciaccess-native', 'libpthread-stubs-native', 'libx11-native', 'libxau-native', 'libxcb-native', 'libxdamage-native', 'libxdmcp-native', 'libxext-native', 'libxfix
es-native', 'libxrandr-native', 'libxrender-native', 'libxshmfence-native', 'libxxf86vm-native', 'pixman-native', 'xtrans-native', 'xcb-proto-native', 'xorgproto-native', 'makedepend-native', 'util-macros-native', 'dtc-native', 'kmod-native', 'alsa-lib-native', 'libpng-native', 'acl-native', 'attr-native', 'bmaptool-native', 'curl-native', 'debianutils-native', 'gdbm-native', 'gmp-native', 'gnutls-native', 'libtasn1-native', 'libbsd-native', 'libcap-ng-native', 'libcap-native', 'libffi-native', 'libgcrypt-native',
 'libgpg-error-native', 'libmd-native', 'libmicrohttpd-native', 'libpcre2-native', 'libunistring-native', 'lz4-native', 'lzo-native', 'nettle-native', 'popt-native', 'shared-mime-info-native', 'sqlite3-native']
| DEBUG: Python function extend_recipe_sysroot finished
| DEBUG: Executing python function set_image_size
| DEBUG: 159546.400000 = 122728 * 1.300000
| DEBUG: 163642.400000 = max(159546.400000, 8192)[159546.400000] + 4096
| DEBUG: 163643.000000 = int(163642.400000)
| DEBUG: 163643 = aligned(163643)
| DEBUG: returning 163643
| DEBUG: Python function set_image_size finished
| DEBUG: Executing shell function do_image_wic
| abort()ing pseudo client by server request. See https://wiki.yoctoproject.org/wiki/Pseudo_Abort for more details on this.
| Check logfile: /home/mcfrisk/src/base/poky/build_genericarm64-st/tmp/work/genericarm64-poky-linux/core-image-minimal/1.0/pseudo//pseudo.log
| WARNING: exit code 134 from a shell command.
| Aborted
NOTE: recipe core-image-minimal-1.0-r0: task do_image_wic: Failed
ERROR: Task (/home/mcfrisk/src/base/poky/meta/recipes-core/images/core-image-minimal.bb:do_image_wic) failed with exit code '1' 
Pseudo log:
path mismatch [2 links]: ino 43965780 db '/home/mcfrisk/src/base/poky/build_genericarm64-st/tmp/work/genericarm64-poky-linux/core-image-minimal/1.0/rootfs/boot/loader/loader.conf' req '/home/mcfrisk/src/base/poky/build_genericarm64-st/tmp/work/genericarm64-poky-linux/core-image-minimal/1.0/tmp-wic/rootfs1/boot/loader/loader.conf'.
Setup complete, sending SIGUSR1 to pid 117389.

NOTE: Tasks Summary: Attempted 5254 tasks of which 5253 didn't need to be rerun and 1 failed.

Summary: 1 task failed:
  /home/mcfrisk/src/base/poky/meta/recipes-core/images/core-image-minimal.bb:do_image_wic
    log: /home/mcfrisk/src/base/poky/build_genericarm64-st/tmp/work/genericarm64-poky-linux/core-image-minimal/1.0/temp/log.do_image_wic.117565
Summary: There was 1 ERROR message, returning a non-zero exit code.
----------------------------------------------------------------------
2025-04-07 09:10:05,489 - oe-selftest - INFO - Ran 1 test in 2271.863s
2025-04-07 09:10:05,489 - oe-selftest - INFO - FAILED
2025-04-07 09:10:05,489 - oe-selftest - INFO -  (failures=1)
2025-04-07 09:10:11,706 - oe-selftest - INFO - RESULTS:
2025-04-07 09:10:11,706 - oe-selftest - INFO - RESULTS - wic.Wic.test_permissions: FAILED (2271.66s)
2025-04-07 09:10:11,708 - oe-selftest - INFO - SUMMARY:
2025-04-07 09:10:11,708 - oe-selftest - INFO - oe-selftest () - Ran 1 test in 2271.863s
2025-04-07 09:10:11,708 - oe-selftest - INFO - oe-selftest - FAIL - Required tests failed (successes=0, skipped=0, failures=1, errors=0)

I think something in this test is faulty. For example building an image
in yocto do_image with fakeroot/pseudo and then modifying it outside of build
env with wic is likely going to fail like this.

I will try with other machine targets and cleaner local.conf
but I suspect I will run into this same issue again.

And the error from your CI buidl was completely different... :/

Cheers,

-Mikko

Re: [OE-core] [PATCH v3 00/11] systemd based initrd and modular kernel support

[Mathieu Dubois-Briand]

On Mon Apr 7, 2025 at 11:24 AM CEST, Mikko Rapeli wrote:
> On Mon, Apr 07, 2025 at 10:51:43AM +0200, Mathieu Dubois-Briand wrote:
>> On Mon Apr 7, 2025 at 10:10 AM CEST, Mikko Rapeli wrote:
>> > Hi,
>> >
>> > On Mon, Apr 07, 2025 at 09:53:45AM +0200, Mathieu Dubois-Briand wrote:
>> >> On Fri Apr 4, 2025 at 6:29 PM CEST, Mikko Rapeli via lists.openembedded.org wrote:
>> >> > systemd based initrd supports more security, encryption etc features
>> >> > than custom shell script ones but oe-core lacks support for it.
>> >> > Convert core-image-initramfs-boot to create systemd based initrd
>> >> > if "systemd-initramfs" is set in DISTRO_FEATURES. Includes a test
>> >> > for this initrd to mount rootfs via Unified Kernel Image uki.py.
>> >> >
>> >> > Sadly the boot time is really slow, e.g. over 30 seconds with
>> >> > systemd based initrd. One of the major reasons is the large
>> >> > amount of kernel modules built into the linux-yocto kernel and
>> >> > processing of their udev events in userspace. Thus add
>> >> > kernel-initrd-modules meta package to easily install
>> >> > subset of all kernel modules to initrd. The subset
>> >> > supports "mount rootfs from any block device" but
>> >> > doesn't include graphics, UBS etc support. Without this
>> >> > generated meta package, initrd recipe needs to manually define
>> >> > which exact kernel modules to include which breaks if
>> >> > those modules are built into the kernel. Thus the initrd
>> >> > becomes machine and kernel config specific and hard to maintain.
>> >> > With this meta package a generic initrd can be created.
>> >> >
>> >> > Separate changes to linux-yocto compile a lot more drivers
>> >> > as modules but they depend on these initrd changes.
>> >> >
>> >> 
>> >> Hi Mikko,
>> >> 
>> >> Thanks for your patch.
>> >> 
>> >> I believe one of these wic related patches is responsible of some
>> >> oe-selftest failures we can see on the autobuilder:
>> >> 
>> >> 2025-04-06 15:51:49,317 - oe-selftest - INFO - wic.Wic.test_permissions (subunit.RemotedTestCase)
>> >> 2025-04-06 15:51:49,318 - oe-selftest - INFO -  ... FAIL
>> >> 
>> >> ...
>> >> 
>> >> ERROR: When reparsing /tmp/selftest-fetchsrayuxoq/test.bb:do_checkuri, the basehash value changed from 84b9e23a83a764e7a5d8a96ee523199e2b1c604f4280a45030e248de0ff52962 to 4123da244f465feffecb2b4fd2b132b64851981ec2fb70bf9445df8b0ea6a69e. The metadata is not deterministic and this needs to be fixed.
>> >> ERROR: The following commands may help:
>> >> ERROR: $ bitbake test -cdo_checkuri -Snone
>> >> ERROR: Then:
>> >> ERROR: $ bitbake test -cdo_checkuri -Sprintdiff
>> >> 
>> >> ERROR: When reparsing /tmp/selftest-fetchsrayuxoq/test.bb:do_fetch, the basehash value changed from 6d55d6743729b615749dc016857d7e5f9c884a8b92f0d57f68e743f4910333d3 to fa7d6ea0563b60362418d2a6c5e41a6684183d01ec578b65abd0c64a9cfba7cf. The metadata is not deterministic and this needs to be fixed.
>> >> ERROR: The following commands may help:
>> >> ERROR: $ bitbake test -cdo_fetch -Snone
>> >> ERROR: Then:
>> >> ERROR: $ bitbake test -cdo_fetch -Sprintdiff
>> >> 
>> >> ERROR: When reparsing /tmp/selftest-fetchsrayuxoq/test.bb:do_unpack, the basehash value changed from ae9d94aafc721d891f8754df82ed90da8191357178f3db64221a49d5c1de3bcd to 1ac8f87a71db151b8eb2ae8d13f9a6ea1a0c884ef98555d61d2c2fe07a476a8a. The metadata is not deterministic and this needs to be fixed.
>> >> ERROR: The following commands may help:
>> >> ERROR: $ bitbake test -cdo_unpack -Snone
>> >> ERROR: Then:
>> >> ERROR: $ bitbake test -cdo_unpack -Sprintdiff
>> >> 
>> >> ...
>> >> 
>> >> https://autobuilder.yoctoproject.org/valkyrie/#/builders/23/builds/1391
>> >> 
>> >> Can you have a look at this please?
>> >
>> > I can have a look but how can these patches change the basehash'es when testing?
>> >
>> > I've seen some of the wic selftets failing on x86_64 build machine with zfs
>> > but changes to fix this was rejected multiple times.
>> >
>> > Then I've seen some of these failing with odd pseudo failures on aarch64
>> > build machine.
>> >
>> > With my patches the end result was the same.
>> >
>> > I ran wic and uki selftests on x86_64 and aarch64 build machines for targets qemuarm64,
>> > qemuarm and genericx86-64.
>> >
>> > The wic patches have actually nothing to do with this series except I ran into bugs
>> > in wic which resulted in unbootable images, e.g. the UEFI bootloader binaries
>> > missing from ESP partition. These were impacting some builds but not all
>> > which was really troubling.
>> >
>> > Cheers,
>> >
>> > -Mikko
>> 
>> Ok, I am running some git bisect locally anyway, I will keep you updated
>> a bit later today.
>
> I ran wic.Wic.test_permissions and it passed without this series
> on aarch64 build machine and genericarm64 target machine:
>
> NOTE: Reconnecting to bitbake server...
> NOTE: Retrying server connection (#1)... (08:13:45.320086)
> NOTE: Reconnecting to bitbake server...
> NOTE: Reconnecting to bitbake server...
> NOTE: Retrying server connection (#1)... (08:13:45.320086)
> NOTE: Retrying server connection (#1)... (08:13:45.320086)
> NOTE: Starting bitbake server...
> hint: Using 'master' as the name for the initial branch. This default branch name
> hint: is subject to change. To configure the initial branch name to use in all
> hint: of your new repositories, which will suppress this warning, call:
> hint: 
> hint:   git config --global init.defaultBranch <name>
> hint: 
> hint: Names commonly chosen instead of 'master' are 'main', 'trunk' and
> hint: 'development'. The just-created branch can be renamed via this command:
> hint: 
> hint:   git branch -m <name>
> 2025-04-07 08:13:46,418 - oe-selftest - INFO - Adding: "include selftest.inc" in /home/mcfrisk/src/base/poky/build_genericarm64-st/conf/local.conf
> 2025-04-07 08:13:46,418 - oe-selftest - INFO - Adding: "include bblayers.inc" in bblayers.conf
> 2025-04-07 08:13:46,418 - oe-selftest - INFO - test_permissions (wic.Wic.test_permissions)
> 2025-04-07 08:24:47,941 - oe-selftest - INFO -  ... ok
> 2025-04-07 08:24:54,376 - oe-selftest - INFO - ----------------------------------------------------------------------
> 2025-04-07 08:24:54,376 - oe-selftest - INFO - Ran 1 test in 668.167s
> 2025-04-07 08:24:54,376 - oe-selftest - INFO - OK
> 2025-04-07 08:25:00,978 - oe-selftest - INFO - RESULTS:
> 2025-04-07 08:25:00,978 - oe-selftest - INFO - RESULTS - wic.Wic.test_permissions: PASSED (661.52s)
> 2025-04-07 08:25:00,979 - oe-selftest - INFO - SUMMARY:
> 2025-04-07 08:25:00,979 - oe-selftest - INFO - oe-selftest () - Ran 1 test in 668.168s
> 2025-04-07 08:25:00,979 - oe-selftest - INFO - oe-selftest - OK - All required tests passed (successes=1, skipped=0, failures=0, errors=0)
>
> Then with patches from this series (and a few more which I sent out separately,
> should be unrelated) it failed with pseudo errors:
>
> 2025-04-07 08:32:12,107 - oe-selftest - INFO - Changing cwd to /home/mcfrisk/src/base/poky/build_genericarm64
> 2025-04-07 08:32:12,107 - oe-selftest - INFO - Adding layer libraries:
> 2025-04-07 08:32:12,107 - oe-selftest - INFO -  /home/mcfrisk/src/base/poky/meta/lib
> 2025-04-07 08:32:12,107 - oe-selftest - INFO -  /home/mcfrisk/src/base/poky/meta-yocto-bsp/lib
> 2025-04-07 08:32:12,107 - oe-selftest - INFO -  /home/mcfrisk/src/base/poky/meta-selftest/lib
> 2025-04-07 08:32:12,108 - oe-selftest - INFO - Checking base configuration is valid/parsable
> NOTE: Reconnecting to bitbake server...
> NOTE: Retrying server connection (#1)... (08:32:12.728357)
> NOTE: Reconnecting to bitbake server...
> NOTE: Reconnecting to bitbake server...
> NOTE: Retrying server connection (#1)... (08:32:12.728357)
> NOTE: Retrying server connection (#1)... (08:32:12.728357)
> NOTE: Starting bitbake server...
> hint: Using 'master' as the name for the initial branch. This default branch name
> hint: is subject to change. To configure the initial branch name to use in all
> hint: of your new repositories, which will suppress this warning, call:
> hint: 
> hint:   git config --global init.defaultBranch <name>
> hint: 
> hint: Names commonly chosen instead of 'master' are 'main', 'trunk' and
> hint: 'development'. The just-created branch can be renamed via this command:
> hint: 
> hint:   git branch -m <name>
> 2025-04-07 08:32:13,824 - oe-selftest - INFO - Adding: "include selftest.inc" in /home/mcfrisk/src/base/poky/build_genericarm64-st/conf/local.conf
> 2025-04-07 08:32:13,824 - oe-selftest - INFO - Adding: "include bblayers.inc" in bblayers.conf
> 2025-04-07 08:32:13,824 - oe-selftest - INFO - test_permissions (wic.Wic.test_permissions)
> 2025-04-07 09:10:05,405 - oe-selftest - INFO -  ... FAIL
> 2025-04-07 09:10:05,488 - oe-selftest - INFO - Traceback (most recent call last):
>   File "/home/mcfrisk/src/base/poky/meta/lib/oeqa/selftest/cases/wic.py", line 677, in test_permissions
>     bitbake('core-image-minimal')
>   File "/home/mcfrisk/src/base/poky/meta/lib/oeqa/utils/commands.py", line 236, in bitbake
>     return runCmd(cmd, ignore_status, timeout, output_log=output_log, **options)
>            ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>   File "/home/mcfrisk/src/base/poky/meta/lib/oeqa/utils/commands.py", line 214, in runCmd
>     raise AssertionError("Command '%s' returned non-zero exit status %d:\n%s" % (command, result.status, exc_output))
> AssertionError: Command 'bitbake  core-image-minimal' returned non-zero exit status 1:
> Loading cache...done.
> Loaded 1976 entries from dependency cache.
> NOTE: Resolving any missing task queue dependencies
>
> Build Configuration:
> BB_VERSION           = "2.12.0"
> BUILD_SYS            = "aarch64-linux"
> NATIVELSBSTRING      = "universal"
> TARGET_SYS           = "aarch64-poky-linux"
> MACHINE              = "genericarm64"
> DISTRO               = "poky-altcfg"
> DISTRO_VERSION       = "5.2"
> TUNE_FEATURES        = "aarch64 armv8a crc"
> TARGET_FPU           = ""
> meta                 
> meta-poky            
> meta-yocto-bsp       = "HEAD:a75117f79e4771927b89125e464e38acdc9c556e"
> meta-selftest        = "master:fd26cf3cc0e6e590b56e331971cdf884d1b881b9"
>
> Initialising tasks...Sstate summary: Wanted 539 Local 536 Mirrors 0 Missed 3 Current 1968 (99% match, 99% complete)
> Removing 3 stale sstate objects for arch genericarm64...done.
> NOTE: Executing Tasks
> NOTE: Running task 5157 of 5259 (/home/mcfrisk/src/base/poky/meta/recipes-core/images/core-image-minimal.bb:do_image_wic)
> NOTE: recipe core-image-minimal-1.0-r0: task do_image_wic: Started
> ERROR: core-image-minimal-1.0-r0 do_image_wic: Execution of '/home/mcfrisk/src/base/poky/build_genericarm64-st/tmp/work/genericarm64-poky-linux/core-image-minimal/1.0/temp/run.do_image_wic.117565' failed with exit code 134
> ERROR: Logfile of failure stored in: /home/mcfrisk/src/base/poky/build_genericarm64-st/tmp/work/genericarm64-poky-linux/core-image-minimal/1.0/temp/log.do_image_wic.117565
> Log data follows:
> | DEBUG: Executing python function extend_recipe_sysroot
> | NOTE: Direct dependencies are ['/home/mcfrisk/src/base/poky/meta/recipes-bsp/grub/grub-efi_2.12.bb:do_populate_sysroot', '/home/mcfrisk/src/base/poky/meta/recipes-core/gli
> bc/cross-localedef-native_2.41.bb:do_populate_sysroot', '/home/mcfrisk/src/base/poky/meta/recipes-core/glibc/ldconfig-native_2.12.1.bb:do_populate_sysroot', '/home/mcfrisk/src/base/poky/meta/recipes-core/systemd/systemd-boot_257.4.bb:do_populate_sysroot', '/home/mcfrisk/src/base/poky/meta/recipes-devtools/binutils/binutils-cross_2.44.bb:do_popu
> late_sysroot', '/home/mcfrisk/src/base/poky/meta/recipes-devtools/cdrtools/cdrtools-native_3.01.bb:do_populate_sysroot', '/home/mcfrisk/src/base/poky/meta/recipes-devtools/qemu/qemuwrapper-cross_1.0.bb:do_populate_sysroot', '/home/mcfrisk/src/base/poky/meta/recipes-kernel/kmod/depmodwrapper-cross_1.0.bb:do_populate_sysroot', 'virtual:native:/home/mcfrisk/src/base/poky/meta/recipes-core/update-rc.d/update-rc.d_0.8.bb:do_populate_sysroot', 'virtual:native:/home/mcfrisk/src/base/poky/meta/recipes-devtools/btrfs-tools
> /btrfs-tools_6.14.bb:do_populate_sysroot', 'virtual:native:/home/mcfrisk/src/base/poky/meta/recipes-devtools/dosfstools/dosfstools_4.2.bb:do_populate_sysroot', 'virtual:native:/home/mcfrisk/src/base/poky/meta/recipes-devtools/e2fsprogs/e2fsprogs_1.47.1.bb:do_populate_sysroot', 'virtual:native:/home/mcfrisk/src/base/poky/meta/recipes-devtools/er
> ofs-utils/erofs-utils_1.8.5.bb:do_populate_sysroot', 'virtual:native:/home/mcfrisk/src/base/poky/meta/recipes-devtools/fdisk/gptfdisk_1.0.10.bb:do_populate_sysroot', 'virtual:native:/home/mcfrisk/src/base/poky/meta/recipes-devtools/makedevs/makedevs_1.0.1.bb:do_populate_sysroot', 'virtual:native:/home/mcfrisk/src/base/poky/meta/recipes-devtools/mtools/mtools_4.0.48.bb:do_populate_sysroot', 'virtual:native:/home/mcfrisk/src/base/poky/meta/recipes-devtools/opkg-utils/opkg-utils_0.7.0.bb:do_populate_sysroot', 'virtua
> l:native:/home/mcfrisk/src/base/poky/meta/recipes-devtools/opkg/opkg_0.7.0.bb:do_populate_sysroot', 'virtual:native:/home/mcfrisk/src/base/poky/meta/recipes-devtools/pseudo/pseudo_git.bb:do_populate_sysroot', 'virtual:native:/home/mcfrisk/src/base/poky/meta/recipes-devtools/squashfs-tools/squashfs-tools_git.bb:do_populate_sysroot', 'virtual:nat
> ive:/home/mcfrisk/src/base/poky/meta/recipes-extended/parted/parted_3.6.bb:do_populate_sysroot', 'virtual:native:/home/mcfrisk/src/base/poky/meta/recipes-extended/pigz/pigz_
> 2.8.bb:do_populate_sysroot', 'virtual:native:/home/mcfrisk/src/base/poky/meta/recipes-support/bmaptool/bmaptool_git.bb:do_populate_sysroot']
> | NOTE: Installed into sysroot: []
> | NOTE: Skipping as already exists in sysroot: ['grub-efi', 'gettext-minimal-native', 'cross-localedef-native', 'glibc', 'ldconfig-native', 'libxcrypt', 'ncurses', 'systemd-
> boot', 'systemd-systemctl-native', 'util-linux-libuuid', 'util-linux', 'zlib', 'binutils-cross-aarch64', 'cdrtools-native', 'cmake-native', 'gcc-runtime', 'libgcc', 'libtool-native', 'm4-native', 'opkg-utils', 'qemu-helper-native', 'qemu-native', 'qemu-system-native', 'qemuwrapper-cross', 'libpam', 'texinfo-dummy-native', 'depmodwrapper-cross', 'linux-libc-headers', 'bash-completion', 'libcap-ng', 'libcap', 'sqlite3', 'openssl-native', 'libslirp-native', 'coreutils-native', 'expat-native', 'gettext-native', 'glib-
> 2.0-native', 'libxml2-native', 'ncurses-native', 'readline-native', 'update-rc.d-native', 'util-linux-libuuid-native', 'util-linux-native', 'zlib-native', 'btrfs-tools-nativ
> e', 'chrpath-native', 'dosfstools-native', 'e2fsprogs-native', 'elfutils-native', 'erofs-utils-native', 'gptfdisk-native', 'flex-native', 'gnu-config-native', 'json-c-native
> ', 'libedit-native', 'llvm-native', 'make-native', 'makedevs-native', 'mtools-native', 'opkg-utils-native', 'opkg-native', 'perl-native', 'pseudo-native', 'python3-build-native', 'python3-calver-native', 'python3-editables-native', 'python3-flit-core-native', 'python3-hatchling-native', 'python3-installer-native', 'python3-jinja2-native', 'pyth
> on3-mako-native', 'python3-markupsafe-native', 'python3-packaging-native', 'python3-pathspec-native', 'python3-pip-native', 'python3-pluggy-native', 'python3-pygments-native
> ', 'python3-pyparsing-native', 'python3-pyproject-hooks-native', 'python3-setuptools-scm-native', 'python3-setuptools-native', 'python3-six-native', 'python3-trove-classifiers-native', 'python3-typing-extensions-native', 'python3-wheel-native', 'python3-native', 'squashfs-tools-native', 'unfs3-native', 'bzip2-native', 'cpio-native', 'diffutils-
> native', 'libarchive-native', 'libidn2-native', 'libnsl2-native', 'libsolv-native', 'libtirpc-native', 'parted-native', 'pigz-native', 'shadow-native', 'unzip-native', 'xz-native', 'zstd-native', 'libdrm-native', 'libepoxy-native', 'libsdl2-native', 'mesa-native', 'virglrenderer-native', 'wayland-protocols-native', 'wayland-native', 'xrandr-nat
> ive', 'libpciaccess-native', 'libpthread-stubs-native', 'libx11-native', 'libxau-native', 'libxcb-native', 'libxdamage-native', 'libxdmcp-native', 'libxext-native', 'libxfixes-native', 'libxrandr-native', 'libxrender-native', 'libxshmfence-native', 'libxxf86vm-native', 'pixman-native', 'xtrans-native', 'xcb-proto-native', 'xorgproto-native', 'makedepend-native', 'util-macros-native', 'dtc-native', 'kmod-native', 'alsa-lib-native', 'libpng-native', 'acl-native', 'attr-native', 'bmaptool-native', 'curl-native', 'deb
> ianutils-native', 'gdbm-native', 'gmp-native', 'gnutls-native', 'libtasn1-native', 'libbsd-native', 'libcap-ng-native', 'libcap-native', 'libffi-native', 'libgcrypt-native', 'libgpg-error-native', 'libmd-native', 'libmicrohttpd-native', 'libpcre2-native', 'libunistring-native', 'lz4-native', 'lzo-native', 'nettle-native', 'popt-native', 'shared
> -mime-info-native', 'sqlite3-native']
> | DEBUG: Python function extend_recipe_sysroot finished
> | DEBUG: Executing python function set_image_size
> | DEBUG: 159546.400000 = 122728 * 1.300000
> | DEBUG: 163642.400000 = max(159546.400000, 8192)[159546.400000] + 4096
> | DEBUG: 163643.000000 = int(163642.400000)
> | DEBUG: 163643 = aligned(163643)
> | DEBUG: returning 163643
> | DEBUG: Python function set_image_size finished
> | DEBUG: Executing shell function do_image_wic
> | abort()ing pseudo client by server request. See https://wiki.yoctoproject.org/wiki/Pseudo_Abort for more details on this.
> | Check logfile: /home/mcfrisk/src/base/poky/build_genericarm64-st/tmp/work/genericarm64-poky-linux/core-image-minimal/1.0/pseudo//pseudo.log
> | WARNING: exit code 134 from a shell command.
> | Aborted
> NOTE: recipe core-image-minimal-1.0-r0: task do_image_wic: Failed
> ERROR: Task (/home/mcfrisk/src/base/poky/meta/recipes-core/images/core-image-minimal.bb:do_image_wic) failed with exit code '1' 
> Pseudo log:
> path mismatch [2 links]: ino 43965780 db '/home/mcfrisk/src/base/poky/build_genericarm64-st/tmp/work/genericarm64-poky-linux/core-image-minimal/1.0/rootfs/boot/loader/loader.conf' req '/home/mcfrisk/src/base/poky/build_genericarm64-st/tmp/work/genericarm64-poky-linux/core-image-minimal/1.0/tmp-wic/rootfs1/boot/loader/loader.conf'.
> Setup complete, sending SIGUSR1 to pid 117389.
>
> NOTE: Tasks Summary: Attempted 5254 tasks of which 5253 didn't need to be rerun and 1 failed.
>
> Summary: 1 task failed:
>   /home/mcfrisk/src/base/poky/meta/recipes-core/images/core-image-minimal.bb:do_image_wic
>     log: /home/mcfrisk/src/base/poky/build_genericarm64-st/tmp/work/genericarm64-poky-linux/core-image-minimal/1.0/temp/log.do_image_wic.117565
> Summary: There was 1 ERROR message, returning a non-zero exit code.
>
> 2025-04-07 09:10:05,488 - oe-selftest - INFO - ======================================================================
> 2025-04-07 09:10:05,488 - oe-selftest - INFO - FAIL: test_permissions (wic.Wic.test_permissions)
> 2025-04-07 09:10:05,489 - oe-selftest - INFO - ----------------------------------------------------------------------
> 2025-04-07 09:10:05,489 - oe-selftest - INFO - Traceback (most recent call last):
>   File "/home/mcfrisk/src/base/poky/meta/lib/oeqa/selftest/cases/wic.py", line 677, in test_permissions
>     bitbake('core-image-minimal')
>   File "/home/mcfrisk/src/base/poky/meta/lib/oeqa/utils/commands.py", line 236, in bitbake
>     return runCmd(cmd, ignore_status, timeout, output_log=output_log, **options)
>            ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>   File "/home/mcfrisk/src/base/poky/meta/lib/oeqa/utils/commands.py", line 214, in runCmd
>     raise AssertionError("Command '%s' returned non-zero exit status %d:\n%s" % (command, result.status, exc_output))
> AssertionError: Command 'bitbake  core-image-minimal' returned non-zero exit status 1:
> Loading cache...done.
> Loaded 1976 entries from dependency cache.
> NOTE: Resolving any missing task queue dependencies
>
> Build Configuration:
> BB_VERSION           = "2.12.0"
> BUILD_SYS            = "aarch64-linux"
> NATIVELSBSTRING      = "universal"
> TARGET_SYS           = "aarch64-poky-linux"
> MACHINE              = "genericarm64"
> DISTRO               = "poky-altcfg"
> DISTRO_VERSION       = "5.2"
> TUNE_FEATURES        = "aarch64 armv8a crc"
> TARGET_FPU           = ""
> meta                 
> meta-poky            
> meta-yocto-bsp       = "HEAD:a75117f79e4771927b89125e464e38acdc9c556e"
> meta-selftest        = "master:fd26cf3cc0e6e590b56e331971cdf884d1b881b9"
>
> Initialising tasks...Sstate summary: Wanted 539 Local 536 Mirrors 0 Missed 3 Current 1968 (99% match, 99% complete)
> Removing 3 stale sstate objects for arch genericarm64...done.
> NOTE: Executing Tasks
> NOTE: Running task 5157 of 5259 (/home/mcfrisk/src/base/poky/meta/recipes-core/images/core-image-minimal.bb:do_image_wic)
> NOTE: recipe core-image-minimal-1.0-r0: task do_image_wic: Started
> ERROR: core-image-minimal-1.0-r0 do_image_wic: Execution of '/home/mcfrisk/src/base/poky/build_genericarm64-st/tmp/work/genericarm64-poky-linux/core-image-minimal/1.0/temp/r
> un.do_image_wic.117565' failed with exit code 134
> ERROR: Logfile of failure stored in: /home/mcfrisk/src/base/poky/build_genericarm64-st/tmp/work/genericarm64-poky-linux/core-image-minimal/1.0/temp/log.do_image_wic.117565
> Log data follows:
> | DEBUG: Executing python function extend_recipe_sysroot
> | NOTE: Direct dependencies are ['/home/mcfrisk/src/base/poky/meta/recipes-bsp/grub/grub-efi_2.12.bb:do_populate_sysroot', '/home/mcfrisk/src/base/poky/meta/recipes-core/glibc/cross-localedef-native_2.41.bb:do_populate_sysroot', '/home/mcfrisk/src/base/poky/meta/recipes-core/glibc/ldconfig-native_2.12.1.bb:do_populate_sysroot', '/home/mcfrisk/s
> rc/base/poky/meta/recipes-core/systemd/systemd-boot_257.4.bb:do_populate_sysroot', '/home/mcfrisk/src/base/poky/meta/recipes-devtools/binutils/binutils-cross_2.44.bb:do_populate_sysroot', '/home/mcfrisk/src/base/poky/meta/recipes-devtools/cdrtools/cdrtools-native_3.01.bb:do_populate_sysroot', '/home/mcfrisk/src/base/poky/meta/recipes-devtools/qemu/qemuwrapper-cross_1.0.bb:do_populate_sysroot', '/home/mcfrisk/src/base/poky/meta/recipes-kernel/kmod/depmodwrapper-cross_1.0.bb:do_populate_sysroot', 'virtual:native:/ho
> me/mcfrisk/src/base/poky/meta/recipes-core/update-rc.d/update-rc.d_0.8.bb:do_populate_sysroot', 'virtual:native:/home/mcfrisk/src/base/poky/meta/recipes-devtools/btrfs-tools/btrfs-tools_6.14.bb:do_populate_sysroot', 'virtual:native:/home/mcfrisk/src/base/poky/meta/recipes-devtools/dosfstools/dosfstools_4.2.bb:do_populate_sysroot', 'virtual:nati
> ve:/home/mcfrisk/src/base/poky/meta/recipes-devtools/e2fsprogs/e2fsprogs_1.47.1.bb:do_populate_sysroot', 'virtual:native:/home/mcfrisk/src/base/poky/meta/recipes-devtools/erofs-utils/erofs-utils_1.8.5.bb:do_populate_sysroot', 'virtual:native:/home/mcfrisk/src/base/poky/meta/recipes-devtools/fdisk/gptfdisk_1.0.10.bb:do_populate_sysroot', 'virtual:native:/home/mcfrisk/src/base/poky/meta/recipes-devtools/makedevs/makedevs_1.0.1.bb:do_populate_sysroot', 'virtual:native:/home/mcfrisk/src/base/poky/meta/recipes-devtools/mtools/mtools_4.0.48.bb:do_populate_sysroot', 'virtual:native:/home/mcfrisk/src/base/poky/meta/recipes-devtools/opkg-utils/opkg-utils_0.7.0.bb:do_populate_sysroot', 'virtua
> l:native:/home/mcfrisk/src/base/poky/meta/recipes-devtools/opkg/opkg_0.7.0.bb:do_populate_sysroot', 'virtual:native:/home/mcfrisk/src/base/poky/meta/recipes-devtools/pseudo/
> pseudo_git.bb:do_populate_sysroot', 'virtual:native:/home/mcfrisk/src/base/poky/meta/recipes-devtools/squashfs-tools/squashfs-tools_git.bb:do_populate_sysroot', 'virtual:native:/home/mcfrisk/src/base/poky/meta/recipes-extended/parted/parted_3.6.bb:do_populate_sysroot', 'virtual:native:/home/mcfrisk/src/base/poky/meta/recipes-extended/pigz/pigz_2.8.bb:do_populate_sysroot', 'virtual:native:/home/mcfrisk/src/base/poky/meta/recipes-support/bmaptool/bmaptool_git.bb:do_populate_sysroot']
> | NOTE: Installed into sysroot: []
> | NOTE: Skipping as already exists in sysroot: ['grub-efi', 'gettext-minimal-native', 'cross-localedef-native', 'glibc', 'ldconfig-native', 'libxcrypt', 'ncurses', 'systemd-boot', 'systemd-systemctl-native', 'util-linux-libuuid', 'util-linux', 'zlib', 'binutils-cross-aarch64', 'cdrtools-native', 'cmake-native', 'gcc-runtime', 'libgcc', 'libtool
> -native', 'm4-native', 'opkg-utils', 'qemu-helper-native', 'qemu-native', 'qemu-system-native', 'qemuwrapper-cross', 'libpam', 'texinfo-dummy-native', 'depmodwrapper-cross', 'linux-libc-headers', 'bash-completion', 'libcap-ng', 'libcap', 'sqlite3', 'openssl-native', 'libslirp-native', 'coreutils-native', 'expat-native', 'gettext-native', 'glib-
> 2.0-native', 'libxml2-native', 'ncurses-native', 'readline-native', 'update-rc.d-native', 'util-linux-libuuid-native', 'util-linux-native', 'zlib-native', 'btrfs-tools-native', 'chrpath-native', 'dosfstools-native', 'e2fsprogs-native', 'elfutils-native', 'erofs-utils-native', 'gptfdisk-native', 'flex-native', 'gnu-config-native', 'json-c-native', 'libedit-native', 'llvm-native', 'make-native', 'makedevs-native', 'mtools-native', 'opkg-utils-native', 'opkg-native', 'perl-native', 'pseudo-native', 'python3-build-nat
> ive', 'python3-calver-native', 'python3-editables-native', 'python3-flit-core-native', 'python3-hatchling-native', 'python3-installer-native', 'python3-jinja2-native', 'python3-mako-native', 'python3-markupsafe-native', 'python3-packaging-native', 'python3-pathspec-native', 'python3-pip-native', 'python3-pluggy-native', 'python3-pygments-native
> ', 'python3-pyparsing-native', 'python3-pyproject-hooks-native', 'python3-setuptools-scm-native', 'python3-setuptools-native', 'python3-six-native', 'python3-trove-classifiers-native', 'python3-typing-extensions-native', 'python3-wheel-native', 'python3-native', 'squashfs-tools-native', 'unfs3-native', 'bzip2-native', 'cpio-native', 'diffutils-native', 'libarchive-native', 'libidn2-native', 'libnsl2-native', 'libsolv-native', 'libtirpc-native', 'parted-native', 'pigz-native', 'shadow-native', 'unzip-native', 'xz-n
> ative', 'zstd-native', 'libdrm-native', 'libepoxy-native', 'libsdl2-native', 'mesa-native', 'virglrenderer-native', 'wayland-protocols-native', 'wayland-native', 'xrandr-native', 'libpciaccess-native', 'libpthread-stubs-native', 'libx11-native', 'libxau-native', 'libxcb-native', 'libxdamage-native', 'libxdmcp-native', 'libxext-native', 'libxfix
> es-native', 'libxrandr-native', 'libxrender-native', 'libxshmfence-native', 'libxxf86vm-native', 'pixman-native', 'xtrans-native', 'xcb-proto-native', 'xorgproto-native', 'makedepend-native', 'util-macros-native', 'dtc-native', 'kmod-native', 'alsa-lib-native', 'libpng-native', 'acl-native', 'attr-native', 'bmaptool-native', 'curl-native', 'debianutils-native', 'gdbm-native', 'gmp-native', 'gnutls-native', 'libtasn1-native', 'libbsd-native', 'libcap-ng-native', 'libcap-native', 'libffi-native', 'libgcrypt-native',
>  'libgpg-error-native', 'libmd-native', 'libmicrohttpd-native', 'libpcre2-native', 'libunistring-native', 'lz4-native', 'lzo-native', 'nettle-native', 'popt-native', 'shared-mime-info-native', 'sqlite3-native']
> | DEBUG: Python function extend_recipe_sysroot finished
> | DEBUG: Executing python function set_image_size
> | DEBUG: 159546.400000 = 122728 * 1.300000
> | DEBUG: 163642.400000 = max(159546.400000, 8192)[159546.400000] + 4096
> | DEBUG: 163643.000000 = int(163642.400000)
> | DEBUG: 163643 = aligned(163643)
> | DEBUG: returning 163643
> | DEBUG: Python function set_image_size finished
> | DEBUG: Executing shell function do_image_wic
> | abort()ing pseudo client by server request. See https://wiki.yoctoproject.org/wiki/Pseudo_Abort for more details on this.
> | Check logfile: /home/mcfrisk/src/base/poky/build_genericarm64-st/tmp/work/genericarm64-poky-linux/core-image-minimal/1.0/pseudo//pseudo.log
> | WARNING: exit code 134 from a shell command.
> | Aborted
> NOTE: recipe core-image-minimal-1.0-r0: task do_image_wic: Failed
> ERROR: Task (/home/mcfrisk/src/base/poky/meta/recipes-core/images/core-image-minimal.bb:do_image_wic) failed with exit code '1' 
> Pseudo log:
> path mismatch [2 links]: ino 43965780 db '/home/mcfrisk/src/base/poky/build_genericarm64-st/tmp/work/genericarm64-poky-linux/core-image-minimal/1.0/rootfs/boot/loader/loader.conf' req '/home/mcfrisk/src/base/poky/build_genericarm64-st/tmp/work/genericarm64-poky-linux/core-image-minimal/1.0/tmp-wic/rootfs1/boot/loader/loader.conf'.
> Setup complete, sending SIGUSR1 to pid 117389.
>
> NOTE: Tasks Summary: Attempted 5254 tasks of which 5253 didn't need to be rerun and 1 failed.
>
> Summary: 1 task failed:
>   /home/mcfrisk/src/base/poky/meta/recipes-core/images/core-image-minimal.bb:do_image_wic
>     log: /home/mcfrisk/src/base/poky/build_genericarm64-st/tmp/work/genericarm64-poky-linux/core-image-minimal/1.0/temp/log.do_image_wic.117565
> Summary: There was 1 ERROR message, returning a non-zero exit code.
> ----------------------------------------------------------------------
> 2025-04-07 09:10:05,489 - oe-selftest - INFO - Ran 1 test in 2271.863s
> 2025-04-07 09:10:05,489 - oe-selftest - INFO - FAILED
> 2025-04-07 09:10:05,489 - oe-selftest - INFO -  (failures=1)
> 2025-04-07 09:10:11,706 - oe-selftest - INFO - RESULTS:
> 2025-04-07 09:10:11,706 - oe-selftest - INFO - RESULTS - wic.Wic.test_permissions: FAILED (2271.66s)
> 2025-04-07 09:10:11,708 - oe-selftest - INFO - SUMMARY:
> 2025-04-07 09:10:11,708 - oe-selftest - INFO - oe-selftest () - Ran 1 test in 2271.863s
> 2025-04-07 09:10:11,708 - oe-selftest - INFO - oe-selftest - FAIL - Required tests failed (successes=0, skipped=0, failures=1, errors=0)
>
> I think something in this test is faulty. For example building an image
> in yocto do_image with fakeroot/pseudo and then modifying it outside of build
> env with wic is likely going to fail like this.
>
> I will try with other machine targets and cleaner local.conf
> but I suspect I will run into this same issue again.
>
> And the error from your CI buidl was completely different... :/
>
> Cheers,
>
> -Mikko

I confirm, localally I see the same thing as you do: just some pseudo
errors. They seem to come from "image_types_wic.bbclass: capture verbose
wic output by default" patch.

So yes, different than on the autobuilder, but yet if I drop the series,
autobuilder builds do succeed :(

So we can hope there is an obscure link between both failures, but
that's all I've got so far.

-- 
Mathieu Dubois-Briand, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com

Re: [OE-core] [PATCH v3 00/11] systemd based initrd and modular kernel support

[Mikko Rapeli]

Hi,

On Mon, Apr 07, 2025 at 11:52:01AM +0200, Mathieu Dubois-Briand wrote:
> On Mon Apr 7, 2025 at 11:24 AM CEST, Mikko Rapeli wrote:
> > On Mon, Apr 07, 2025 at 10:51:43AM +0200, Mathieu Dubois-Briand wrote:
> >> On Mon Apr 7, 2025 at 10:10 AM CEST, Mikko Rapeli wrote:
> >> > Hi,
> >> >
> >> > On Mon, Apr 07, 2025 at 09:53:45AM +0200, Mathieu Dubois-Briand wrote:
> >> >> On Fri Apr 4, 2025 at 6:29 PM CEST, Mikko Rapeli via lists.openembedded.org wrote:
> >> >> > systemd based initrd supports more security, encryption etc features
> >> >> > than custom shell script ones but oe-core lacks support for it.
> >> >> > Convert core-image-initramfs-boot to create systemd based initrd
> >> >> > if "systemd-initramfs" is set in DISTRO_FEATURES. Includes a test
> >> >> > for this initrd to mount rootfs via Unified Kernel Image uki.py.
> >> >> >
> >> >> > Sadly the boot time is really slow, e.g. over 30 seconds with
> >> >> > systemd based initrd. One of the major reasons is the large
> >> >> > amount of kernel modules built into the linux-yocto kernel and
> >> >> > processing of their udev events in userspace. Thus add
> >> >> > kernel-initrd-modules meta package to easily install
> >> >> > subset of all kernel modules to initrd. The subset
> >> >> > supports "mount rootfs from any block device" but
> >> >> > doesn't include graphics, UBS etc support. Without this
> >> >> > generated meta package, initrd recipe needs to manually define
> >> >> > which exact kernel modules to include which breaks if
> >> >> > those modules are built into the kernel. Thus the initrd
> >> >> > becomes machine and kernel config specific and hard to maintain.
> >> >> > With this meta package a generic initrd can be created.
> >> >> >
> >> >> > Separate changes to linux-yocto compile a lot more drivers
> >> >> > as modules but they depend on these initrd changes.
> >> >> >
> >> >> 
> >> >> Hi Mikko,
> >> >> 
> >> >> Thanks for your patch.
> >> >> 
> >> >> I believe one of these wic related patches is responsible of some
> >> >> oe-selftest failures we can see on the autobuilder:
> >> >> 
> >> >> 2025-04-06 15:51:49,317 - oe-selftest - INFO - wic.Wic.test_permissions (subunit.RemotedTestCase)
> >> >> 2025-04-06 15:51:49,318 - oe-selftest - INFO -  ... FAIL
> >> >> 
> >> >> ...
> >> >> 
> >> >> ERROR: When reparsing /tmp/selftest-fetchsrayuxoq/test.bb:do_checkuri, the basehash value changed from 84b9e23a83a764e7a5d8a96ee523199e2b1c604f4280a45030e248de0ff52962 to 4123da244f465feffecb2b4fd2b132b64851981ec2fb70bf9445df8b0ea6a69e. The metadata is not deterministic and this needs to be fixed.
> >> >> ERROR: The following commands may help:
> >> >> ERROR: $ bitbake test -cdo_checkuri -Snone
> >> >> ERROR: Then:
> >> >> ERROR: $ bitbake test -cdo_checkuri -Sprintdiff
> >> >> 
> >> >> ERROR: When reparsing /tmp/selftest-fetchsrayuxoq/test.bb:do_fetch, the basehash value changed from 6d55d6743729b615749dc016857d7e5f9c884a8b92f0d57f68e743f4910333d3 to fa7d6ea0563b60362418d2a6c5e41a6684183d01ec578b65abd0c64a9cfba7cf. The metadata is not deterministic and this needs to be fixed.
> >> >> ERROR: The following commands may help:
> >> >> ERROR: $ bitbake test -cdo_fetch -Snone
> >> >> ERROR: Then:
> >> >> ERROR: $ bitbake test -cdo_fetch -Sprintdiff
> >> >> 
> >> >> ERROR: When reparsing /tmp/selftest-fetchsrayuxoq/test.bb:do_unpack, the basehash value changed from ae9d94aafc721d891f8754df82ed90da8191357178f3db64221a49d5c1de3bcd to 1ac8f87a71db151b8eb2ae8d13f9a6ea1a0c884ef98555d61d2c2fe07a476a8a. The metadata is not deterministic and this needs to be fixed.
> >> >> ERROR: The following commands may help:
> >> >> ERROR: $ bitbake test -cdo_unpack -Snone
> >> >> ERROR: Then:
> >> >> ERROR: $ bitbake test -cdo_unpack -Sprintdiff
> >> >> 
> >> >> ...
> >> >> 
> >> >> https://autobuilder.yoctoproject.org/valkyrie/#/builders/23/builds/1391
> >> >> 
> >> >> Can you have a look at this please?
> >> >
> >> > I can have a look but how can these patches change the basehash'es when testing?
> >> >
> >> > I've seen some of the wic selftets failing on x86_64 build machine with zfs
> >> > but changes to fix this was rejected multiple times.
> >> >
> >> > Then I've seen some of these failing with odd pseudo failures on aarch64
> >> > build machine.
> >> >
> >> > With my patches the end result was the same.
> >> >
> >> > I ran wic and uki selftests on x86_64 and aarch64 build machines for targets qemuarm64,
> >> > qemuarm and genericx86-64.
> >> >
> >> > The wic patches have actually nothing to do with this series except I ran into bugs
> >> > in wic which resulted in unbootable images, e.g. the UEFI bootloader binaries
> >> > missing from ESP partition. These were impacting some builds but not all
> >> > which was really troubling.
> >> >
> >> > Cheers,
> >> >
> >> > -Mikko
> >> 
> >> Ok, I am running some git bisect locally anyway, I will keep you updated
> >> a bit later today.
> >
> > I ran wic.Wic.test_permissions and it passed without this series
> > on aarch64 build machine and genericarm64 target machine:
> >
> > NOTE: Reconnecting to bitbake server...
> > NOTE: Retrying server connection (#1)... (08:13:45.320086)
> > NOTE: Reconnecting to bitbake server...
> > NOTE: Reconnecting to bitbake server...
> > NOTE: Retrying server connection (#1)... (08:13:45.320086)
> > NOTE: Retrying server connection (#1)... (08:13:45.320086)
> > NOTE: Starting bitbake server...
> > hint: Using 'master' as the name for the initial branch. This default branch name
> > hint: is subject to change. To configure the initial branch name to use in all
> > hint: of your new repositories, which will suppress this warning, call:
> > hint: 
> > hint:   git config --global init.defaultBranch <name>
> > hint: 
> > hint: Names commonly chosen instead of 'master' are 'main', 'trunk' and
> > hint: 'development'. The just-created branch can be renamed via this command:
> > hint: 
> > hint:   git branch -m <name>
> > 2025-04-07 08:13:46,418 - oe-selftest - INFO - Adding: "include selftest.inc" in /home/mcfrisk/src/base/poky/build_genericarm64-st/conf/local.conf
> > 2025-04-07 08:13:46,418 - oe-selftest - INFO - Adding: "include bblayers.inc" in bblayers.conf
> > 2025-04-07 08:13:46,418 - oe-selftest - INFO - test_permissions (wic.Wic.test_permissions)
> > 2025-04-07 08:24:47,941 - oe-selftest - INFO -  ... ok
> > 2025-04-07 08:24:54,376 - oe-selftest - INFO - ----------------------------------------------------------------------
> > 2025-04-07 08:24:54,376 - oe-selftest - INFO - Ran 1 test in 668.167s
> > 2025-04-07 08:24:54,376 - oe-selftest - INFO - OK
> > 2025-04-07 08:25:00,978 - oe-selftest - INFO - RESULTS:
> > 2025-04-07 08:25:00,978 - oe-selftest - INFO - RESULTS - wic.Wic.test_permissions: PASSED (661.52s)
> > 2025-04-07 08:25:00,979 - oe-selftest - INFO - SUMMARY:
> > 2025-04-07 08:25:00,979 - oe-selftest - INFO - oe-selftest () - Ran 1 test in 668.168s
> > 2025-04-07 08:25:00,979 - oe-selftest - INFO - oe-selftest - OK - All required tests passed (successes=1, skipped=0, failures=0, errors=0)
> >
> > Then with patches from this series (and a few more which I sent out separately,
> > should be unrelated) it failed with pseudo errors:
> >
> > 2025-04-07 08:32:12,107 - oe-selftest - INFO - Changing cwd to /home/mcfrisk/src/base/poky/build_genericarm64
> > 2025-04-07 08:32:12,107 - oe-selftest - INFO - Adding layer libraries:
> > 2025-04-07 08:32:12,107 - oe-selftest - INFO -  /home/mcfrisk/src/base/poky/meta/lib
> > 2025-04-07 08:32:12,107 - oe-selftest - INFO -  /home/mcfrisk/src/base/poky/meta-yocto-bsp/lib
> > 2025-04-07 08:32:12,107 - oe-selftest - INFO -  /home/mcfrisk/src/base/poky/meta-selftest/lib
> > 2025-04-07 08:32:12,108 - oe-selftest - INFO - Checking base configuration is valid/parsable
> > NOTE: Reconnecting to bitbake server...
> > NOTE: Retrying server connection (#1)... (08:32:12.728357)
> > NOTE: Reconnecting to bitbake server...
> > NOTE: Reconnecting to bitbake server...
> > NOTE: Retrying server connection (#1)... (08:32:12.728357)
> > NOTE: Retrying server connection (#1)... (08:32:12.728357)
> > NOTE: Starting bitbake server...
> > hint: Using 'master' as the name for the initial branch. This default branch name
> > hint: is subject to change. To configure the initial branch name to use in all
> > hint: of your new repositories, which will suppress this warning, call:
> > hint: 
> > hint:   git config --global init.defaultBranch <name>
> > hint: 
> > hint: Names commonly chosen instead of 'master' are 'main', 'trunk' and
> > hint: 'development'. The just-created branch can be renamed via this command:
> > hint: 
> > hint:   git branch -m <name>
> > 2025-04-07 08:32:13,824 - oe-selftest - INFO - Adding: "include selftest.inc" in /home/mcfrisk/src/base/poky/build_genericarm64-st/conf/local.conf
> > 2025-04-07 08:32:13,824 - oe-selftest - INFO - Adding: "include bblayers.inc" in bblayers.conf
> > 2025-04-07 08:32:13,824 - oe-selftest - INFO - test_permissions (wic.Wic.test_permissions)
> > 2025-04-07 09:10:05,405 - oe-selftest - INFO -  ... FAIL
> > 2025-04-07 09:10:05,488 - oe-selftest - INFO - Traceback (most recent call last):
> >   File "/home/mcfrisk/src/base/poky/meta/lib/oeqa/selftest/cases/wic.py", line 677, in test_permissions
> >     bitbake('core-image-minimal')
> >   File "/home/mcfrisk/src/base/poky/meta/lib/oeqa/utils/commands.py", line 236, in bitbake
> >     return runCmd(cmd, ignore_status, timeout, output_log=output_log, **options)
> >            ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> >   File "/home/mcfrisk/src/base/poky/meta/lib/oeqa/utils/commands.py", line 214, in runCmd
> >     raise AssertionError("Command '%s' returned non-zero exit status %d:\n%s" % (command, result.status, exc_output))
> > AssertionError: Command 'bitbake  core-image-minimal' returned non-zero exit status 1:
> > Loading cache...done.
> > Loaded 1976 entries from dependency cache.
> > NOTE: Resolving any missing task queue dependencies
> >
> > Build Configuration:
> > BB_VERSION           = "2.12.0"
> > BUILD_SYS            = "aarch64-linux"
> > NATIVELSBSTRING      = "universal"
> > TARGET_SYS           = "aarch64-poky-linux"
> > MACHINE              = "genericarm64"
> > DISTRO               = "poky-altcfg"
> > DISTRO_VERSION       = "5.2"
> > TUNE_FEATURES        = "aarch64 armv8a crc"
> > TARGET_FPU           = ""
> > meta                 
> > meta-poky            
> > meta-yocto-bsp       = "HEAD:a75117f79e4771927b89125e464e38acdc9c556e"
> > meta-selftest        = "master:fd26cf3cc0e6e590b56e331971cdf884d1b881b9"
> >
> > Initialising tasks...Sstate summary: Wanted 539 Local 536 Mirrors 0 Missed 3 Current 1968 (99% match, 99% complete)
> > Removing 3 stale sstate objects for arch genericarm64...done.
> > NOTE: Executing Tasks
> > NOTE: Running task 5157 of 5259 (/home/mcfrisk/src/base/poky/meta/recipes-core/images/core-image-minimal.bb:do_image_wic)
> > NOTE: recipe core-image-minimal-1.0-r0: task do_image_wic: Started
> > ERROR: core-image-minimal-1.0-r0 do_image_wic: Execution of '/home/mcfrisk/src/base/poky/build_genericarm64-st/tmp/work/genericarm64-poky-linux/core-image-minimal/1.0/temp/run.do_image_wic.117565' failed with exit code 134
> > ERROR: Logfile of failure stored in: /home/mcfrisk/src/base/poky/build_genericarm64-st/tmp/work/genericarm64-poky-linux/core-image-minimal/1.0/temp/log.do_image_wic.117565
> > Log data follows:
> > | DEBUG: Executing python function extend_recipe_sysroot
> > | NOTE: Direct dependencies are ['/home/mcfrisk/src/base/poky/meta/recipes-bsp/grub/grub-efi_2.12.bb:do_populate_sysroot', '/home/mcfrisk/src/base/poky/meta/recipes-core/gli
> > bc/cross-localedef-native_2.41.bb:do_populate_sysroot', '/home/mcfrisk/src/base/poky/meta/recipes-core/glibc/ldconfig-native_2.12.1.bb:do_populate_sysroot', '/home/mcfrisk/src/base/poky/meta/recipes-core/systemd/systemd-boot_257.4.bb:do_populate_sysroot', '/home/mcfrisk/src/base/poky/meta/recipes-devtools/binutils/binutils-cross_2.44.bb:do_popu
> > late_sysroot', '/home/mcfrisk/src/base/poky/meta/recipes-devtools/cdrtools/cdrtools-native_3.01.bb:do_populate_sysroot', '/home/mcfrisk/src/base/poky/meta/recipes-devtools/qemu/qemuwrapper-cross_1.0.bb:do_populate_sysroot', '/home/mcfrisk/src/base/poky/meta/recipes-kernel/kmod/depmodwrapper-cross_1.0.bb:do_populate_sysroot', 'virtual:native:/home/mcfrisk/src/base/poky/meta/recipes-core/update-rc.d/update-rc.d_0.8.bb:do_populate_sysroot', 'virtual:native:/home/mcfrisk/src/base/poky/meta/recipes-devtools/btrfs-tools
> > /btrfs-tools_6.14.bb:do_populate_sysroot', 'virtual:native:/home/mcfrisk/src/base/poky/meta/recipes-devtools/dosfstools/dosfstools_4.2.bb:do_populate_sysroot', 'virtual:native:/home/mcfrisk/src/base/poky/meta/recipes-devtools/e2fsprogs/e2fsprogs_1.47.1.bb:do_populate_sysroot', 'virtual:native:/home/mcfrisk/src/base/poky/meta/recipes-devtools/er
> > ofs-utils/erofs-utils_1.8.5.bb:do_populate_sysroot', 'virtual:native:/home/mcfrisk/src/base/poky/meta/recipes-devtools/fdisk/gptfdisk_1.0.10.bb:do_populate_sysroot', 'virtual:native:/home/mcfrisk/src/base/poky/meta/recipes-devtools/makedevs/makedevs_1.0.1.bb:do_populate_sysroot', 'virtual:native:/home/mcfrisk/src/base/poky/meta/recipes-devtools/mtools/mtools_4.0.48.bb:do_populate_sysroot', 'virtual:native:/home/mcfrisk/src/base/poky/meta/recipes-devtools/opkg-utils/opkg-utils_0.7.0.bb:do_populate_sysroot', 'virtua
> > l:native:/home/mcfrisk/src/base/poky/meta/recipes-devtools/opkg/opkg_0.7.0.bb:do_populate_sysroot', 'virtual:native:/home/mcfrisk/src/base/poky/meta/recipes-devtools/pseudo/pseudo_git.bb:do_populate_sysroot', 'virtual:native:/home/mcfrisk/src/base/poky/meta/recipes-devtools/squashfs-tools/squashfs-tools_git.bb:do_populate_sysroot', 'virtual:nat
> > ive:/home/mcfrisk/src/base/poky/meta/recipes-extended/parted/parted_3.6.bb:do_populate_sysroot', 'virtual:native:/home/mcfrisk/src/base/poky/meta/recipes-extended/pigz/pigz_
> > 2.8.bb:do_populate_sysroot', 'virtual:native:/home/mcfrisk/src/base/poky/meta/recipes-support/bmaptool/bmaptool_git.bb:do_populate_sysroot']
> > | NOTE: Installed into sysroot: []
> > | NOTE: Skipping as already exists in sysroot: ['grub-efi', 'gettext-minimal-native', 'cross-localedef-native', 'glibc', 'ldconfig-native', 'libxcrypt', 'ncurses', 'systemd-
> > boot', 'systemd-systemctl-native', 'util-linux-libuuid', 'util-linux', 'zlib', 'binutils-cross-aarch64', 'cdrtools-native', 'cmake-native', 'gcc-runtime', 'libgcc', 'libtool-native', 'm4-native', 'opkg-utils', 'qemu-helper-native', 'qemu-native', 'qemu-system-native', 'qemuwrapper-cross', 'libpam', 'texinfo-dummy-native', 'depmodwrapper-cross', 'linux-libc-headers', 'bash-completion', 'libcap-ng', 'libcap', 'sqlite3', 'openssl-native', 'libslirp-native', 'coreutils-native', 'expat-native', 'gettext-native', 'glib-
> > 2.0-native', 'libxml2-native', 'ncurses-native', 'readline-native', 'update-rc.d-native', 'util-linux-libuuid-native', 'util-linux-native', 'zlib-native', 'btrfs-tools-nativ
> > e', 'chrpath-native', 'dosfstools-native', 'e2fsprogs-native', 'elfutils-native', 'erofs-utils-native', 'gptfdisk-native', 'flex-native', 'gnu-config-native', 'json-c-native
> > ', 'libedit-native', 'llvm-native', 'make-native', 'makedevs-native', 'mtools-native', 'opkg-utils-native', 'opkg-native', 'perl-native', 'pseudo-native', 'python3-build-native', 'python3-calver-native', 'python3-editables-native', 'python3-flit-core-native', 'python3-hatchling-native', 'python3-installer-native', 'python3-jinja2-native', 'pyth
> > on3-mako-native', 'python3-markupsafe-native', 'python3-packaging-native', 'python3-pathspec-native', 'python3-pip-native', 'python3-pluggy-native', 'python3-pygments-native
> > ', 'python3-pyparsing-native', 'python3-pyproject-hooks-native', 'python3-setuptools-scm-native', 'python3-setuptools-native', 'python3-six-native', 'python3-trove-classifiers-native', 'python3-typing-extensions-native', 'python3-wheel-native', 'python3-native', 'squashfs-tools-native', 'unfs3-native', 'bzip2-native', 'cpio-native', 'diffutils-
> > native', 'libarchive-native', 'libidn2-native', 'libnsl2-native', 'libsolv-native', 'libtirpc-native', 'parted-native', 'pigz-native', 'shadow-native', 'unzip-native', 'xz-native', 'zstd-native', 'libdrm-native', 'libepoxy-native', 'libsdl2-native', 'mesa-native', 'virglrenderer-native', 'wayland-protocols-native', 'wayland-native', 'xrandr-nat
> > ive', 'libpciaccess-native', 'libpthread-stubs-native', 'libx11-native', 'libxau-native', 'libxcb-native', 'libxdamage-native', 'libxdmcp-native', 'libxext-native', 'libxfixes-native', 'libxrandr-native', 'libxrender-native', 'libxshmfence-native', 'libxxf86vm-native', 'pixman-native', 'xtrans-native', 'xcb-proto-native', 'xorgproto-native', 'makedepend-native', 'util-macros-native', 'dtc-native', 'kmod-native', 'alsa-lib-native', 'libpng-native', 'acl-native', 'attr-native', 'bmaptool-native', 'curl-native', 'deb
> > ianutils-native', 'gdbm-native', 'gmp-native', 'gnutls-native', 'libtasn1-native', 'libbsd-native', 'libcap-ng-native', 'libcap-native', 'libffi-native', 'libgcrypt-native', 'libgpg-error-native', 'libmd-native', 'libmicrohttpd-native', 'libpcre2-native', 'libunistring-native', 'lz4-native', 'lzo-native', 'nettle-native', 'popt-native', 'shared
> > -mime-info-native', 'sqlite3-native']
> > | DEBUG: Python function extend_recipe_sysroot finished
> > | DEBUG: Executing python function set_image_size
> > | DEBUG: 159546.400000 = 122728 * 1.300000
> > | DEBUG: 163642.400000 = max(159546.400000, 8192)[159546.400000] + 4096
> > | DEBUG: 163643.000000 = int(163642.400000)
> > | DEBUG: 163643 = aligned(163643)
> > | DEBUG: returning 163643
> > | DEBUG: Python function set_image_size finished
> > | DEBUG: Executing shell function do_image_wic
> > | abort()ing pseudo client by server request. See https://wiki.yoctoproject.org/wiki/Pseudo_Abort for more details on this.
> > | Check logfile: /home/mcfrisk/src/base/poky/build_genericarm64-st/tmp/work/genericarm64-poky-linux/core-image-minimal/1.0/pseudo//pseudo.log
> > | WARNING: exit code 134 from a shell command.
> > | Aborted
> > NOTE: recipe core-image-minimal-1.0-r0: task do_image_wic: Failed
> > ERROR: Task (/home/mcfrisk/src/base/poky/meta/recipes-core/images/core-image-minimal.bb:do_image_wic) failed with exit code '1' 
> > Pseudo log:
> > path mismatch [2 links]: ino 43965780 db '/home/mcfrisk/src/base/poky/build_genericarm64-st/tmp/work/genericarm64-poky-linux/core-image-minimal/1.0/rootfs/boot/loader/loader.conf' req '/home/mcfrisk/src/base/poky/build_genericarm64-st/tmp/work/genericarm64-poky-linux/core-image-minimal/1.0/tmp-wic/rootfs1/boot/loader/loader.conf'.
> > Setup complete, sending SIGUSR1 to pid 117389.
> >
> > NOTE: Tasks Summary: Attempted 5254 tasks of which 5253 didn't need to be rerun and 1 failed.
> >
> > Summary: 1 task failed:
> >   /home/mcfrisk/src/base/poky/meta/recipes-core/images/core-image-minimal.bb:do_image_wic
> >     log: /home/mcfrisk/src/base/poky/build_genericarm64-st/tmp/work/genericarm64-poky-linux/core-image-minimal/1.0/temp/log.do_image_wic.117565
> > Summary: There was 1 ERROR message, returning a non-zero exit code.
> >
> > 2025-04-07 09:10:05,488 - oe-selftest - INFO - ======================================================================
> > 2025-04-07 09:10:05,488 - oe-selftest - INFO - FAIL: test_permissions (wic.Wic.test_permissions)
> > 2025-04-07 09:10:05,489 - oe-selftest - INFO - ----------------------------------------------------------------------
> > 2025-04-07 09:10:05,489 - oe-selftest - INFO - Traceback (most recent call last):
> >   File "/home/mcfrisk/src/base/poky/meta/lib/oeqa/selftest/cases/wic.py", line 677, in test_permissions
> >     bitbake('core-image-minimal')
> >   File "/home/mcfrisk/src/base/poky/meta/lib/oeqa/utils/commands.py", line 236, in bitbake
> >     return runCmd(cmd, ignore_status, timeout, output_log=output_log, **options)
> >            ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> >   File "/home/mcfrisk/src/base/poky/meta/lib/oeqa/utils/commands.py", line 214, in runCmd
> >     raise AssertionError("Command '%s' returned non-zero exit status %d:\n%s" % (command, result.status, exc_output))
> > AssertionError: Command 'bitbake  core-image-minimal' returned non-zero exit status 1:
> > Loading cache...done.
> > Loaded 1976 entries from dependency cache.
> > NOTE: Resolving any missing task queue dependencies
> >
> > Build Configuration:
> > BB_VERSION           = "2.12.0"
> > BUILD_SYS            = "aarch64-linux"
> > NATIVELSBSTRING      = "universal"
> > TARGET_SYS           = "aarch64-poky-linux"
> > MACHINE              = "genericarm64"
> > DISTRO               = "poky-altcfg"
> > DISTRO_VERSION       = "5.2"
> > TUNE_FEATURES        = "aarch64 armv8a crc"
> > TARGET_FPU           = ""
> > meta                 
> > meta-poky            
> > meta-yocto-bsp       = "HEAD:a75117f79e4771927b89125e464e38acdc9c556e"
> > meta-selftest        = "master:fd26cf3cc0e6e590b56e331971cdf884d1b881b9"
> >
> > Initialising tasks...Sstate summary: Wanted 539 Local 536 Mirrors 0 Missed 3 Current 1968 (99% match, 99% complete)
> > Removing 3 stale sstate objects for arch genericarm64...done.
> > NOTE: Executing Tasks
> > NOTE: Running task 5157 of 5259 (/home/mcfrisk/src/base/poky/meta/recipes-core/images/core-image-minimal.bb:do_image_wic)
> > NOTE: recipe core-image-minimal-1.0-r0: task do_image_wic: Started
> > ERROR: core-image-minimal-1.0-r0 do_image_wic: Execution of '/home/mcfrisk/src/base/poky/build_genericarm64-st/tmp/work/genericarm64-poky-linux/core-image-minimal/1.0/temp/r
> > un.do_image_wic.117565' failed with exit code 134
> > ERROR: Logfile of failure stored in: /home/mcfrisk/src/base/poky/build_genericarm64-st/tmp/work/genericarm64-poky-linux/core-image-minimal/1.0/temp/log.do_image_wic.117565
> > Log data follows:
> > | DEBUG: Executing python function extend_recipe_sysroot
> > | NOTE: Direct dependencies are ['/home/mcfrisk/src/base/poky/meta/recipes-bsp/grub/grub-efi_2.12.bb:do_populate_sysroot', '/home/mcfrisk/src/base/poky/meta/recipes-core/glibc/cross-localedef-native_2.41.bb:do_populate_sysroot', '/home/mcfrisk/src/base/poky/meta/recipes-core/glibc/ldconfig-native_2.12.1.bb:do_populate_sysroot', '/home/mcfrisk/s
> > rc/base/poky/meta/recipes-core/systemd/systemd-boot_257.4.bb:do_populate_sysroot', '/home/mcfrisk/src/base/poky/meta/recipes-devtools/binutils/binutils-cross_2.44.bb:do_populate_sysroot', '/home/mcfrisk/src/base/poky/meta/recipes-devtools/cdrtools/cdrtools-native_3.01.bb:do_populate_sysroot', '/home/mcfrisk/src/base/poky/meta/recipes-devtools/qemu/qemuwrapper-cross_1.0.bb:do_populate_sysroot', '/home/mcfrisk/src/base/poky/meta/recipes-kernel/kmod/depmodwrapper-cross_1.0.bb:do_populate_sysroot', 'virtual:native:/ho
> > me/mcfrisk/src/base/poky/meta/recipes-core/update-rc.d/update-rc.d_0.8.bb:do_populate_sysroot', 'virtual:native:/home/mcfrisk/src/base/poky/meta/recipes-devtools/btrfs-tools/btrfs-tools_6.14.bb:do_populate_sysroot', 'virtual:native:/home/mcfrisk/src/base/poky/meta/recipes-devtools/dosfstools/dosfstools_4.2.bb:do_populate_sysroot', 'virtual:nati
> > ve:/home/mcfrisk/src/base/poky/meta/recipes-devtools/e2fsprogs/e2fsprogs_1.47.1.bb:do_populate_sysroot', 'virtual:native:/home/mcfrisk/src/base/poky/meta/recipes-devtools/erofs-utils/erofs-utils_1.8.5.bb:do_populate_sysroot', 'virtual:native:/home/mcfrisk/src/base/poky/meta/recipes-devtools/fdisk/gptfdisk_1.0.10.bb:do_populate_sysroot', 'virtual:native:/home/mcfrisk/src/base/poky/meta/recipes-devtools/makedevs/makedevs_1.0.1.bb:do_populate_sysroot', 'virtual:native:/home/mcfrisk/src/base/poky/meta/recipes-devtools/mtools/mtools_4.0.48.bb:do_populate_sysroot', 'virtual:native:/home/mcfrisk/src/base/poky/meta/recipes-devtools/opkg-utils/opkg-utils_0.7.0.bb:do_populate_sysroot', 'virtua
> > l:native:/home/mcfrisk/src/base/poky/meta/recipes-devtools/opkg/opkg_0.7.0.bb:do_populate_sysroot', 'virtual:native:/home/mcfrisk/src/base/poky/meta/recipes-devtools/pseudo/
> > pseudo_git.bb:do_populate_sysroot', 'virtual:native:/home/mcfrisk/src/base/poky/meta/recipes-devtools/squashfs-tools/squashfs-tools_git.bb:do_populate_sysroot', 'virtual:native:/home/mcfrisk/src/base/poky/meta/recipes-extended/parted/parted_3.6.bb:do_populate_sysroot', 'virtual:native:/home/mcfrisk/src/base/poky/meta/recipes-extended/pigz/pigz_2.8.bb:do_populate_sysroot', 'virtual:native:/home/mcfrisk/src/base/poky/meta/recipes-support/bmaptool/bmaptool_git.bb:do_populate_sysroot']
> > | NOTE: Installed into sysroot: []
> > | NOTE: Skipping as already exists in sysroot: ['grub-efi', 'gettext-minimal-native', 'cross-localedef-native', 'glibc', 'ldconfig-native', 'libxcrypt', 'ncurses', 'systemd-boot', 'systemd-systemctl-native', 'util-linux-libuuid', 'util-linux', 'zlib', 'binutils-cross-aarch64', 'cdrtools-native', 'cmake-native', 'gcc-runtime', 'libgcc', 'libtool
> > -native', 'm4-native', 'opkg-utils', 'qemu-helper-native', 'qemu-native', 'qemu-system-native', 'qemuwrapper-cross', 'libpam', 'texinfo-dummy-native', 'depmodwrapper-cross', 'linux-libc-headers', 'bash-completion', 'libcap-ng', 'libcap', 'sqlite3', 'openssl-native', 'libslirp-native', 'coreutils-native', 'expat-native', 'gettext-native', 'glib-
> > 2.0-native', 'libxml2-native', 'ncurses-native', 'readline-native', 'update-rc.d-native', 'util-linux-libuuid-native', 'util-linux-native', 'zlib-native', 'btrfs-tools-native', 'chrpath-native', 'dosfstools-native', 'e2fsprogs-native', 'elfutils-native', 'erofs-utils-native', 'gptfdisk-native', 'flex-native', 'gnu-config-native', 'json-c-native', 'libedit-native', 'llvm-native', 'make-native', 'makedevs-native', 'mtools-native', 'opkg-utils-native', 'opkg-native', 'perl-native', 'pseudo-native', 'python3-build-nat
> > ive', 'python3-calver-native', 'python3-editables-native', 'python3-flit-core-native', 'python3-hatchling-native', 'python3-installer-native', 'python3-jinja2-native', 'python3-mako-native', 'python3-markupsafe-native', 'python3-packaging-native', 'python3-pathspec-native', 'python3-pip-native', 'python3-pluggy-native', 'python3-pygments-native
> > ', 'python3-pyparsing-native', 'python3-pyproject-hooks-native', 'python3-setuptools-scm-native', 'python3-setuptools-native', 'python3-six-native', 'python3-trove-classifiers-native', 'python3-typing-extensions-native', 'python3-wheel-native', 'python3-native', 'squashfs-tools-native', 'unfs3-native', 'bzip2-native', 'cpio-native', 'diffutils-native', 'libarchive-native', 'libidn2-native', 'libnsl2-native', 'libsolv-native', 'libtirpc-native', 'parted-native', 'pigz-native', 'shadow-native', 'unzip-native', 'xz-n
> > ative', 'zstd-native', 'libdrm-native', 'libepoxy-native', 'libsdl2-native', 'mesa-native', 'virglrenderer-native', 'wayland-protocols-native', 'wayland-native', 'xrandr-native', 'libpciaccess-native', 'libpthread-stubs-native', 'libx11-native', 'libxau-native', 'libxcb-native', 'libxdamage-native', 'libxdmcp-native', 'libxext-native', 'libxfix
> > es-native', 'libxrandr-native', 'libxrender-native', 'libxshmfence-native', 'libxxf86vm-native', 'pixman-native', 'xtrans-native', 'xcb-proto-native', 'xorgproto-native', 'makedepend-native', 'util-macros-native', 'dtc-native', 'kmod-native', 'alsa-lib-native', 'libpng-native', 'acl-native', 'attr-native', 'bmaptool-native', 'curl-native', 'debianutils-native', 'gdbm-native', 'gmp-native', 'gnutls-native', 'libtasn1-native', 'libbsd-native', 'libcap-ng-native', 'libcap-native', 'libffi-native', 'libgcrypt-native',
> >  'libgpg-error-native', 'libmd-native', 'libmicrohttpd-native', 'libpcre2-native', 'libunistring-native', 'lz4-native', 'lzo-native', 'nettle-native', 'popt-native', 'shared-mime-info-native', 'sqlite3-native']
> > | DEBUG: Python function extend_recipe_sysroot finished
> > | DEBUG: Executing python function set_image_size
> > | DEBUG: 159546.400000 = 122728 * 1.300000
> > | DEBUG: 163642.400000 = max(159546.400000, 8192)[159546.400000] + 4096
> > | DEBUG: 163643.000000 = int(163642.400000)
> > | DEBUG: 163643 = aligned(163643)
> > | DEBUG: returning 163643
> > | DEBUG: Python function set_image_size finished
> > | DEBUG: Executing shell function do_image_wic
> > | abort()ing pseudo client by server request. See https://wiki.yoctoproject.org/wiki/Pseudo_Abort for more details on this.
> > | Check logfile: /home/mcfrisk/src/base/poky/build_genericarm64-st/tmp/work/genericarm64-poky-linux/core-image-minimal/1.0/pseudo//pseudo.log
> > | WARNING: exit code 134 from a shell command.
> > | Aborted
> > NOTE: recipe core-image-minimal-1.0-r0: task do_image_wic: Failed
> > ERROR: Task (/home/mcfrisk/src/base/poky/meta/recipes-core/images/core-image-minimal.bb:do_image_wic) failed with exit code '1' 
> > Pseudo log:
> > path mismatch [2 links]: ino 43965780 db '/home/mcfrisk/src/base/poky/build_genericarm64-st/tmp/work/genericarm64-poky-linux/core-image-minimal/1.0/rootfs/boot/loader/loader.conf' req '/home/mcfrisk/src/base/poky/build_genericarm64-st/tmp/work/genericarm64-poky-linux/core-image-minimal/1.0/tmp-wic/rootfs1/boot/loader/loader.conf'.
> > Setup complete, sending SIGUSR1 to pid 117389.
> >
> > NOTE: Tasks Summary: Attempted 5254 tasks of which 5253 didn't need to be rerun and 1 failed.
> >
> > Summary: 1 task failed:
> >   /home/mcfrisk/src/base/poky/meta/recipes-core/images/core-image-minimal.bb:do_image_wic
> >     log: /home/mcfrisk/src/base/poky/build_genericarm64-st/tmp/work/genericarm64-poky-linux/core-image-minimal/1.0/temp/log.do_image_wic.117565
> > Summary: There was 1 ERROR message, returning a non-zero exit code.
> > ----------------------------------------------------------------------
> > 2025-04-07 09:10:05,489 - oe-selftest - INFO - Ran 1 test in 2271.863s
> > 2025-04-07 09:10:05,489 - oe-selftest - INFO - FAILED
> > 2025-04-07 09:10:05,489 - oe-selftest - INFO -  (failures=1)
> > 2025-04-07 09:10:11,706 - oe-selftest - INFO - RESULTS:
> > 2025-04-07 09:10:11,706 - oe-selftest - INFO - RESULTS - wic.Wic.test_permissions: FAILED (2271.66s)
> > 2025-04-07 09:10:11,708 - oe-selftest - INFO - SUMMARY:
> > 2025-04-07 09:10:11,708 - oe-selftest - INFO - oe-selftest () - Ran 1 test in 2271.863s
> > 2025-04-07 09:10:11,708 - oe-selftest - INFO - oe-selftest - FAIL - Required tests failed (successes=0, skipped=0, failures=1, errors=0)
> >
> > I think something in this test is faulty. For example building an image
> > in yocto do_image with fakeroot/pseudo and then modifying it outside of build
> > env with wic is likely going to fail like this.
> >
> > I will try with other machine targets and cleaner local.conf
> > but I suspect I will run into this same issue again.
> >
> > And the error from your CI buidl was completely different... :/
> >
> > Cheers,
> >
> > -Mikko
> 
> I confirm, localally I see the same thing as you do: just some pseudo
> errors. They seem to come from "image_types_wic.bbclass: capture verbose
> wic output by default" patch.
> 
> So yes, different than on the autobuilder, but yet if I drop the series,
> autobuilder builds do succeed :(
> 
> So we can hope there is an obscure link between both failures, but
> that's all I've got so far.

With:

--- a/meta/lib/oeqa/selftest/cases/wic.py
+++ b/meta/lib/oeqa/selftest/cases/wic.py
@@ -674,6 +674,7 @@ part /etc --source rootfs --fstype=ext4 --change-directory=etc
 
                 config = 'IMAGE_FSTYPES += "wic"\nWKS_FILE = "%s"\n' % wks_file
                 self.append_config(config)
+                bitbake('-c clean core-image-minimal')
                 bitbake('core-image-minimal')
                 tmpdir = os.path.join(get_bb_var('WORKDIR', 'core-image-minimal'),'build-wic')
 

the test is passing for me now without pseudo errors.

The debug logging patch is IMO unrelated. It's just capturing logs from wic by default.
It could trigger rebuilds vs sstate cache if testing is done without and then with
the patch applied. Is full world build done with this patch applied before
selftests are run? I think this may impact the test as well.

Cheers,

-Mikko

Re: [OE-core] [PATCH v3 00/11] systemd based initrd and modular kernel support

[Mikko Rapeli]

Hi,

On Mon, Apr 07, 2025 at 01:26:06PM +0300, Mikko Rapeli via lists.openembedded.org wrote:
> On Mon, Apr 07, 2025 at 11:52:01AM +0200, Mathieu Dubois-Briand wrote:
> > On Mon Apr 7, 2025 at 11:24 AM CEST, Mikko Rapeli wrote:
> > > On Mon, Apr 07, 2025 at 10:51:43AM +0200, Mathieu Dubois-Briand wrote:
> > >> On Mon Apr 7, 2025 at 10:10 AM CEST, Mikko Rapeli wrote:
> > >> > On Mon, Apr 07, 2025 at 09:53:45AM +0200, Mathieu Dubois-Briand wrote:
> > >> >> On Fri Apr 4, 2025 at 6:29 PM CEST, Mikko Rapeli via lists.openembedded.org wrote:
> > >> >> > systemd based initrd supports more security, encryption etc features
> > >> >> > than custom shell script ones but oe-core lacks support for it.
> > >> >> > Convert core-image-initramfs-boot to create systemd based initrd
> > >> >> > if "systemd-initramfs" is set in DISTRO_FEATURES. Includes a test
> > >> >> > for this initrd to mount rootfs via Unified Kernel Image uki.py.
> > >> >> >
> > >> >> > Sadly the boot time is really slow, e.g. over 30 seconds with
> > >> >> > systemd based initrd. One of the major reasons is the large
> > >> >> > amount of kernel modules built into the linux-yocto kernel and
> > >> >> > processing of their udev events in userspace. Thus add
> > >> >> > kernel-initrd-modules meta package to easily install
> > >> >> > subset of all kernel modules to initrd. The subset
> > >> >> > supports "mount rootfs from any block device" but
> > >> >> > doesn't include graphics, UBS etc support. Without this
> > >> >> > generated meta package, initrd recipe needs to manually define
> > >> >> > which exact kernel modules to include which breaks if
> > >> >> > those modules are built into the kernel. Thus the initrd
> > >> >> > becomes machine and kernel config specific and hard to maintain.
> > >> >> > With this meta package a generic initrd can be created.
> > >> >> >
> > >> >> > Separate changes to linux-yocto compile a lot more drivers
> > >> >> > as modules but they depend on these initrd changes.
> > >> >> >
> > >> >> 
> > >> >> Hi Mikko,
> > >> >> 
> > >> >> Thanks for your patch.
> > >> >> 
> > >> >> I believe one of these wic related patches is responsible of some
> > >> >> oe-selftest failures we can see on the autobuilder:
> > >> >> 
> > >> >> 2025-04-06 15:51:49,317 - oe-selftest - INFO - wic.Wic.test_permissions (subunit.RemotedTestCase)
> > >> >> 2025-04-06 15:51:49,318 - oe-selftest - INFO -  ... FAIL
> > >> >> 
> > >> >> ...
> > >> >> 
> > >> >> ERROR: When reparsing /tmp/selftest-fetchsrayuxoq/test.bb:do_checkuri, the basehash value changed from 84b9e23a83a764e7a5d8a96ee523199e2b1c604f4280a45030e248de0ff52962 to 4123da244f465feffecb2b4fd2b132b64851981ec2fb70bf9445df8b0ea6a69e. The metadata is not deterministic and this needs to be fixed.
> > >> >> ERROR: The following commands may help:
> > >> >> ERROR: $ bitbake test -cdo_checkuri -Snone
> > >> >> ERROR: Then:
> > >> >> ERROR: $ bitbake test -cdo_checkuri -Sprintdiff
> > >> >> 
> > >> >> ERROR: When reparsing /tmp/selftest-fetchsrayuxoq/test.bb:do_fetch, the basehash value changed from 6d55d6743729b615749dc016857d7e5f9c884a8b92f0d57f68e743f4910333d3 to fa7d6ea0563b60362418d2a6c5e41a6684183d01ec578b65abd0c64a9cfba7cf. The metadata is not deterministic and this needs to be fixed.
> > >> >> ERROR: The following commands may help:
> > >> >> ERROR: $ bitbake test -cdo_fetch -Snone
> > >> >> ERROR: Then:
> > >> >> ERROR: $ bitbake test -cdo_fetch -Sprintdiff
> > >> >> 
> > >> >> ERROR: When reparsing /tmp/selftest-fetchsrayuxoq/test.bb:do_unpack, the basehash value changed from ae9d94aafc721d891f8754df82ed90da8191357178f3db64221a49d5c1de3bcd to 1ac8f87a71db151b8eb2ae8d13f9a6ea1a0c884ef98555d61d2c2fe07a476a8a. The metadata is not deterministic and this needs to be fixed.
> > >> >> ERROR: The following commands may help:
> > >> >> ERROR: $ bitbake test -cdo_unpack -Snone
> > >> >> ERROR: Then:
> > >> >> ERROR: $ bitbake test -cdo_unpack -Sprintdiff
> > >> >> 
> > >> >> ...
> > >> >> 
> > >> >> https://autobuilder.yoctoproject.org/valkyrie/#/builders/23/builds/1391
> > >> >> 
> > >> >> Can you have a look at this please?
> > >> >
> > >> > I can have a look but how can these patches change the basehash'es when testing?
> > >> >
> > >> > I've seen some of the wic selftets failing on x86_64 build machine with zfs
> > >> > but changes to fix this was rejected multiple times.
> > >> >
> > >> > Then I've seen some of these failing with odd pseudo failures on aarch64
> > >> > build machine.
> > >> >
> > >> > With my patches the end result was the same.
> > >> >
> > >> > I ran wic and uki selftests on x86_64 and aarch64 build machines for targets qemuarm64,
> > >> > qemuarm and genericx86-64.
> > >> >
> > >> > The wic patches have actually nothing to do with this series except I ran into bugs
> > >> > in wic which resulted in unbootable images, e.g. the UEFI bootloader binaries
> > >> > missing from ESP partition. These were impacting some builds but not all
> > >> > which was really troubling.
> > >> >
> > >> > Cheers,
> > >> >
> > >> > -Mikko
> > >> 
> > >> Ok, I am running some git bisect locally anyway, I will keep you updated
> > >> a bit later today.
> > >
> > > I ran wic.Wic.test_permissions and it passed without this series
> > > on aarch64 build machine and genericarm64 target machine:
> > >
> > > NOTE: Reconnecting to bitbake server...
> > > NOTE: Retrying server connection (#1)... (08:13:45.320086)
> > > NOTE: Reconnecting to bitbake server...
> > > NOTE: Reconnecting to bitbake server...
> > > NOTE: Retrying server connection (#1)... (08:13:45.320086)
> > > NOTE: Retrying server connection (#1)... (08:13:45.320086)
> > > NOTE: Starting bitbake server...
> > > hint: Using 'master' as the name for the initial branch. This default branch name
> > > hint: is subject to change. To configure the initial branch name to use in all
> > > hint: of your new repositories, which will suppress this warning, call:
> > > hint: 
> > > hint:   git config --global init.defaultBranch <name>
> > > hint: 
> > > hint: Names commonly chosen instead of 'master' are 'main', 'trunk' and
> > > hint: 'development'. The just-created branch can be renamed via this command:
> > > hint: 
> > > hint:   git branch -m <name>
> > > 2025-04-07 08:13:46,418 - oe-selftest - INFO - Adding: "include selftest.inc" in /home/mcfrisk/src/base/poky/build_genericarm64-st/conf/local.conf
> > > 2025-04-07 08:13:46,418 - oe-selftest - INFO - Adding: "include bblayers.inc" in bblayers.conf
> > > 2025-04-07 08:13:46,418 - oe-selftest - INFO - test_permissions (wic.Wic.test_permissions)
> > > 2025-04-07 08:24:47,941 - oe-selftest - INFO -  ... ok
> > > 2025-04-07 08:24:54,376 - oe-selftest - INFO - ----------------------------------------------------------------------
> > > 2025-04-07 08:24:54,376 - oe-selftest - INFO - Ran 1 test in 668.167s
> > > 2025-04-07 08:24:54,376 - oe-selftest - INFO - OK
> > > 2025-04-07 08:25:00,978 - oe-selftest - INFO - RESULTS:
> > > 2025-04-07 08:25:00,978 - oe-selftest - INFO - RESULTS - wic.Wic.test_permissions: PASSED (661.52s)
> > > 2025-04-07 08:25:00,979 - oe-selftest - INFO - SUMMARY:
> > > 2025-04-07 08:25:00,979 - oe-selftest - INFO - oe-selftest () - Ran 1 test in 668.168s
> > > 2025-04-07 08:25:00,979 - oe-selftest - INFO - oe-selftest - OK - All required tests passed (successes=1, skipped=0, failures=0, errors=0)
> > >
> > > Then with patches from this series (and a few more which I sent out separately,
> > > should be unrelated) it failed with pseudo errors:
> > >
> > > 2025-04-07 08:32:12,107 - oe-selftest - INFO - Changing cwd to /home/mcfrisk/src/base/poky/build_genericarm64
> > > 2025-04-07 08:32:12,107 - oe-selftest - INFO - Adding layer libraries:
> > > 2025-04-07 08:32:12,107 - oe-selftest - INFO -  /home/mcfrisk/src/base/poky/meta/lib
> > > 2025-04-07 08:32:12,107 - oe-selftest - INFO -  /home/mcfrisk/src/base/poky/meta-yocto-bsp/lib
> > > 2025-04-07 08:32:12,107 - oe-selftest - INFO -  /home/mcfrisk/src/base/poky/meta-selftest/lib
> > > 2025-04-07 08:32:12,108 - oe-selftest - INFO - Checking base configuration is valid/parsable
> > > NOTE: Reconnecting to bitbake server...
> > > NOTE: Retrying server connection (#1)... (08:32:12.728357)
> > > NOTE: Reconnecting to bitbake server...
> > > NOTE: Reconnecting to bitbake server...
> > > NOTE: Retrying server connection (#1)... (08:32:12.728357)
> > > NOTE: Retrying server connection (#1)... (08:32:12.728357)
> > > NOTE: Starting bitbake server...
> > > hint: Using 'master' as the name for the initial branch. This default branch name
> > > hint: is subject to change. To configure the initial branch name to use in all
> > > hint: of your new repositories, which will suppress this warning, call:
> > > hint: 
> > > hint:   git config --global init.defaultBranch <name>
> > > hint: 
> > > hint: Names commonly chosen instead of 'master' are 'main', 'trunk' and
> > > hint: 'development'. The just-created branch can be renamed via this command:
> > > hint: 
> > > hint:   git branch -m <name>
> > > 2025-04-07 08:32:13,824 - oe-selftest - INFO - Adding: "include selftest.inc" in /home/mcfrisk/src/base/poky/build_genericarm64-st/conf/local.conf
> > > 2025-04-07 08:32:13,824 - oe-selftest - INFO - Adding: "include bblayers.inc" in bblayers.conf
> > > 2025-04-07 08:32:13,824 - oe-selftest - INFO - test_permissions (wic.Wic.test_permissions)
> > > 2025-04-07 09:10:05,405 - oe-selftest - INFO -  ... FAIL
> > > 2025-04-07 09:10:05,488 - oe-selftest - INFO - Traceback (most recent call last):
> > >   File "/home/mcfrisk/src/base/poky/meta/lib/oeqa/selftest/cases/wic.py", line 677, in test_permissions
> > >     bitbake('core-image-minimal')
> > >   File "/home/mcfrisk/src/base/poky/meta/lib/oeqa/utils/commands.py", line 236, in bitbake
> > >     return runCmd(cmd, ignore_status, timeout, output_log=output_log, **options)
> > >            ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> > >   File "/home/mcfrisk/src/base/poky/meta/lib/oeqa/utils/commands.py", line 214, in runCmd
> > >     raise AssertionError("Command '%s' returned non-zero exit status %d:\n%s" % (command, result.status, exc_output))
> > > AssertionError: Command 'bitbake  core-image-minimal' returned non-zero exit status 1:
> > > Loading cache...done.
> > > Loaded 1976 entries from dependency cache.
> > > NOTE: Resolving any missing task queue dependencies
> > >
> > > Build Configuration:
> > > BB_VERSION           = "2.12.0"
> > > BUILD_SYS            = "aarch64-linux"
> > > NATIVELSBSTRING      = "universal"
> > > TARGET_SYS           = "aarch64-poky-linux"
> > > MACHINE              = "genericarm64"
> > > DISTRO               = "poky-altcfg"
> > > DISTRO_VERSION       = "5.2"
> > > TUNE_FEATURES        = "aarch64 armv8a crc"
> > > TARGET_FPU           = ""
> > > meta                 
> > > meta-poky            
> > > meta-yocto-bsp       = "HEAD:a75117f79e4771927b89125e464e38acdc9c556e"
> > > meta-selftest        = "master:fd26cf3cc0e6e590b56e331971cdf884d1b881b9"
> > >
> > > Initialising tasks...Sstate summary: Wanted 539 Local 536 Mirrors 0 Missed 3 Current 1968 (99% match, 99% complete)
> > > Removing 3 stale sstate objects for arch genericarm64...done.
> > > NOTE: Executing Tasks
> > > NOTE: Running task 5157 of 5259 (/home/mcfrisk/src/base/poky/meta/recipes-core/images/core-image-minimal.bb:do_image_wic)
> > > NOTE: recipe core-image-minimal-1.0-r0: task do_image_wic: Started
> > > ERROR: core-image-minimal-1.0-r0 do_image_wic: Execution of '/home/mcfrisk/src/base/poky/build_genericarm64-st/tmp/work/genericarm64-poky-linux/core-image-minimal/1.0/temp/run.do_image_wic.117565' failed with exit code 134
> > > ERROR: Logfile of failure stored in: /home/mcfrisk/src/base/poky/build_genericarm64-st/tmp/work/genericarm64-poky-linux/core-image-minimal/1.0/temp/log.do_image_wic.117565
> > > Log data follows:
> > > | DEBUG: Executing python function extend_recipe_sysroot
> > > | NOTE: Direct dependencies are ['/home/mcfrisk/src/base/poky/meta/recipes-bsp/grub/grub-efi_2.12.bb:do_populate_sysroot', '/home/mcfrisk/src/base/poky/meta/recipes-core/gli
> > > bc/cross-localedef-native_2.41.bb:do_populate_sysroot', '/home/mcfrisk/src/base/poky/meta/recipes-core/glibc/ldconfig-native_2.12.1.bb:do_populate_sysroot', '/home/mcfrisk/src/base/poky/meta/recipes-core/systemd/systemd-boot_257.4.bb:do_populate_sysroot', '/home/mcfrisk/src/base/poky/meta/recipes-devtools/binutils/binutils-cross_2.44.bb:do_popu
> > > late_sysroot', '/home/mcfrisk/src/base/poky/meta/recipes-devtools/cdrtools/cdrtools-native_3.01.bb:do_populate_sysroot', '/home/mcfrisk/src/base/poky/meta/recipes-devtools/qemu/qemuwrapper-cross_1.0.bb:do_populate_sysroot', '/home/mcfrisk/src/base/poky/meta/recipes-kernel/kmod/depmodwrapper-cross_1.0.bb:do_populate_sysroot', 'virtual:native:/home/mcfrisk/src/base/poky/meta/recipes-core/update-rc.d/update-rc.d_0.8.bb:do_populate_sysroot', 'virtual:native:/home/mcfrisk/src/base/poky/meta/recipes-devtools/btrfs-tools
> > > /btrfs-tools_6.14.bb:do_populate_sysroot', 'virtual:native:/home/mcfrisk/src/base/poky/meta/recipes-devtools/dosfstools/dosfstools_4.2.bb:do_populate_sysroot', 'virtual:native:/home/mcfrisk/src/base/poky/meta/recipes-devtools/e2fsprogs/e2fsprogs_1.47.1.bb:do_populate_sysroot', 'virtual:native:/home/mcfrisk/src/base/poky/meta/recipes-devtools/er
> > > ofs-utils/erofs-utils_1.8.5.bb:do_populate_sysroot', 'virtual:native:/home/mcfrisk/src/base/poky/meta/recipes-devtools/fdisk/gptfdisk_1.0.10.bb:do_populate_sysroot', 'virtual:native:/home/mcfrisk/src/base/poky/meta/recipes-devtools/makedevs/makedevs_1.0.1.bb:do_populate_sysroot', 'virtual:native:/home/mcfrisk/src/base/poky/meta/recipes-devtools/mtools/mtools_4.0.48.bb:do_populate_sysroot', 'virtual:native:/home/mcfrisk/src/base/poky/meta/recipes-devtools/opkg-utils/opkg-utils_0.7.0.bb:do_populate_sysroot', 'virtua
> > > l:native:/home/mcfrisk/src/base/poky/meta/recipes-devtools/opkg/opkg_0.7.0.bb:do_populate_sysroot', 'virtual:native:/home/mcfrisk/src/base/poky/meta/recipes-devtools/pseudo/pseudo_git.bb:do_populate_sysroot', 'virtual:native:/home/mcfrisk/src/base/poky/meta/recipes-devtools/squashfs-tools/squashfs-tools_git.bb:do_populate_sysroot', 'virtual:nat
> > > ive:/home/mcfrisk/src/base/poky/meta/recipes-extended/parted/parted_3.6.bb:do_populate_sysroot', 'virtual:native:/home/mcfrisk/src/base/poky/meta/recipes-extended/pigz/pigz_
> > > 2.8.bb:do_populate_sysroot', 'virtual:native:/home/mcfrisk/src/base/poky/meta/recipes-support/bmaptool/bmaptool_git.bb:do_populate_sysroot']
> > > | NOTE: Installed into sysroot: []
> > > | NOTE: Skipping as already exists in sysroot: ['grub-efi', 'gettext-minimal-native', 'cross-localedef-native', 'glibc', 'ldconfig-native', 'libxcrypt', 'ncurses', 'systemd-
> > > boot', 'systemd-systemctl-native', 'util-linux-libuuid', 'util-linux', 'zlib', 'binutils-cross-aarch64', 'cdrtools-native', 'cmake-native', 'gcc-runtime', 'libgcc', 'libtool-native', 'm4-native', 'opkg-utils', 'qemu-helper-native', 'qemu-native', 'qemu-system-native', 'qemuwrapper-cross', 'libpam', 'texinfo-dummy-native', 'depmodwrapper-cross', 'linux-libc-headers', 'bash-completion', 'libcap-ng', 'libcap', 'sqlite3', 'openssl-native', 'libslirp-native', 'coreutils-native', 'expat-native', 'gettext-native', 'glib-
> > > 2.0-native', 'libxml2-native', 'ncurses-native', 'readline-native', 'update-rc.d-native', 'util-linux-libuuid-native', 'util-linux-native', 'zlib-native', 'btrfs-tools-nativ
> > > e', 'chrpath-native', 'dosfstools-native', 'e2fsprogs-native', 'elfutils-native', 'erofs-utils-native', 'gptfdisk-native', 'flex-native', 'gnu-config-native', 'json-c-native
> > > ', 'libedit-native', 'llvm-native', 'make-native', 'makedevs-native', 'mtools-native', 'opkg-utils-native', 'opkg-native', 'perl-native', 'pseudo-native', 'python3-build-native', 'python3-calver-native', 'python3-editables-native', 'python3-flit-core-native', 'python3-hatchling-native', 'python3-installer-native', 'python3-jinja2-native', 'pyth
> > > on3-mako-native', 'python3-markupsafe-native', 'python3-packaging-native', 'python3-pathspec-native', 'python3-pip-native', 'python3-pluggy-native', 'python3-pygments-native
> > > ', 'python3-pyparsing-native', 'python3-pyproject-hooks-native', 'python3-setuptools-scm-native', 'python3-setuptools-native', 'python3-six-native', 'python3-trove-classifiers-native', 'python3-typing-extensions-native', 'python3-wheel-native', 'python3-native', 'squashfs-tools-native', 'unfs3-native', 'bzip2-native', 'cpio-native', 'diffutils-
> > > native', 'libarchive-native', 'libidn2-native', 'libnsl2-native', 'libsolv-native', 'libtirpc-native', 'parted-native', 'pigz-native', 'shadow-native', 'unzip-native', 'xz-native', 'zstd-native', 'libdrm-native', 'libepoxy-native', 'libsdl2-native', 'mesa-native', 'virglrenderer-native', 'wayland-protocols-native', 'wayland-native', 'xrandr-nat
> > > ive', 'libpciaccess-native', 'libpthread-stubs-native', 'libx11-native', 'libxau-native', 'libxcb-native', 'libxdamage-native', 'libxdmcp-native', 'libxext-native', 'libxfixes-native', 'libxrandr-native', 'libxrender-native', 'libxshmfence-native', 'libxxf86vm-native', 'pixman-native', 'xtrans-native', 'xcb-proto-native', 'xorgproto-native', 'makedepend-native', 'util-macros-native', 'dtc-native', 'kmod-native', 'alsa-lib-native', 'libpng-native', 'acl-native', 'attr-native', 'bmaptool-native', 'curl-native', 'deb
> > > ianutils-native', 'gdbm-native', 'gmp-native', 'gnutls-native', 'libtasn1-native', 'libbsd-native', 'libcap-ng-native', 'libcap-native', 'libffi-native', 'libgcrypt-native', 'libgpg-error-native', 'libmd-native', 'libmicrohttpd-native', 'libpcre2-native', 'libunistring-native', 'lz4-native', 'lzo-native', 'nettle-native', 'popt-native', 'shared
> > > -mime-info-native', 'sqlite3-native']
> > > | DEBUG: Python function extend_recipe_sysroot finished
> > > | DEBUG: Executing python function set_image_size
> > > | DEBUG: 159546.400000 = 122728 * 1.300000
> > > | DEBUG: 163642.400000 = max(159546.400000, 8192)[159546.400000] + 4096
> > > | DEBUG: 163643.000000 = int(163642.400000)
> > > | DEBUG: 163643 = aligned(163643)
> > > | DEBUG: returning 163643
> > > | DEBUG: Python function set_image_size finished
> > > | DEBUG: Executing shell function do_image_wic
> > > | abort()ing pseudo client by server request. See https://wiki.yoctoproject.org/wiki/Pseudo_Abort for more details on this.
> > > | Check logfile: /home/mcfrisk/src/base/poky/build_genericarm64-st/tmp/work/genericarm64-poky-linux/core-image-minimal/1.0/pseudo//pseudo.log
> > > | WARNING: exit code 134 from a shell command.
> > > | Aborted
> > > NOTE: recipe core-image-minimal-1.0-r0: task do_image_wic: Failed
> > > ERROR: Task (/home/mcfrisk/src/base/poky/meta/recipes-core/images/core-image-minimal.bb:do_image_wic) failed with exit code '1' 
> > > Pseudo log:
> > > path mismatch [2 links]: ino 43965780 db '/home/mcfrisk/src/base/poky/build_genericarm64-st/tmp/work/genericarm64-poky-linux/core-image-minimal/1.0/rootfs/boot/loader/loader.conf' req '/home/mcfrisk/src/base/poky/build_genericarm64-st/tmp/work/genericarm64-poky-linux/core-image-minimal/1.0/tmp-wic/rootfs1/boot/loader/loader.conf'.
> > > Setup complete, sending SIGUSR1 to pid 117389.
> > >
> > > NOTE: Tasks Summary: Attempted 5254 tasks of which 5253 didn't need to be rerun and 1 failed.
> > >
> > > Summary: 1 task failed:
> > >   /home/mcfrisk/src/base/poky/meta/recipes-core/images/core-image-minimal.bb:do_image_wic
> > >     log: /home/mcfrisk/src/base/poky/build_genericarm64-st/tmp/work/genericarm64-poky-linux/core-image-minimal/1.0/temp/log.do_image_wic.117565
> > > Summary: There was 1 ERROR message, returning a non-zero exit code.
> > >
> > > 2025-04-07 09:10:05,488 - oe-selftest - INFO - ======================================================================
> > > 2025-04-07 09:10:05,488 - oe-selftest - INFO - FAIL: test_permissions (wic.Wic.test_permissions)
> > > 2025-04-07 09:10:05,489 - oe-selftest - INFO - ----------------------------------------------------------------------
> > > 2025-04-07 09:10:05,489 - oe-selftest - INFO - Traceback (most recent call last):
> > >   File "/home/mcfrisk/src/base/poky/meta/lib/oeqa/selftest/cases/wic.py", line 677, in test_permissions
> > >     bitbake('core-image-minimal')
> > >   File "/home/mcfrisk/src/base/poky/meta/lib/oeqa/utils/commands.py", line 236, in bitbake
> > >     return runCmd(cmd, ignore_status, timeout, output_log=output_log, **options)
> > >            ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> > >   File "/home/mcfrisk/src/base/poky/meta/lib/oeqa/utils/commands.py", line 214, in runCmd
> > >     raise AssertionError("Command '%s' returned non-zero exit status %d:\n%s" % (command, result.status, exc_output))
> > > AssertionError: Command 'bitbake  core-image-minimal' returned non-zero exit status 1:
> > > Loading cache...done.
> > > Loaded 1976 entries from dependency cache.
> > > NOTE: Resolving any missing task queue dependencies
> > >
> > > Build Configuration:
> > > BB_VERSION           = "2.12.0"
> > > BUILD_SYS            = "aarch64-linux"
> > > NATIVELSBSTRING      = "universal"
> > > TARGET_SYS           = "aarch64-poky-linux"
> > > MACHINE              = "genericarm64"
> > > DISTRO               = "poky-altcfg"
> > > DISTRO_VERSION       = "5.2"
> > > TUNE_FEATURES        = "aarch64 armv8a crc"
> > > TARGET_FPU           = ""
> > > meta                 
> > > meta-poky            
> > > meta-yocto-bsp       = "HEAD:a75117f79e4771927b89125e464e38acdc9c556e"
> > > meta-selftest        = "master:fd26cf3cc0e6e590b56e331971cdf884d1b881b9"
> > >
> > > Initialising tasks...Sstate summary: Wanted 539 Local 536 Mirrors 0 Missed 3 Current 1968 (99% match, 99% complete)
> > > Removing 3 stale sstate objects for arch genericarm64...done.
> > > NOTE: Executing Tasks
> > > NOTE: Running task 5157 of 5259 (/home/mcfrisk/src/base/poky/meta/recipes-core/images/core-image-minimal.bb:do_image_wic)
> > > NOTE: recipe core-image-minimal-1.0-r0: task do_image_wic: Started
> > > ERROR: core-image-minimal-1.0-r0 do_image_wic: Execution of '/home/mcfrisk/src/base/poky/build_genericarm64-st/tmp/work/genericarm64-poky-linux/core-image-minimal/1.0/temp/r
> > > un.do_image_wic.117565' failed with exit code 134
> > > ERROR: Logfile of failure stored in: /home/mcfrisk/src/base/poky/build_genericarm64-st/tmp/work/genericarm64-poky-linux/core-image-minimal/1.0/temp/log.do_image_wic.117565
> > > Log data follows:
> > > | DEBUG: Executing python function extend_recipe_sysroot
> > > | NOTE: Direct dependencies are ['/home/mcfrisk/src/base/poky/meta/recipes-bsp/grub/grub-efi_2.12.bb:do_populate_sysroot', '/home/mcfrisk/src/base/poky/meta/recipes-core/glibc/cross-localedef-native_2.41.bb:do_populate_sysroot', '/home/mcfrisk/src/base/poky/meta/recipes-core/glibc/ldconfig-native_2.12.1.bb:do_populate_sysroot', '/home/mcfrisk/s
> > > rc/base/poky/meta/recipes-core/systemd/systemd-boot_257.4.bb:do_populate_sysroot', '/home/mcfrisk/src/base/poky/meta/recipes-devtools/binutils/binutils-cross_2.44.bb:do_populate_sysroot', '/home/mcfrisk/src/base/poky/meta/recipes-devtools/cdrtools/cdrtools-native_3.01.bb:do_populate_sysroot', '/home/mcfrisk/src/base/poky/meta/recipes-devtools/qemu/qemuwrapper-cross_1.0.bb:do_populate_sysroot', '/home/mcfrisk/src/base/poky/meta/recipes-kernel/kmod/depmodwrapper-cross_1.0.bb:do_populate_sysroot', 'virtual:native:/ho
> > > me/mcfrisk/src/base/poky/meta/recipes-core/update-rc.d/update-rc.d_0.8.bb:do_populate_sysroot', 'virtual:native:/home/mcfrisk/src/base/poky/meta/recipes-devtools/btrfs-tools/btrfs-tools_6.14.bb:do_populate_sysroot', 'virtual:native:/home/mcfrisk/src/base/poky/meta/recipes-devtools/dosfstools/dosfstools_4.2.bb:do_populate_sysroot', 'virtual:nati
> > > ve:/home/mcfrisk/src/base/poky/meta/recipes-devtools/e2fsprogs/e2fsprogs_1.47.1.bb:do_populate_sysroot', 'virtual:native:/home/mcfrisk/src/base/poky/meta/recipes-devtools/erofs-utils/erofs-utils_1.8.5.bb:do_populate_sysroot', 'virtual:native:/home/mcfrisk/src/base/poky/meta/recipes-devtools/fdisk/gptfdisk_1.0.10.bb:do_populate_sysroot', 'virtual:native:/home/mcfrisk/src/base/poky/meta/recipes-devtools/makedevs/makedevs_1.0.1.bb:do_populate_sysroot', 'virtual:native:/home/mcfrisk/src/base/poky/meta/recipes-devtools/mtools/mtools_4.0.48.bb:do_populate_sysroot', 'virtual:native:/home/mcfrisk/src/base/poky/meta/recipes-devtools/opkg-utils/opkg-utils_0.7.0.bb:do_populate_sysroot', 'virtua
> > > l:native:/home/mcfrisk/src/base/poky/meta/recipes-devtools/opkg/opkg_0.7.0.bb:do_populate_sysroot', 'virtual:native:/home/mcfrisk/src/base/poky/meta/recipes-devtools/pseudo/
> > > pseudo_git.bb:do_populate_sysroot', 'virtual:native:/home/mcfrisk/src/base/poky/meta/recipes-devtools/squashfs-tools/squashfs-tools_git.bb:do_populate_sysroot', 'virtual:native:/home/mcfrisk/src/base/poky/meta/recipes-extended/parted/parted_3.6.bb:do_populate_sysroot', 'virtual:native:/home/mcfrisk/src/base/poky/meta/recipes-extended/pigz/pigz_2.8.bb:do_populate_sysroot', 'virtual:native:/home/mcfrisk/src/base/poky/meta/recipes-support/bmaptool/bmaptool_git.bb:do_populate_sysroot']
> > > | NOTE: Installed into sysroot: []
> > > | NOTE: Skipping as already exists in sysroot: ['grub-efi', 'gettext-minimal-native', 'cross-localedef-native', 'glibc', 'ldconfig-native', 'libxcrypt', 'ncurses', 'systemd-boot', 'systemd-systemctl-native', 'util-linux-libuuid', 'util-linux', 'zlib', 'binutils-cross-aarch64', 'cdrtools-native', 'cmake-native', 'gcc-runtime', 'libgcc', 'libtool
> > > -native', 'm4-native', 'opkg-utils', 'qemu-helper-native', 'qemu-native', 'qemu-system-native', 'qemuwrapper-cross', 'libpam', 'texinfo-dummy-native', 'depmodwrapper-cross', 'linux-libc-headers', 'bash-completion', 'libcap-ng', 'libcap', 'sqlite3', 'openssl-native', 'libslirp-native', 'coreutils-native', 'expat-native', 'gettext-native', 'glib-
> > > 2.0-native', 'libxml2-native', 'ncurses-native', 'readline-native', 'update-rc.d-native', 'util-linux-libuuid-native', 'util-linux-native', 'zlib-native', 'btrfs-tools-native', 'chrpath-native', 'dosfstools-native', 'e2fsprogs-native', 'elfutils-native', 'erofs-utils-native', 'gptfdisk-native', 'flex-native', 'gnu-config-native', 'json-c-native', 'libedit-native', 'llvm-native', 'make-native', 'makedevs-native', 'mtools-native', 'opkg-utils-native', 'opkg-native', 'perl-native', 'pseudo-native', 'python3-build-nat
> > > ive', 'python3-calver-native', 'python3-editables-native', 'python3-flit-core-native', 'python3-hatchling-native', 'python3-installer-native', 'python3-jinja2-native', 'python3-mako-native', 'python3-markupsafe-native', 'python3-packaging-native', 'python3-pathspec-native', 'python3-pip-native', 'python3-pluggy-native', 'python3-pygments-native
> > > ', 'python3-pyparsing-native', 'python3-pyproject-hooks-native', 'python3-setuptools-scm-native', 'python3-setuptools-native', 'python3-six-native', 'python3-trove-classifiers-native', 'python3-typing-extensions-native', 'python3-wheel-native', 'python3-native', 'squashfs-tools-native', 'unfs3-native', 'bzip2-native', 'cpio-native', 'diffutils-native', 'libarchive-native', 'libidn2-native', 'libnsl2-native', 'libsolv-native', 'libtirpc-native', 'parted-native', 'pigz-native', 'shadow-native', 'unzip-native', 'xz-n
> > > ative', 'zstd-native', 'libdrm-native', 'libepoxy-native', 'libsdl2-native', 'mesa-native', 'virglrenderer-native', 'wayland-protocols-native', 'wayland-native', 'xrandr-native', 'libpciaccess-native', 'libpthread-stubs-native', 'libx11-native', 'libxau-native', 'libxcb-native', 'libxdamage-native', 'libxdmcp-native', 'libxext-native', 'libxfix
> > > es-native', 'libxrandr-native', 'libxrender-native', 'libxshmfence-native', 'libxxf86vm-native', 'pixman-native', 'xtrans-native', 'xcb-proto-native', 'xorgproto-native', 'makedepend-native', 'util-macros-native', 'dtc-native', 'kmod-native', 'alsa-lib-native', 'libpng-native', 'acl-native', 'attr-native', 'bmaptool-native', 'curl-native', 'debianutils-native', 'gdbm-native', 'gmp-native', 'gnutls-native', 'libtasn1-native', 'libbsd-native', 'libcap-ng-native', 'libcap-native', 'libffi-native', 'libgcrypt-native',
> > >  'libgpg-error-native', 'libmd-native', 'libmicrohttpd-native', 'libpcre2-native', 'libunistring-native', 'lz4-native', 'lzo-native', 'nettle-native', 'popt-native', 'shared-mime-info-native', 'sqlite3-native']
> > > | DEBUG: Python function extend_recipe_sysroot finished
> > > | DEBUG: Executing python function set_image_size
> > > | DEBUG: 159546.400000 = 122728 * 1.300000
> > > | DEBUG: 163642.400000 = max(159546.400000, 8192)[159546.400000] + 4096
> > > | DEBUG: 163643.000000 = int(163642.400000)
> > > | DEBUG: 163643 = aligned(163643)
> > > | DEBUG: returning 163643
> > > | DEBUG: Python function set_image_size finished
> > > | DEBUG: Executing shell function do_image_wic
> > > | abort()ing pseudo client by server request. See https://wiki.yoctoproject.org/wiki/Pseudo_Abort for more details on this.
> > > | Check logfile: /home/mcfrisk/src/base/poky/build_genericarm64-st/tmp/work/genericarm64-poky-linux/core-image-minimal/1.0/pseudo//pseudo.log
> > > | WARNING: exit code 134 from a shell command.
> > > | Aborted
> > > NOTE: recipe core-image-minimal-1.0-r0: task do_image_wic: Failed
> > > ERROR: Task (/home/mcfrisk/src/base/poky/meta/recipes-core/images/core-image-minimal.bb:do_image_wic) failed with exit code '1' 
> > > Pseudo log:
> > > path mismatch [2 links]: ino 43965780 db '/home/mcfrisk/src/base/poky/build_genericarm64-st/tmp/work/genericarm64-poky-linux/core-image-minimal/1.0/rootfs/boot/loader/loader.conf' req '/home/mcfrisk/src/base/poky/build_genericarm64-st/tmp/work/genericarm64-poky-linux/core-image-minimal/1.0/tmp-wic/rootfs1/boot/loader/loader.conf'.
> > > Setup complete, sending SIGUSR1 to pid 117389.
> > >
> > > NOTE: Tasks Summary: Attempted 5254 tasks of which 5253 didn't need to be rerun and 1 failed.
> > >
> > > Summary: 1 task failed:
> > >   /home/mcfrisk/src/base/poky/meta/recipes-core/images/core-image-minimal.bb:do_image_wic
> > >     log: /home/mcfrisk/src/base/poky/build_genericarm64-st/tmp/work/genericarm64-poky-linux/core-image-minimal/1.0/temp/log.do_image_wic.117565
> > > Summary: There was 1 ERROR message, returning a non-zero exit code.
> > > ----------------------------------------------------------------------
> > > 2025-04-07 09:10:05,489 - oe-selftest - INFO - Ran 1 test in 2271.863s
> > > 2025-04-07 09:10:05,489 - oe-selftest - INFO - FAILED
> > > 2025-04-07 09:10:05,489 - oe-selftest - INFO -  (failures=1)
> > > 2025-04-07 09:10:11,706 - oe-selftest - INFO - RESULTS:
> > > 2025-04-07 09:10:11,706 - oe-selftest - INFO - RESULTS - wic.Wic.test_permissions: FAILED (2271.66s)
> > > 2025-04-07 09:10:11,708 - oe-selftest - INFO - SUMMARY:
> > > 2025-04-07 09:10:11,708 - oe-selftest - INFO - oe-selftest () - Ran 1 test in 2271.863s
> > > 2025-04-07 09:10:11,708 - oe-selftest - INFO - oe-selftest - FAIL - Required tests failed (successes=0, skipped=0, failures=1, errors=0)
> > >
> > > I think something in this test is faulty. For example building an image
> > > in yocto do_image with fakeroot/pseudo and then modifying it outside of build
> > > env with wic is likely going to fail like this.
> > >
> > > I will try with other machine targets and cleaner local.conf
> > > but I suspect I will run into this same issue again.
> > >
> > > And the error from your CI buidl was completely different... :/
> > >
> > > Cheers,
> > >
> > > -Mikko
> > 
> > I confirm, localally I see the same thing as you do: just some pseudo
> > errors. They seem to come from "image_types_wic.bbclass: capture verbose
> > wic output by default" patch.
> > 
> > So yes, different than on the autobuilder, but yet if I drop the series,
> > autobuilder builds do succeed :(
> > 
> > So we can hope there is an obscure link between both failures, but
> > that's all I've got so far.
> 
> With:
> 
> --- a/meta/lib/oeqa/selftest/cases/wic.py
> +++ b/meta/lib/oeqa/selftest/cases/wic.py
> @@ -674,6 +674,7 @@ part /etc --source rootfs --fstype=ext4 --change-directory=etc
>  
>                  config = 'IMAGE_FSTYPES += "wic"\nWKS_FILE = "%s"\n' % wks_file
>                  self.append_config(config)
> +                bitbake('-c clean core-image-minimal')
>                  bitbake('core-image-minimal')
>                  tmpdir = os.path.join(get_bb_var('WORKDIR', 'core-image-minimal'),'build-wic')
>  
> 
> the test is passing for me now without pseudo errors.
> 
> The debug logging patch is IMO unrelated. It's just capturing logs from wic by default.
> It could trigger rebuilds vs sstate cache if testing is done without and then with
> the patch applied. Is full world build done with this patch applied before
> selftests are run? I think this may impact the test as well.

Sent this out as "oeqa wic.py: clean image build dir before rebuild in test_permissions()"
separately. I think this test failure is unrelated to the changes but related to the
way tests are executed. I think tests behave different depending if sstate has the
image recipe output or not.

Cheers,

-Mikko

Re: [OE-core] [PATCH v3 00/11] systemd based initrd and modular kernel support

[Mathieu Dubois-Briand]

On Mon Apr 7, 2025 at 1:13 PM CEST, Mikko Rapeli wrote:
> Hi,
>
> On Mon, Apr 07, 2025 at 01:26:06PM +0300, Mikko Rapeli via lists.openembedded.org wrote:
> Sent this out as "oeqa wic.py: clean image build dir before rebuild in test_permissions()"
> separately. I think this test failure is unrelated to the changes but related to the
> way tests are executed. I think tests behave different depending if sstate has the
> image recipe output or not.
>
> Cheers,
>
> -Mikko

Ok, it seems this patch indeed fixes the oe-selftest on the autobuilder:
I had some successful builds this morning on a separate branch. Not sure
about what is really the link between the error we saw locally and the
one on the autobuilder.

I will pick both this series and the said patch in my -next branch later
today.

-- 
Mathieu Dubois-Briand, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com

Re: [OE-core] [PATCH v3 00/11] systemd based initrd and modular kernel support

[Mikko Rapeli]

Hi,

On Tue, Apr 08, 2025 at 01:26:21PM +0200, Mathieu Dubois-Briand wrote:
> On Mon Apr 7, 2025 at 1:13 PM CEST, Mikko Rapeli wrote:
> > Hi,
> >
> > On Mon, Apr 07, 2025 at 01:26:06PM +0300, Mikko Rapeli via lists.openembedded.org wrote:
> > Sent this out as "oeqa wic.py: clean image build dir before rebuild in test_permissions()"
> > separately. I think this test failure is unrelated to the changes but related to the
> > way tests are executed. I think tests behave different depending if sstate has the
> > image recipe output or not.
> >
> > Cheers,
> >
> > -Mikko
> 
> Ok, it seems this patch indeed fixes the oe-selftest on the autobuilder:
> I had some successful builds this morning on a separate branch. Not sure
> about what is really the link between the error we saw locally and the
> one on the autobuilder.
> 
> I will pick both this series and the said patch in my -next branch later
> today.

Thanks. I've also been running wic selftests and they seem to be fine
with this change. I had one additional failure, very similar
pseudo problem, with wic.Wic.test_wic_sector_size test and I was
testing fix/workaround:

--- a/meta/lib/oeqa/selftest/cases/wic.py
+++ b/meta/lib/oeqa/selftest/cases/wic.py
@@ -852,6 +852,7 @@ bootloader --ptable gpt""")
             config = 'WIC_SECTOR_SIZE = "4096"\n'\
                      'WICVARS:append = " WIC_SECTOR_SIZE"\n'
             self.append_config(config)
+            bitbake('-c clean core-image-minimal')
             bitbake('core-image-minimal')
 
             # Check WIC_SECTOR_SIZE apply to bitbake variable

but I can't reproduce the problem anymore. There is something happening
with sstate cache here. I think builds of core-image-minimal and possibly
world before running selftests hide these problems. I can't explain
the details either.

Cheers,

-Mikko