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

[PATCH v2 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

Mikko Rapeli (11):
  systemd: enable efi support if in MACHINE_FEATURES too
  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               | 46 +++++++++++
 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.3.bb    |  1 +
 scripts/lib/wic/plugins/source/bootimg-efi.py |  3 +
 10 files changed, 200 insertions(+), 8 deletions(-)

-- 
2.43.0

[PATCH v2 01/11] systemd: enable efi support if in MACHINE_FEATURES too

[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 if it's in MACHINE_FEATURES.
Fixes efivars mount to /sys/firmware/efi/efivars etc.

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

diff --git a/meta/recipes-core/systemd/systemd_257.3.bb b/meta/recipes-core/systemd/systemd_257.3.bb
index 64fb8fe69a..9bc4532021 100644
--- a/meta/recipes-core/systemd/systemd_257.3.bb
+++ b/meta/recipes-core/systemd/systemd_257.3.bb
@@ -69,6 +69,7 @@ PAM_PLUGINS = " \
 
 PACKAGECONFIG ??= " \
     ${@bb.utils.filter('DISTRO_FEATURES', 'acl audit apparmor efi ldconfig pam pni-names selinux smack polkit seccomp', d)} \
+    ${@bb.utils.filter('MACHINE_FEATURES', 'efi', 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)} \
-- 
2.43.0

[PATCH v2 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 v2 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               | 46 +++++++++++++++++++
 meta/classes-recipe/kernel.bbclass            |  5 +-
 meta/classes-recipe/module.bbclass            | 37 +++++++++++++++
 3 files changed, 87 insertions(+), 1 deletion(-)

diff --git a/meta/classes-recipe/kernel-module-split.bbclass b/meta/classes-recipe/kernel-module-split.bbclass
index 9487365eb7..06e8fbed6e 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,18 @@ 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')
+    initrd_module_regex = re.compile(d.getVar('KERNEL_INITRD_MODULES_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 64a685a964..8fda61574d 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

[PATCH v2 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

[PATCH v2 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

[PATCH v2 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 v2 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 v2 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 v2 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

[PATCH v2 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

[PATCH v2 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

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

[patchtest]

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

Thank you for your submission. Patchtest identified one
or more issues with the patch. Please see the log below for
more information:

---
Testing patch /home/patchtest/share/mboxes/v2-11-11-image_types_wic.bbclass-depend-on-grub-efi-and-systemd-boot-on-aarch64-systemd-boot-on-arm.patch

FAIL: test shortlog length: Edit shortlog so that it is 90 characters or less (currently 92 characters) (test_mbox.TestMbox.test_shortlog_length)

PASS: test Signed-off-by presence (test_mbox.TestMbox.test_signed_off_by_presence)
PASS: test author valid (test_mbox.TestMbox.test_author_valid)
PASS: test commit message presence (test_mbox.TestMbox.test_commit_message_presence)
PASS: test commit message user tags (test_mbox.TestMbox.test_commit_message_user_tags)
PASS: test max line length (test_metadata.TestMetadata.test_max_line_length)
PASS: test mbox format (test_mbox.TestMbox.test_mbox_format)
PASS: test non-AUH upgrade (test_mbox.TestMbox.test_non_auh_upgrade)
PASS: test shortlog format (test_mbox.TestMbox.test_shortlog_format)
PASS: test target mailing list (test_mbox.TestMbox.test_target_mailing_list)

SKIP: pretest pylint: No python related patches, skipping test (test_python_pylint.PyLint.pretest_pylint)
SKIP: pretest src uri left files: No modified recipes, skipping pretest (test_metadata.TestMetadata.pretest_src_uri_left_files)
SKIP: test CVE check ignore: No modified recipes or older target branch, skipping test (test_metadata.TestMetadata.test_cve_check_ignore)
SKIP: test CVE tag format: No new CVE patches introduced (test_patch.TestPatch.test_cve_tag_format)
SKIP: test Signed-off-by presence: No new CVE patches introduced (test_patch.TestPatch.test_signed_off_by_presence)
SKIP: test Upstream-Status presence: No new CVE patches introduced (test_patch.TestPatch.test_upstream_status_presence_format)
SKIP: test bugzilla entry format: No bug ID found (test_mbox.TestMbox.test_bugzilla_entry_format)
SKIP: test lic files chksum modified not mentioned: No modified recipes, skipping test (test_metadata.TestMetadata.test_lic_files_chksum_modified_not_mentioned)
SKIP: test lic files chksum presence: No added recipes, skipping test (test_metadata.TestMetadata.test_lic_files_chksum_presence)
SKIP: test license presence: No added recipes, skipping test (test_metadata.TestMetadata.test_license_presence)
SKIP: test pylint: No python related patches, skipping test (test_python_pylint.PyLint.test_pylint)
SKIP: test series merge on head: Merge test is disabled for now (test_mbox.TestMbox.test_series_merge_on_head)
SKIP: test src uri left files: No modified recipes, skipping pretest (test_metadata.TestMetadata.test_src_uri_left_files)
SKIP: test summary presence: No added recipes, skipping test (test_metadata.TestMetadata.test_summary_presence)

---

Please address the issues identified and
submit a new revision of the patch, or alternatively, reply to this
email with an explanation of why the patch should be accepted. If you
believe these results are due to an error in patchtest, please submit a
bug at https://bugzilla.yoctoproject.org/ (use the 'Patchtest' category
under 'Yocto Project Subprojects'). For more information on specific
failures, see: https://wiki.yoctoproject.org/wiki/Patchtest. Thank
you!

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

[Bruce Ashfield]

I was going to reply to v1, but v2 came out before I got to it!

In message: [OE-core] [PATCH v2 03/11] kernel.bbclass: add kernel-initrd-modules meta package
on 21/03/2025 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 list of paths gives me the nagging feeling that there's
a better way. With the paths, it is just something else to
maintain and has to work against an undefined set of kernel and
kernel versions (not that major directories in the kernel change,
so I don't think it is a big issue).

There won't be a way to do this generically, but I'd prefer that
this was driven from the kernel recipes down to the packaging,
instead of the packaging (the classes) coming along after and
trying to serve the needs of those undefined sets of recipes and
configurations.

The simplest would be to have the kernel recipes provide that
regex. That way the coupling of directories to the kernel
version and provider is explicit. Sure, that means the regex
is in recipes (and possibly repeated), but individual layers
and kernel providers can figure out how to minimize that
themselvs (.inc or whatever), so it is a solvable problem.

The other way that I was thinking was an annotation in the
module meta-data that could do the same thing. i.e. it could
tag a configuration option's purpose and then use that to
generate the list of modules (versus the directories), but
again, that would just go in the recipe versus the base classes
and would allow different providers to have different ways
of specifying what is for the initrd.

I honestly wouldn't provide a default in the bbclass as we
just have no way to test it for all the different kernels
and kernel providers in the ecosystem. Make the opt-in
explicit by requiring it in the kernel recipe to start
building the meta-package.

> 
> 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               | 46 +++++++++++++++++++
>  meta/classes-recipe/kernel.bbclass            |  5 +-
>  meta/classes-recipe/module.bbclass            | 37 +++++++++++++++
>  3 files changed, 87 insertions(+), 1 deletion(-)
> 
> diff --git a/meta/classes-recipe/kernel-module-split.bbclass b/meta/classes-recipe/kernel-module-split.bbclass
> index 9487365eb7..06e8fbed6e 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/\
> +)(.*)"
> +

Is that the same regex in both files ? We probably should unify them or
maintainence will be harder, which is why I'm suggesting that this
should come from the recipes, not the bbclass itself.

>  python split_kernel_module_packages () {
>      import re
>  
> @@ -183,6 +217,18 @@ 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')
> +    initrd_module_regex = re.compile(d.getVar('KERNEL_INITRD_MODULES_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))

I'd suggest that we could also have a flag to completely skip the
processing. It isn't a particularly expensive set of operations, but
we tend to not do processing for boot modes that won't be used.

If it was driven top-down from a kernel recipe like I mentioned
above, just testing if the KERNEL_INITRD_MODULES_REGEX was defined
might be a good flag for the job.

Bruce

>  }
>  
>  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 64a685a964..8fda61574d 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 (#213459): https://lists.openembedded.org/g/openembedded-core/message/213459
> Mute This Topic: https://lists.openembedded.org/mt/111827585/1050810
> Group Owner: openembedded-core+owner@lists.openembedded.org
> Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [bruce.ashfield@gmail.com]
> -=-=-=-=-=-=-=-=-=-=-=-
> 

Re: [OE-core] [PATCH v2 01/11] systemd: enable efi support if in MACHINE_FEATURES too

[Richard Purdie]

On Fri, 2025-03-21 at 15:25 +0200, 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 if it's in MACHINE_FEATURES.
> Fixes efivars mount to /sys/firmware/efi/efivars etc.
> 
> Signed-off-by: Mikko Rapeli <mikko.rapeli@linaro.org>
> ---
>  meta/recipes-core/systemd/systemd_257.3.bb | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/meta/recipes-core/systemd/systemd_257.3.bb b/meta/recipes-core/systemd/systemd_257.3.bb
> index 64fb8fe69a..9bc4532021 100644
> --- a/meta/recipes-core/systemd/systemd_257.3.bb
> +++ b/meta/recipes-core/systemd/systemd_257.3.bb
> @@ -69,6 +69,7 @@ PAM_PLUGINS = " \
>  
>  PACKAGECONFIG ??= " \
>      ${@bb.utils.filter('DISTRO_FEATURES', 'acl audit apparmor efi ldconfig pam pni-names selinux smack polkit seccomp', d)} \
> +    ${@bb.utils.filter('MACHINE_FEATURES', 'efi', 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)} \

This makes the systemd recipe machine specific which isn't currently the case.

Cheers,

Richard

Re: [OE-core] [PATCH v2 01/11] systemd: enable efi support if in MACHINE_FEATURES too

[Mikko Rapeli]

Hi,

On Sun, Mar 23, 2025 at 10:53:59AM +0000, Richard Purdie wrote:
> On Fri, 2025-03-21 at 15:25 +0200, 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 if it's in MACHINE_FEATURES.
> > Fixes efivars mount to /sys/firmware/efi/efivars etc.
> > 
> > Signed-off-by: Mikko Rapeli <mikko.rapeli@linaro.org>
> > ---
> > �meta/recipes-core/systemd/systemd_257.3.bb | 1 +
> > �1 file changed, 1 insertion(+)
> > 
> > diff --git a/meta/recipes-core/systemd/systemd_257.3.bb b/meta/recipes-core/systemd/systemd_257.3.bb
> > index 64fb8fe69a..9bc4532021 100644
> > --- a/meta/recipes-core/systemd/systemd_257.3.bb
> > +++ b/meta/recipes-core/systemd/systemd_257.3.bb
> > @@ -69,6 +69,7 @@ PAM_PLUGINS = " \
> > �
> > �PACKAGECONFIG ??= " \
> > ���� ${@bb.utils.filter('DISTRO_FEATURES', 'acl audit apparmor efi ldconfig pam pni-names selinux smack polkit seccomp', d)} \
> > +��� ${@bb.utils.filter('MACHINE_FEATURES', 'efi', 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)} \
> 
> This makes the systemd recipe machine specific which isn't currently the case.

Can we enable "efi" in DISTRO_FEATURES by default?

That would solve the issue without checking MACHINE_FEATURES in systemd recipe.

Cheers,

-Mikko

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

[Mikko Rapeli]

Hi,

On Fri, Mar 21, 2025 at 10:59:50AM -0400, Bruce Ashfield wrote:
> I was going to reply to v1, but v2 came out before I got to it!
>
> In message: [OE-core] [PATCH v2 03/11] kernel.bbclass: add kernel-initrd-modules meta package
> on 21/03/2025 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 list of paths gives me the nagging feeling that there's
> a better way. With the paths, it is just something else to
> maintain and has to work against an undefined set of kernel and
> kernel versions (not that major directories in the kernel change,
> so I don't think it is a big issue).
> 
> There won't be a way to do this generically, but I'd prefer that
> this was driven from the kernel recipes down to the packaging,
> instead of the packaging (the classes) coming along after and
> trying to serve the needs of those undefined sets of recipes and
> configurations.
> 
> The simplest would be to have the kernel recipes provide that
> regex. That way the coupling of directories to the kernel
> version and provider is explicit. Sure, that means the regex
> is in recipes (and possibly repeated), but individual layers
> and kernel providers can figure out how to minimize that
> themselvs (.inc or whatever), so it is a solvable problem.
> 
> The other way that I was thinking was an annotation in the
> module meta-data that could do the same thing. i.e. it could
> tag a configuration option's purpose and then use that to
> generate the list of modules (versus the directories), but
> again, that would just go in the recipe versus the base classes
> and would allow different providers to have different ways
> of specifying what is for the initrd.
> 
> I honestly wouldn't provide a default in the bbclass as we
> just have no way to test it for all the different kernels
> and kernel providers in the ecosystem. Make the opt-in
> explicit by requiring it in the kernel recipe to start
> building the meta-package.

I can move the regexp to kernel recipe. That makes sense.

Tagging for custom kernel modules could be done, maybe
through another variable which lists other kernel
modules to include. But then this should not be specific
to kernel as there may be other extra packages that
may need to be added. Since the regex with paths creates
generally usable initrd which are obviously not optimised
for specific usecases or HW or machine/distro config, I
omitted those for now.

For the best result, users can change everything in the
core-image-initramfs-boot recipe or replace with their own
recipe.

> > 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               | 46 +++++++++++++++++++
> >  meta/classes-recipe/kernel.bbclass            |  5 +-
> >  meta/classes-recipe/module.bbclass            | 37 +++++++++++++++
> >  3 files changed, 87 insertions(+), 1 deletion(-)
> > 
> > diff --git a/meta/classes-recipe/kernel-module-split.bbclass b/meta/classes-recipe/kernel-module-split.bbclass
> > index 9487365eb7..06e8fbed6e 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/\
> > +)(.*)"
> > +
> 
> Is that the same regex in both files ? We probably should unify them or
> maintainence will be harder, which is why I'm suggesting that this
> should come from the recipes, not the bbclass itself.

ACK, movint to kernel recipe and reducing to single variable.
 
> >  python split_kernel_module_packages () {
> >      import re
> >  
> > @@ -183,6 +217,18 @@ 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')
> > +    initrd_module_regex = re.compile(d.getVar('KERNEL_INITRD_MODULES_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))
> 
> I'd suggest that we could also have a flag to completely skip the
> processing. It isn't a particularly expensive set of operations, but
> we tend to not do processing for boot modes that won't be used.
> 
> If it was driven top-down from a kernel recipe like I mentioned
> above, just testing if the KERNEL_INITRD_MODULES_REGEX was defined
> might be a good flag for the job.

Thanks, will do this in v3.

Cheers,

-Mikko

Re: [OE-core] [PATCH v2 01/11] systemd: enable efi support if in MACHINE_FEATURES too

[Mikko Rapeli]

On Mon, Mar 24, 2025 at 09:29:48AM +0200, Mikko Rapeli via lists.openembedded.org wrote:
> Hi,
> 
> On Sun, Mar 23, 2025 at 10:53:59AM +0000, Richard Purdie wrote:
> > On Fri, 2025-03-21 at 15:25 +0200, 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 if it's in MACHINE_FEATURES.
> > > Fixes efivars mount to /sys/firmware/efi/efivars etc.
> > > 
> > > Signed-off-by: Mikko Rapeli <mikko.rapeli@linaro.org>
> > > ---
> > > �meta/recipes-core/systemd/systemd_257.3.bb | 1 +
> > > �1 file changed, 1 insertion(+)
> > > 
> > > diff --git a/meta/recipes-core/systemd/systemd_257.3.bb b/meta/recipes-core/systemd/systemd_257.3.bb
> > > index 64fb8fe69a..9bc4532021 100644
> > > --- a/meta/recipes-core/systemd/systemd_257.3.bb
> > > +++ b/meta/recipes-core/systemd/systemd_257.3.bb
> > > @@ -69,6 +69,7 @@ PAM_PLUGINS = " \
> > > �
> > > �PACKAGECONFIG ??= " \
> > > ���� ${@bb.utils.filter('DISTRO_FEATURES', 'acl audit apparmor efi ldconfig pam pni-names selinux smack polkit seccomp', d)} \
> > > +��� ${@bb.utils.filter('MACHINE_FEATURES', 'efi', 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)} \
> > 
> > This makes the systemd recipe machine specific which isn't currently the case.
> 
> Can we enable "efi" in DISTRO_FEATURES by default?
> 
> That would solve the issue without checking MACHINE_FEATURES in systemd recipe.

Or we just enable "efi" support in systemd by default, or bind it to the new
"systemd-initramfs" DISTRO_FEATURE.

systemd in initrd doesn't work if the EFI ESP partition isn't mounted
and for that the 'efi' support needs to be enabled.

Cheers,

-Mikko

Re: [OE-core] [PATCH v2 01/11] systemd: enable efi support if in MACHINE_FEATURES too

[Richard Purdie]

On Mon, 2025-03-24 at 09:43 +0200, Mikko Rapeli wrote:
> On Mon, Mar 24, 2025 at 09:29:48AM +0200, Mikko Rapeli via lists.openembedded.org wrote:
> > Hi,
> > 
> > On Sun, Mar 23, 2025 at 10:53:59AM +0000, Richard Purdie wrote:
> > > On Fri, 2025-03-21 at 15:25 +0200, 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 if it's in MACHINE_FEATURES.
> > > > Fixes efivars mount to /sys/firmware/efi/efivars etc.
> > > > 
> > > > Signed-off-by: Mikko Rapeli <mikko.rapeli@linaro.org>
> > > > ---
> > > >  meta/recipes-core/systemd/systemd_257.3.bb | 1 +
> > > >  1 file changed, 1 insertion(+)
> > > > 
> > > > diff --git a/meta/recipes-core/systemd/systemd_257.3.bb b/meta/recipes-core/systemd/systemd_257.3.bb
> > > > index 64fb8fe69a..9bc4532021 100644
> > > > --- a/meta/recipes-core/systemd/systemd_257.3.bb
> > > > +++ b/meta/recipes-core/systemd/systemd_257.3.bb
> > > > @@ -69,6 +69,7 @@ PAM_PLUGINS = " \
> > > >  
> > > >  PACKAGECONFIG ??= " \
> > > >      ${@bb.utils.filter('DISTRO_FEATURES', 'acl audit apparmor efi ldconfig pam pni-names selinux smack polkit seccomp', d)} \
> > > > +    ${@bb.utils.filter('MACHINE_FEATURES', 'efi', 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)} \
> > > 
> > > This makes the systemd recipe machine specific which isn't currently the case.
> > 
> > Can we enable "efi" in DISTRO_FEATURES by default?
> > 
> > That would solve the issue without checking MACHINE_FEATURES in systemd recipe.
> 
> Or we just enable "efi" support in systemd by default, or bind it to the new
> "systemd-initramfs" DISTRO_FEATURE.
> 
> systemd in initrd doesn't work if the EFI ESP partition isn't mounted
> and for that the 'efi' support needs to be enabled.

I suspect enabling it by default might be the simpler solution.

Cheers,

Richard

Re: [OE-core] [PATCH v2 01/11] systemd: enable efi support if in MACHINE_FEATURES too

[Koen Kooi]

> Op 24 mrt 2025, om 08:29 heeft Mikko Rapeli via lists.openembedded.org <mikko.rapeli=linaro.org@lists.openembedded.org> het volgende geschreven:
> 
> Hi,
> 
> On Sun, Mar 23, 2025 at 10:53:59AM +0000, Richard Purdie wrote:
>> On Fri, 2025-03-21 at 15:25 +0200, 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 if it's in MACHINE_FEATURES.
>>> Fixes efivars mount to /sys/firmware/efi/efivars etc.
>>> 
>>> Signed-off-by: Mikko Rapeli <mikko.rapeli@linaro.org>
>>> ---
>>>  meta/recipes-core/systemd/systemd_257.3.bb | 1 +
>>>  1 file changed, 1 insertion(+)
>>> 
>>> diff --git a/meta/recipes-core/systemd/systemd_257.3.bb b/meta/recipes-core/systemd/systemd_257.3.bb
>>> index 64fb8fe69a..9bc4532021 100644
>>> --- a/meta/recipes-core/systemd/systemd_257.3.bb
>>> +++ b/meta/recipes-core/systemd/systemd_257.3.bb
>>> @@ -69,6 +69,7 @@ PAM_PLUGINS = " \
>>>  
>>>  PACKAGECONFIG ??= " \
>>>      ${@bb.utils.filter('DISTRO_FEATURES', 'acl audit apparmor efi ldconfig pam pni-names selinux smack polkit seccomp', d)} \
>>> +    ${@bb.utils.filter('MACHINE_FEATURES', 'efi', 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)} \
>> 
>> This makes the systemd recipe machine specific which isn't currently the case.
> 
> Can we enable "efi" in DISTRO_FEATURES by default?
> 
> That would solve the issue without checking MACHINE_FEATURES in systemd recipe.

If your DISTRO doesn't enable it you can either pick a more suitable DISTRO or send patches to fix your DISTRO. Changing OE-core wide defaults is the wrong thing to do.

regards,

Koen

Re: [OE-core] [PATCH v2 01/11] systemd: enable efi support if in MACHINE_FEATURES too

[Koen Kooi]

> Op 23 mrt 2025, om 11:53 heeft Richard Purdie via lists.openembedded.org <richard.purdie=linuxfoundation.org@lists.openembedded.org> het volgende geschreven:
> 
> On Fri, 2025-03-21 at 15:25 +0200, 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 if it's in MACHINE_FEATURES.
>> Fixes efivars mount to /sys/firmware/efi/efivars etc.
>> 
>> Signed-off-by: Mikko Rapeli <mikko.rapeli@linaro.org>
>> ---
>>  meta/recipes-core/systemd/systemd_257.3.bb | 1 +
>>  1 file changed, 1 insertion(+)
>> 
>> diff --git a/meta/recipes-core/systemd/systemd_257.3.bb b/meta/recipes-core/systemd/systemd_257.3.bb
>> index 64fb8fe69a..9bc4532021 100644
>> --- a/meta/recipes-core/systemd/systemd_257.3.bb
>> +++ b/meta/recipes-core/systemd/systemd_257.3.bb
>> @@ -69,6 +69,7 @@ PAM_PLUGINS = " \
>>  
>>  PACKAGECONFIG ??= " \
>>      ${@bb.utils.filter('DISTRO_FEATURES', 'acl audit apparmor efi ldconfig pam pni-names selinux smack polkit seccomp', d)} \
>> +    ${@bb.utils.filter('MACHINE_FEATURES', 'efi', 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)} \
> 
> This makes the systemd recipe machine specific which isn't currently the case.

And it also side steps DISTRO configs that don't enable 'efi' in DISTRO_FEATURES, which breaks the belief that DISTROs get the final say on policy.

regards,

Koen

Re: [OE-core] [PATCH v2 01/11] systemd: enable efi support if in MACHINE_FEATURES too

[Mikko Rapeli]

Hi,

On Mon, Mar 24, 2025 at 09:50:42AM +0100, Koen Kooi wrote:
> 
> > Op 24 mrt 2025, om 08:29 heeft Mikko Rapeli via lists.openembedded.org <mikko.rapeli=linaro.org@lists.openembedded.org> het volgende geschreven:
> > 
> > Hi,
> > 
> > On Sun, Mar 23, 2025 at 10:53:59AM +0000, Richard Purdie wrote:
> >> On Fri, 2025-03-21 at 15:25 +0200, 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 if it's in MACHINE_FEATURES.
> >>> Fixes efivars mount to /sys/firmware/efi/efivars etc.
> >>> 
> >>> Signed-off-by: Mikko Rapeli <mikko.rapeli@linaro.org>
> >>> ---
> >>>  meta/recipes-core/systemd/systemd_257.3.bb | 1 +
> >>>  1 file changed, 1 insertion(+)
> >>> 
> >>> diff --git a/meta/recipes-core/systemd/systemd_257.3.bb b/meta/recipes-core/systemd/systemd_257.3.bb
> >>> index 64fb8fe69a..9bc4532021 100644
> >>> --- a/meta/recipes-core/systemd/systemd_257.3.bb
> >>> +++ b/meta/recipes-core/systemd/systemd_257.3.bb
> >>> @@ -69,6 +69,7 @@ PAM_PLUGINS = " \
> >>>  
> >>>  PACKAGECONFIG ??= " \
> >>>      ${@bb.utils.filter('DISTRO_FEATURES', 'acl audit apparmor efi ldconfig pam pni-names selinux smack polkit seccomp', d)} \
> >>> +    ${@bb.utils.filter('MACHINE_FEATURES', 'efi', 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)} \
> >> 
> >> This makes the systemd recipe machine specific which isn't currently the case.
> > 
> > Can we enable "efi" in DISTRO_FEATURES by default?
> > 
> > That would solve the issue without checking MACHINE_FEATURES in systemd recipe.
> 
> If your DISTRO doesn't enable it you can either pick a more suitable DISTRO or send patches to fix your DISTRO. Changing OE-core wide defaults is the wrong thing to do.

The DISTROs I care about with this patch set are poky or poky-altcfg.

When systemd is selected as init, it currently doesn't work in initramfs
on UEFI systemd even when MACHINE_FEATURES has "efi" enabled.

Cheers,

-Mikko

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

[Bruce Ashfield]

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

On Mon, Mar 24, 2025 at 3:40 AM Mikko Rapeli <mikko.rapeli@linaro.org>
wrote:

> Hi,
>
> On Fri, Mar 21, 2025 at 10:59:50AM -0400, Bruce Ashfield wrote:
> > I was going to reply to v1, but v2 came out before I got to it!
> >
> > In message: [OE-core] [PATCH v2 03/11] kernel.bbclass: add
> kernel-initrd-modules meta package
> > on 21/03/2025 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 list of paths gives me the nagging feeling that there's
> > a better way. With the paths, it is just something else to
> > maintain and has to work against an undefined set of kernel and
> > kernel versions (not that major directories in the kernel change,
> > so I don't think it is a big issue).
> >
> > There won't be a way to do this generically, but I'd prefer that
> > this was driven from the kernel recipes down to the packaging,
> > instead of the packaging (the classes) coming along after and
> > trying to serve the needs of those undefined sets of recipes and
> > configurations.
> >
> > The simplest would be to have the kernel recipes provide that
> > regex. That way the coupling of directories to the kernel
> > version and provider is explicit. Sure, that means the regex
> > is in recipes (and possibly repeated), but individual layers
> > and kernel providers can figure out how to minimize that
> > themselvs (.inc or whatever), so it is a solvable problem.
> >
> > The other way that I was thinking was an annotation in the
> > module meta-data that could do the same thing. i.e. it could
> > tag a configuration option's purpose and then use that to
> > generate the list of modules (versus the directories), but
> > again, that would just go in the recipe versus the base classes
> > and would allow different providers to have different ways
> > of specifying what is for the initrd.
> >
> > I honestly wouldn't provide a default in the bbclass as we
> > just have no way to test it for all the different kernels
> > and kernel providers in the ecosystem. Make the opt-in
> > explicit by requiring it in the kernel recipe to start
> > building the meta-package.
>
> I can move the regexp to kernel recipe. That makes sense.
>
> Tagging for custom kernel modules could be done, maybe
> through another variable which lists other kernel
> modules to include. But then this should not be specific
> to kernel as there may be other extra packages that
> may need to be added. Since the regex with paths creates
> generally usable initrd which are obviously not optimised
> for specific usecases or HW or machine/distro config, I
> omitted those for now.
>

I agree that it is a good starting point. With the regex moved
to the recipes, it fundamentally doesn't matter if it is done by
the regex, some sort of tagging or as you added, someone
just doing their own complete recipe.

Trying to get it too precise at the start is a waste of effort.

I'm taking a close look at the kernel configuration bits and
the tooling early this week, hopefully that will be about the
same time as your v3 for easier testing for anyone interested.

Cheers,

Bruce



>
> For the best result, users can change everything in the
> core-image-initramfs-boot recipe or replace with their own
> recipe.
>
> > > 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               | 46 +++++++++++++++++++
> > >  meta/classes-recipe/kernel.bbclass            |  5 +-
> > >  meta/classes-recipe/module.bbclass            | 37 +++++++++++++++
> > >  3 files changed, 87 insertions(+), 1 deletion(-)
> > >
> > > diff --git a/meta/classes-recipe/kernel-module-split.bbclass
> b/meta/classes-recipe/kernel-module-split.bbclass
> > > index 9487365eb7..06e8fbed6e 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/\
> > > +)(.*)"
> > > +
> >
> > Is that the same regex in both files ? We probably should unify them or
> > maintainence will be harder, which is why I'm suggesting that this
> > should come from the recipes, not the bbclass itself.
>
> ACK, movint to kernel recipe and reducing to single variable.
>
> > >  python split_kernel_module_packages () {
> > >      import re
> > >
> > > @@ -183,6 +217,18 @@ 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')
> > > +    initrd_module_regex =
> re.compile(d.getVar('KERNEL_INITRD_MODULES_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))
> >
> > I'd suggest that we could also have a flag to completely skip the
> > processing. It isn't a particularly expensive set of operations, but
> > we tend to not do processing for boot modes that won't be used.
> >
> > If it was driven top-down from a kernel recipe like I mentioned
> > above, just testing if the KERNEL_INITRD_MODULES_REGEX was defined
> > might be a good flag for the job.
>
> Thanks, will do this in v3.
>
> 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: 11818 bytes --]

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

[Mikko Rapeli]

Hi,

On Fri, Mar 21, 2025 at 10:59:50AM -0400, Bruce Ashfield wrote:
> I was going to reply to v1, but v2 came out before I got to it!
> 
> In message: [OE-core] [PATCH v2 03/11] kernel.bbclass: add kernel-initrd-modules meta package
> on 21/03/2025 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 list of paths gives me the nagging feeling that there's
> a better way. With the paths, it is just something else to
> maintain and has to work against an undefined set of kernel and
> kernel versions (not that major directories in the kernel change,
> so I don't think it is a big issue).
> 
> There won't be a way to do this generically, but I'd prefer that
> this was driven from the kernel recipes down to the packaging,
> instead of the packaging (the classes) coming along after and
> trying to serve the needs of those undefined sets of recipes and
> configurations.
>
> The simplest would be to have the kernel recipes provide that
> regex. That way the coupling of directories to the kernel
> version and provider is explicit. Sure, that means the regex
> is in recipes (and possibly repeated), but individual layers
> and kernel providers can figure out how to minimize that
> themselvs (.inc or whatever), so it is a solvable problem.

What about BSP kernels which don't use linux-yocto but do use
the kernel bbclasses?

I think they should be made compatible with initrd recipes
and thus the classes should generate this meta package and also
initialize the regex and other variables with some simple defaults.

This could make it easier to boot upstream initrd and images with
vendor kernels and configurations.

Cheers,

-Mikko

> The other way that I was thinking was an annotation in the
> module meta-data that could do the same thing. i.e. it could
> tag a configuration option's purpose and then use that to
> generate the list of modules (versus the directories), but
> again, that would just go in the recipe versus the base classes
> and would allow different providers to have different ways
> of specifying what is for the initrd.
> 
> I honestly wouldn't provide a default in the bbclass as we
> just have no way to test it for all the different kernels
> and kernel providers in the ecosystem. Make the opt-in
> explicit by requiring it in the kernel recipe to start
> building the meta-package.
> 
> > 
> > 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               | 46 +++++++++++++++++++
> >  meta/classes-recipe/kernel.bbclass            |  5 +-
> >  meta/classes-recipe/module.bbclass            | 37 +++++++++++++++
> >  3 files changed, 87 insertions(+), 1 deletion(-)
> > 
> > diff --git a/meta/classes-recipe/kernel-module-split.bbclass b/meta/classes-recipe/kernel-module-split.bbclass
> > index 9487365eb7..06e8fbed6e 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/\
> > +)(.*)"
> > +
> 
> Is that the same regex in both files ? We probably should unify them or
> maintainence will be harder, which is why I'm suggesting that this
> should come from the recipes, not the bbclass itself.
> 
> >  python split_kernel_module_packages () {
> >      import re
> >  
> > @@ -183,6 +217,18 @@ 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')
> > +    initrd_module_regex = re.compile(d.getVar('KERNEL_INITRD_MODULES_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))
> 
> I'd suggest that we could also have a flag to completely skip the
> processing. It isn't a particularly expensive set of operations, but
> we tend to not do processing for boot modes that won't be used.
> 
> If it was driven top-down from a kernel recipe like I mentioned
> above, just testing if the KERNEL_INITRD_MODULES_REGEX was defined
> might be a good flag for the job.
> 
> Bruce
> 
> >  }
> >  
> >  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 64a685a964..8fda61574d 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 (#213459): https://lists.openembedded.org/g/openembedded-core/message/213459
> > Mute This Topic: https://lists.openembedded.org/mt/111827585/1050810
> > Group Owner: openembedded-core+owner@lists.openembedded.org
> > Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [bruce.ashfield@gmail.com]
> > -=-=-=-=-=-=-=-=-=-=-=-
> > 
>