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

["'Jan Kiszka' via isar-users" <isar-users@googlegroups.com>]

On 19.09.25 14:26, Uladzimir Bely wrote:
> On Fri, 2025-09-05 at 17:06 +0200, Jan Kiszka wrote:
>> On 21.01.22 08:42, Uladzimir Bely wrote:
>>> 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 <ubely@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
>>
>> 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
> 
> 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.

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.

Jan

-- 
Siemens AG, Foundational Technologies
Linux Expert Center

-- 
You received this message because you are subscribed to the Google Groups "isar-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to isar-users+unsubscribe@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/isar-users/8af63a90-dabc-496d-aad9-c2335b283f86%40siemens.com.