image_types.bbclass: make fsck optional

The fsck in oe_mkext234fs() was added to prevent an extra reboot on the
target:

https://git.openembedded.org/openembedded-core/commit/?id=a93d0059341

This has the side effect of increasing delta between images which
prevents reproducibility. In many cases, the added security provided by
image reproducibility is worth the extra reboot upon first booting the
target. The use of fsck should be included by default, but left
configurable.

[YOCTO #16110]

Signed-off-by: Levi Shafter <levi.shafter@elder-tomes.com>
---
Sponsor: 21SoftWare LLC

 meta/classes-recipe/image_types.bbclass | 10 ++++++++--
 1 file changed, 8 insertions(+), 2 deletions(-)

+	fi
 }

 IMAGE_CMD:ext2 = "oe_mkext234fs ext2 ${EXTRA_IMAGECMD}"

On 31 Dec 2025, at 22:52, Levi Shafter via lists.openembedded.org <levi.shafter=elder-tomes.com@lists.openembedded.org> wrote:
> 
> The fsck in oe_mkext234fs() was added to prevent an extra reboot on the
> target:
> 
> https://git.openembedded.org/openembedded-core/commit/?id=a93d0059341
> 
> This has the side effect of increasing delta between images which
> prevents reproducibility. In many cases, the added security provided by
> image reproducibility is worth the extra reboot upon first booting the
> target. The use of fsck should be included by default, but left
> configurable.
> 
> [YOCTO #16110]

There’s slightly more information in the bug report than here, which links to a video from YPS 2024.12 talking about how fsck will modify timestamps in file systems, so whilst the initial ext4 from mkfs is reproducible, we do a fsck to clear flags and they’re no longer bit-identical.  Is this the only source of non-determinism that you’re observing?

I don’t think adding an option is the right thing here as you’re swapping one problem (non-reproducible ext4) with another (filesystem dirty, needs a reboot).  As the video shows, we should be passing timestamp information at construction time to avoid this problem. Would you be able to work on a patch to do that instead?

Thanks,
Ross

Hi Ross,

I really appreciate the feedback! I agree that passing timestamp
information is the proper solution here. I'll create a new patch that
does this.

Be well,
- Levi

On 1/9/26 10:03, Ross Burton wrote:
> On 31 Dec 2025, at 22:52, Levi Shafter via lists.openembedded.org <levi.shafter=elder-tomes.com@lists.openembedded.org> wrote:
>>
>> The fsck in oe_mkext234fs() was added to prevent an extra reboot on the
>> target:
>>
>> https://git.openembedded.org/openembedded-core/commit/?id=a93d0059341
>>
>> This has the side effect of increasing delta between images which
>> prevents reproducibility. In many cases, the added security provided by
>> image reproducibility is worth the extra reboot upon first booting the
>> target. The use of fsck should be included by default, but left
>> configurable.
>>
>> [YOCTO #16110]
> 
> There’s slightly more information in the bug report than here, which links to a video from YPS 2024.12 talking about how fsck will modify timestamps in file systems, so whilst the initial ext4 from mkfs is reproducible, we do a fsck to clear flags and they’re no longer bit-identical.  Is this the only source of non-determinism that you’re observing?
> 
> I don’t think adding an option is the right thing here as you’re swapping one problem (non-reproducible ext4) with another (filesystem dirty, needs a reboot).  As the video shows, we should be passing timestamp information at construction time to avoid this problem. Would you be able to work on a patch to do that instead?
> 
> Thanks,
> Ross

Hi again Ross,

After doing some more testing after eliminating image delta caused by
differing timestamps, etc. (detailed in the bug report) as well as
reviewing the YPS 2024.12 video, it seems there is further
non-determinism caused by the fsck command.

While it may be possible to eliminate the delta caused by running the
fsck command while also being able to keep it, to my knowledge, nobody
has been able to document this thus far. It could be a time-consuming
process. While the video you mentioned suggests completely removing the
use of fsck, I would argue this patch represents an improvement which
retains the default for those who have a use case which favors avoiding
a reboot on the target while also providing an option for those who
would prioritize reproducibility.

Let me know if you might have some ideas for retaining reproducible
builds while keeping the fsck. I'm unsure why additional delta is
observed beyond timestamps data, and I'd love to investigate further,
but I'm not sure it's something I can dive deeper into at this time.



On 1/9/26 10:03, Ross Burton wrote:
> On 31 Dec 2025, at 22:52, Levi Shafter via lists.openembedded.org <levi.shafter=elder-tomes.com@lists.openembedded.org> wrote:
>>
>> The fsck in oe_mkext234fs() was added to prevent an extra reboot on the
>> target:
>>
>> https://git.openembedded.org/openembedded-core/commit/?id=a93d0059341
>>
>> This has the side effect of increasing delta between images which
>> prevents reproducibility. In many cases, the added security provided by
>> image reproducibility is worth the extra reboot upon first booting the
>> target. The use of fsck should be included by default, but left
>> configurable.
>>
>> [YOCTO #16110]
> 
> There’s slightly more information in the bug report than here, which links to a video from YPS 2024.12 talking about how fsck will modify timestamps in file systems, so whilst the initial ext4 from mkfs is reproducible, we do a fsck to clear flags and they’re no longer bit-identical.  Is this the only source of non-determinism that you’re observing?
> 
> I don’t think adding an option is the right thing here as you’re swapping one problem (non-reproducible ext4) with another (filesystem dirty, needs a reboot).  As the video shows, we should be passing timestamp information at construction time to avoid this problem. Would you be able to work on a patch to do that instead?
> 
> Thanks,
> Ross