[PATCH 1/1] enable-fsck: don't run update-initramfs after fstab modification

[Uladzimir Bely]

On first machine run, if enable-fsck recipe was enabled, it takes
much time to start because of spending too much time on
the 'update-initramfs -u' call.

Removing it while it really does nothing useful.

Signed-off-by: Uladzimir Bely <ub...@ilbers.de>
---
meta/recipes-support/enable-fsck/files/enable-fsck.sh | 2 --
1 file changed, 2 deletions(-)

diff --git a/meta/recipes-support/enable-fsck/files/enable-fsck.sh b/meta/recipes-support/enable-fsck/files/enable-fsck.sh
index d09e35df..72d6bd78 100644
--- a/meta/recipes-support/enable-fsck/files/enable-fsck.sh
+++ b/meta/recipes-support/enable-fsck/files/enable-fsck.sh
@@ -12,5 +12,3 @@ set -e
ROOT_DEV="$(/bin/findmnt -n -o SOURCE /)"
sed -i -e 's|^/dev/root\([ ]\+.*[ ]\+\)0[ ]\+0|'"$ROOT_DEV"'\10 1|' \
-e 's|^\(/dev/.*[ ]\+\)0[ ]\+0|\10 2|' /etc/fstab
-
-update-initramfs -u
--
2.20.1

[Uladzimir Bely]

The enable-fsck recipe installs into the system the script that sets
'fs_passno' fields for the partitions in fstab. After that, it calls
'update-initramfs -u' that takes several minutes to run.

In CI this sometimes causes fails with 'run_vm' tests while there is
no proper command prompt after expected timeout, especially if CI
server is highly loaded.

Actually, there were several targets checked. All of them had empty
fstab in their generated initramfs images. So, 'update-initramfs -u'
just takes much time but doesn't really change anything and may be
omitted.

Anyway, something could be overlooked during investigations, so if we
really need initramfs update at first run, it would be nice to know
exactly why.

Uladzimir Bely (1):
enable-fsck: don't run update-initramfs after fstab modification

meta/recipes-support/enable-fsck/files/enable-fsck.sh | 2 --
1 file changed, 2 deletions(-)

--
2.20.1

[Jan Kiszka]

On 21.01.22 08:42, Uladzimir Bely wrote:
> The enable-fsck recipe installs into the system the script that sets
> 'fs_passno' fields for the partitions in fstab. After that, it calls
> 'update-initramfs -u' that takes several minutes to run.
>
> In CI this sometimes causes fails with 'run_vm' tests while there is
> no proper command prompt after expected timeout, especially if CI
> server is highly loaded.
>
> Actually, there were several targets checked. All of them had empty
> fstab in their generated initramfs images. So, 'update-initramfs -u'
> just takes much time but doesn't really change anything and may be
> omitted.
>
> Anyway, something could be overlooked during investigations, so if we
> really need initramfs update at first run, it would be nice to know
> exactly why.
>

I don't recall details about this anymore. I would just recommend to
check if there are any differences in buster vs. newer versions. Stretch
is no longer supported, but I think it was the target back then, and
maybe that did something different /wrt the initramfs.

Jan

--
Siemens AG, Technology
Competence Center Embedded Linux

[Anton Mikanovich]

Applied to next, thanks.

[Jan Kiszka]

On 21.01.22 08:42, Uladzimir Bely wrote:

This was wrong, unfortunately: The original purpose of this whole recipe
is to generate an initramfs that contains all tools needed to perform
early filesystem checks. As this information is not available at the
time we build the rootfs, only after wic ran, I once decided achieve the
desired effect by recreating the initramfs on first boot.

If anyone has a better idea how to model that more elegantly, I'm all
ears. Otherwise, we need to revert this and address the boot time issue
by reducing the number of targets where it is run.

Jan

--
Siemens AG, Foundational Technologies
Linux Expert Center