Issues creating images with custom initramfs

Issues creating images with custom initramfs

[Moessbauer, Felix]

Dear ISAR devs,

yesterday I observed an issue in an image with a custom initramfs (on
current next, using systemd-boot).
The image should mount a squashfs as rootfs and for that the squashfs
module is required in the initrd (for stock Debian kernels).

The problem is, that the module is never included in the initrd that
ends up in the final image (but with the efibootguard WIC plugin it is
sometimes!! included).

A very minimal reproducer is (using the squashfs hook from isar-cip-
core):

my-image.bb
inherit image
INITRAMFS_RECIPE = "my-initramfs"
INITRD_IMAGE = "${INITRAMFS_RECIPE}-${DISTRO}-${MACHINE}.initrd.img"
do_image_wic[depends] += "${INITRAMFS_RECIPE}:do_build"

my-initramfs.bb
inherit initramfs

INITRAMFS_INSTALL += " \
    initramfs-squashfs-hook \
    "

What I debugged so far:

Initial build:

lsinitramfs <deploy-dir>/my-initramfs-debian-bullseye-siemens-
ipc427e.initrd.img | grep squashfs : shows squashfs module path

Loop mount of /boot partition
lsinitramfs /mnt/loop1/initrd.img-5.10.0-21-amd64 | grep squashfs:
squashfs module is sometimes missing

bitbake -c cleansstate my-image
bitbake -c build my-image

lsinitramfs <deploy-dir>/my-initramfs-debian-bullseye-siemens-
ipc427e.initrd.img | grep squashfs : squashfs module is missing

Loop mount of /boot partition
lsinitramfs /mnt/loop1/initrd.img-5.10.0-21-amd64 | grep squashfs:
squashfs module is missing

Especially the non-determinism in the initramfs in the deploy dir
somehow indicates a race-condition. Another thing I don't understand is
how that should work at all. If I read the code correctly,
do_copy_boot_files copies the stock initrd from the rootfs recipe into
the deploy dir and potentially overwrites the existing initrd there.
But which version of the initrd does WIC read? The one from the rootfs
or the one in the deploy dir?

Best regards,
Felix

Re: Issues creating images with custom initramfs

[Jan Kiszka]

On 17.02.23 06:54, Moessbauer, Felix (T CED INW-CN) wrote:
> Dear ISAR devs,
> 
> yesterday I observed an issue in an image with a custom initramfs (on
> current next, using systemd-boot).
> The image should mount a squashfs as rootfs and for that the squashfs
> module is required in the initrd (for stock Debian kernels).
> 
> The problem is, that the module is never included in the initrd that
> ends up in the final image (but with the efibootguard WIC plugin it is
> sometimes!! included).
> 
> A very minimal reproducer is (using the squashfs hook from isar-cip-
> core):
> 
> my-image.bb
> inherit image
> INITRAMFS_RECIPE = "my-initramfs"
> INITRD_IMAGE = "${INITRAMFS_RECIPE}-${DISTRO}-${MACHINE}.initrd.img"
> do_image_wic[depends] += "${INITRAMFS_RECIPE}:do_build"
> 
> my-initramfs.bb
> inherit initramfs
> 
> INITRAMFS_INSTALL += " \
>     initramfs-squashfs-hook \
>     "
> 
> What I debugged so far:
> 
> Initial build:
> 
> lsinitramfs <deploy-dir>/my-initramfs-debian-bullseye-siemens-
> ipc427e.initrd.img | grep squashfs : shows squashfs module path
> 
> Loop mount of /boot partition
> lsinitramfs /mnt/loop1/initrd.img-5.10.0-21-amd64 | grep squashfs:
> squashfs module is sometimes missing
> 
> bitbake -c cleansstate my-image
> bitbake -c build my-image
> 
> lsinitramfs <deploy-dir>/my-initramfs-debian-bullseye-siemens-
> ipc427e.initrd.img | grep squashfs : squashfs module is missing
> 
> Loop mount of /boot partition
> lsinitramfs /mnt/loop1/initrd.img-5.10.0-21-amd64 | grep squashfs:
> squashfs module is missing
> 
> Especially the non-determinism in the initramfs in the deploy dir
> somehow indicates a race-condition. Another thing I don't understand is
> how that should work at all. If I read the code correctly,
> do_copy_boot_files copies the stock initrd from the rootfs recipe into
> the deploy dir and potentially overwrites the existing initrd there.
> But which version of the initrd does WIC read? The one from the rootfs
> or the one in the deploy dir?

There is INITRD_IMAGE describing the target initramfs filename in
DEPLOY_DIR_IMAGE. An initramfs recipe should generally depend on the
rootfs to be ready, thus also do_copy_boot_files was already run by
then. That task pulled the initramfs from the rootfs, and the initramfs
recipe will later on simply overwrite that. wic plugins will therefore
use the overwritten version.

But you should be able to visualize this dependency graph to confirm
this or prove it to be wrong for the case that showed undeterministic
behavior.

Jan

-- 
Siemens AG, Technology
Competence Center Embedded Linux