public inbox for isar-users@googlegroups.com
 help / color / mirror / Atom feed
From: "Moessbauer, Felix" <felix.moessbauer@siemens.com>
To: "isar-users@googlegroups.com" <isar-users@googlegroups.com>,
	"Gylstorff, Quirin" <quirin.gylstorff@siemens.com>,
	"Schild, Henning" <henning.schild@siemens.com>
Cc: "Kiszka, Jan" <jan.kiszka@siemens.com>
Subject: Issues creating images with custom initramfs
Date: Fri, 17 Feb 2023 05:54:33 +0000	[thread overview]
Message-ID: <fe1d4d9d9c269e15e24c89399942af0f59eaa81d.camel@siemens.com> (raw)

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


             reply	other threads:[~2023-02-17  5:54 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-02-17  5:54 Moessbauer, Felix [this message]
2023-02-17  7:16 ` Jan Kiszka

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=fe1d4d9d9c269e15e24c89399942af0f59eaa81d.camel@siemens.com \
    --to=felix.moessbauer@siemens.com \
    --cc=henning.schild@siemens.com \
    --cc=isar-users@googlegroups.com \
    --cc=jan.kiszka@siemens.com \
    --cc=quirin.gylstorff@siemens.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox