[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

[Baurzhan Ismagulov]

On 2025-09-05 17:06, 'Jan Kiszka' via isar-users 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.

We'll check.

With kind regards,
Baurzhan

[Uladzimir Bely]

Hello.

It seems that "enable-fsck" doesn't look like some mandatory for Isar
itself, that's why the patch was applied earlier.

First, the script tries to modify "/dev/root..." line that none of
meta-isar's targets have at all. This probably works only with
downstreams that use `cip-core` with `readonly-roofs.bbclass` or in
some other (which?) cases with "/dev/root..." in fstab.

Second, other "/dev/..." lines in fstab are also uncommon for meta-
isar's targets that are quite simple (e.g., have only rootfs or at most
boot/rootfs).

Third, real benefit from enable-fsck seems to become visible only after
some hardware crashes that require filesystem reparing.


I tried to revert the patch and this brought the following issues
again:

- qemuarm/qemuarmhf machines (at least) take more than 10 minutes to
start when run on quite decent CI server. Default value for
DEF_VM_TO_SEC value in testsuite should be increased to avoid "timeout"
failures.
- generating new initrd on first run requires additional space on
rootfs, otherwise some targets fail. Changes in some WKS files (adding
extra space for root partition) are required.

When both issues are solved, CI seems to pass.

So, if having "update-initramfs" is mandatory for downstreams, we can
propose the following patchset as a solution:

- original patch revered
- increased CI timeout
- extra space added to .WKS/.conf used by failing qemu targets.

If OK, the patchset will be sent after testing in CI.

--
Best regards,
Uladzimir.

[Jan Kiszka]

Don't test it on emulated platforms - does not add much value.

> - generating new initrd on first run requires additional space on
> rootfs, otherwise some targets fail. Changes in some WKS files (adding
> extra space for root partition) are required.
>

Pick few native targets and ensure that they have enough space.

> When both issues are solved, CI seems to pass.
>
> So, if having "update-initramfs" is mandatory for downstreams, we can
> propose the following patchset as a solution:
>
> - original patch revered
> - increased CI timeout
> - extra space added to .WKS/.conf used by failing qemu targets.
>
> If OK, the patchset will be sent after testing in CI.
>

I'm still open to a suggestion which resolves the underlying issue: Make
sure that fsck is run for writable rootfs, but that already during
offline [initrd] image generation.