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 > <[email protected]> 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
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#229220): https://lists.openembedded.org/g/openembedded-core/message/229220 Mute This Topic: https://lists.openembedded.org/mt/117020092/21656 Group Owner: [email protected] Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [[email protected]] -=-=-=-=-=-=-=-=-=-=-=-
