[PATCH v2 RESEND 1/2] fix: copy boot files after finishing all rootfs operations

[Felix Moessbauer]

By that, we make sure that all operations (including initrd generation)
are finished before transitioning into the imaging step. Also, this
structures the build into the rootfs and the imaging steps.

Signed-off-by: Felix Moessbauer <felix.mo...@siemens.com>
---
meta/classes/image.bbclass | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meta/classes/image.bbclass b/meta/classes/image.bbclass
index c29d9e26..0dea06fa 100644
--- a/meta/classes/image.bbclass
+++ b/meta/classes/image.bbclass
@@ -363,7 +363,7 @@ do_copy_boot_files() {
cp -f "$dtb" "${DEPLOYDIR}/"
done
}
-addtask copy_boot_files before do_rootfs_postprocess after do_rootfs_install
+addtask copy_boot_files before do_image_tools after do_rootfs

python do_copy_boot_files_setscene () {
sstate_setscene(d)
--
2.39.2

[Felix Moessbauer]

This patch solves major performance issues around the initramfs
creation by ensuring that the initrd is only created once. This is
implemented by stubbing the update-initramfs call during the package
installing. After all apt operations are completed, we manually
trigger the initrd creation. In case a custom initramfs is used, the
creation is completely skipped in the image rootfs, as this would
anyways not be used.

Before that, each package install that made a initrd relevant change
triggered the update of the initrd. As we have multiple apt calls during
the build, this step was sometimes executed multiple times. In addition,
the apt install step is emulated, further slowing down the initrd
generation. On some layers on non native architecutes, this summed up to
over 10 minutes of initrd generation time.

Signed-off-by: Felix Moessbauer <felix.mo...@siemens.com>
---

meta/classes/image.bbclass | 4 +++
meta/classes/rootfs.bbclass | 32 +++++++++++++++++++
.../isar-bootstrap/isar-bootstrap.inc | 2 ++
3 files changed, 38 insertions(+)

diff --git a/meta/classes/image.bbclass b/meta/classes/image.bbclass
index 0dea06fa..b6763d73 100644
--- a/meta/classes/image.bbclass
+++ b/meta/classes/image.bbclass
@@ -67,6 +67,8 @@ inherit essential

ROOTFSDIR = "${IMAGE_ROOTFS}"
ROOTFS_FEATURES += "clean-package-cache clean-pycache generate-manifest export-dpkg-status clean-log-files clean-debconf-cache"
+# when using a custom initrd, do not generate one as part of the image rootfs
+ROOTFS_FEATURES += "${@ '' if d.getVar('INITRD_IMAGE') == '' else 'no-generate-initrd'}"
ROOTFS_PACKAGES += "${IMAGE_PREINSTALL} ${@isar_multiarch_packages('IMAGE_INSTALL', d)}"
ROOTFS_MANIFEST_DEPLOY_DIR ?= "${DEPLOY_DIR_IMAGE}"
ROOTFS_DPKGSTATUS_DEPLOY_DIR ?= "${DEPLOY_DIR_IMAGE}"
@@ -458,6 +460,8 @@ do_rootfs_quality_check() {
args="${ROOTFS_QA_FIND_ARGS}"
# rootfs_finalize chroot-setup.sh
args="${args} ! -path ${ROOTFSDIR}/var/lib/dpkg/diversions"
+ # initramfs is generated outside of the image rootfs
+ args="${args} ! -path ${ROOTFSDIR}/boot/initrd.img*"
for cmd in ${ROOTFS_POSTPROCESS_COMMAND}; do
case "${cmd}" in
image_postprocess_mark)
diff --git a/meta/classes/rootfs.bbclass b/meta/classes/rootfs.bbclass
index f0abd795..5c7a4c9a 100644
--- a/meta/classes/rootfs.bbclass
+++ b/meta/classes/rootfs.bbclass
@@ -14,6 +14,7 @@ ROOTFS_BASE_DISTRO ?= "${BASE_DISTRO}"
# 'generate-manifest' - generate a package manifest of the rootfs into ${ROOTFS_MANIFEST_DEPLOY_DIR}
# 'export-dpkg-status' - exports /var/lib/dpkg/status file to ${ROOTFS_DPKGSTATUS_DEPLOY_DIR}
# 'clean-log-files' - delete log files that are not owned by packages
+# 'no-generate-initrd' - do not generate debian default initrd
ROOTFS_FEATURES ?= ""

ROOTFS_APT_ARGS="install --yes -o Debug::pkgProblemResolver=yes"
@@ -127,6 +128,16 @@ rootfs_configure_apt() {
EOSUDO
}

+ROOTFS_CONFIGURE_COMMAND += "rootfs_disable_initrd_generation"
+rootfs_disable_initrd_generation[weight] = "1"
+rootfs_disable_initrd_generation() {
+ # fully disable initrd generation
+ echo "replace update-initramfs with stub"
+ sudo mv "${ROOTFSDIR}/usr/sbin/update-initramfs" \
+ "${ROOTFSDIR}/usr/sbin/update-initramfs.isar"
+ sudo chroot "${ROOTFSDIR}" ln -s "/usr/bin/true" "/usr/sbin/update-initramfs"
+}
+

ROOTFS_INSTALL_COMMAND += "rootfs_install_pkgs_update"
rootfs_install_pkgs_update[weight] = "5"
@@ -331,6 +342,27 @@ rootfs_cleanup_base_apt() {
EOSUDO
}

+ROOTFS_POSTPROCESS_COMMAND += "rootfs_restore_initrd_tooling"
+rootfs_restore_initrd_tooling[weight] = "1"
+rootfs_restore_initrd_tooling() {
+ if [ -e "${ROOTFSDIR}/usr/sbin/update-initramfs.isar" ]; then
+ sudo mv -f "${ROOTFSDIR}/usr/sbin/update-initramfs.isar" \
+ "${ROOTFSDIR}/usr/sbin/update-initramfs"
+ fi
+}
+
+ROOTFS_POSTPROCESS_COMMAND += "${@bb.utils.contains('ROOTFS_FEATURES', 'no-generate-initrd', '', 'rootfs_generate_initrd', d)}"
+rootfs_generate_initrd[weight] = "10"
+rootfs_generate_initrd() {
+ if [ -n "$(sudo find '${ROOTFSDIR}/boot' -type f -name 'vmlinu[xz]*')" ]; then
+ sudo -E chroot "${ROOTFSDIR}" sh -c '\
+ export kernel_version=$(basename /boot/vmlinu[xz]* | cut -d'-' -f2-); \
+ update-initramfs -u -v -k "$kernel_version";'
+ else
+ echo "no kernel in this rootfs, do not generate initrd"
+ fi
+}
+
do_rootfs_postprocess[vardeps] = "${ROOTFS_POSTPROCESS_COMMAND}"
do_rootfs_postprocess[network] = "${TASK_USE_SUDO}"
python do_rootfs_postprocess() {
diff --git a/meta/recipes-core/isar-bootstrap/isar-bootstrap.inc b/meta/recipes-core/isar-bootstrap/isar-bootstrap.inc
index 12f32ff0..e85c2894 100644
--- a/meta/recipes-core/isar-bootstrap/isar-bootstrap.inc
+++ b/meta/recipes-core/isar-bootstrap/isar-bootstrap.inc
@@ -28,6 +28,8 @@ DISTRO_BOOTSTRAP_KEYS ?= ""
THIRD_PARTY_APT_KEYS ?= ""
DEPLOY_ISAR_BOOTSTRAP ?= ""
DISTRO_BOOTSTRAP_BASE_PACKAGES = "locales"
+# install early, so we can stub the update-initramfs script before rootfs install
+DISTRO_BOOTSTRAP_BASE_PACKAGES:append = ",initramfs-tools"
DISTRO_BOOTSTRAP_BASE_PACKAGES:append:gnupg = ",gnupg"
DISTRO_BOOTSTRAP_BASE_PACKAGES:append:https-support = ",ca-certificates"
DISTRO_VARS_PREFIX ?= "${@'HOST_' if bb.utils.to_boolean(d.getVar('BOOTSTRAP_FOR_HOST')) else ''}"
--
2.39.2

[Jan Kiszka]

On 17.09.24 11:15, Felix Moessbauer wrote:
> This patch solves major performance issues around the initramfs
> creation by ensuring that the initrd is only created once. This is
> implemented by stubbing the update-initramfs call during the package
> installing. After all apt operations are completed, we manually
> trigger the initrd creation. In case a custom initramfs is used, the
> creation is completely skipped in the image rootfs, as this would
> anyways not be used.
>
> Before that, each package install that made a initrd relevant change
> triggered the update of the initrd. As we have multiple apt calls during

Anything else but
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1079509 (which is an
optimization) would be bugs and no good reason for this workaround.

Jan

Siemens AG, Technology
Linux Expert Center

[MOESSBAUER, Felix]

On Tue, 2024-09-17 at 14:26 +0200, Jan Kiszka wrote:
> On 17.09.24 11:15, Felix Moessbauer wrote:
> > This patch solves major performance issues around the initramfs
> > creation by ensuring that the initrd is only created once. This is
> > implemented by stubbing the update-initramfs call during the
> > package
> > installing. After all apt operations are completed, we manually
> > trigger the initrd creation. In case a custom initramfs is used,
> > the
> > creation is completely skipped in the image rootfs, as this would
> > anyways not be used.
> >
> > Before that, each package install that made a initrd relevant
> > change
> > triggered the update of the initrd. As we have multiple apt calls
> > during
>
> Anything else but
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1079509 (which is
> an
> optimization) would be bugs and no good reason for this workaround.

Hmm... I tend to disagree. The Debian patch definitely improves the
situation, however:

1. it is unlikely that this will get backported
2. It still provides no mechanism to completely disable the initrd
generation

But maybe we could approach the problem differently:

Reg. 1: Provide a local build of that package, as already mentioned on
the ML

Reg. 2: Tricky, as the kernel needs to be installed into the rootfs as
well to get the modules.

Felix

[Uladzimir Bely]

On Tue, 2024-09-17 at 11:15 +0200, 'Felix Moessbauer' via isar-users
wrote:

Hello.

This fails in CI (at least with focal/arm64 target with

DEBUG: Executing shell function do_rootfs_quality_check
find: paths must precede expression: `<path_to>/build/tmp/work/ubuntu-
focal-arm64/isar-image-base-qemuarm64/1.0-
r0/rootfs/boot/initrd.img.old'
WARNING: exit code 1 from a shell command.

--
Best regards,
Uladzimir.

[MOESSBAUER, Felix]

On Tue, 2024-09-17 at 14:26 +0200, Jan Kiszka wrote:

> On 17.09.24 11:15, Felix Moessbauer wrote:
> > This patch solves major performance issues around the initramfs
> > creation by ensuring that the initrd is only created once. This is
> > implemented by stubbing the update-initramfs call during the
> > package
> > installing. After all apt operations are completed, we manually
> > trigger the initrd creation. In case a custom initramfs is used,
> > the
> > creation is completely skipped in the image rootfs, as this would
> > anyways not be used.
> >
> > Before that, each package install that made a initrd relevant
> > change
> > triggered the update of the initrd. As we have multiple apt calls
> > during
>
> Anything else but
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1079509 (which is
> an
> optimization) would be bugs and no good reason for this workaround.

This "bug" just became a known-limitation as the corresponding fix was
rejected. IMHO we really need a solution to this rebuilding of the
initrd, as this adds +15mins build time on the RPi4 target with a
distro kernel. In case a dedicated initrd is used, another 10mins are
added on top.

I have a rebase of this series running locally for some time which
reliably works. But it probably does not solve the reported CI issue.

Felix

Linux Expert Center
Friedrich-Ludwig-Bauer-Str. 3
85748 Garching, Germany