Hi Ross, I'd like to bump this patch and ask if you've had a chance to review my last message. Considering additional delta beyond differences in timestamp information is observed between builds, do you think a toggle that allows for a choice between problems represents an improvement until the path to full reproducibility with the fsck command becomes clear?
Thanks! - Levi On 1/12/26 14:06, Levi Shafter wrote: > 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 (#242810): https://lists.openembedded.org/g/openembedded-core/message/242810 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]] -=-=-=-=-=-=-=-=-=-=-=-
