P.S. Richard, you can easily check it on yours system. Just make a clean build of something with all the reproducible stuff set and inspect the resulting FS image.
Even with a very tiny core image (linux + bash + coreutils) there are several inodes with improper timestamps: $ /sbin/debugfs -f cmd ./platform.img 2>/dev/null |grep -e '^Inode:' -e 'mtime' |paste - - |grep 2022$ Inode: 1 Type: bad type Mode: 0000 Flags: 0x0 mtime: 0x6364f673 -- Fri Nov 4 14:24:35 2022 Inode: 2 Type: directory Mode: 0755 Flags: 0x80000 mtime: 0x6364f673:00000000 -- Fri Nov 4 14:24:35 2022 Inode: 7 Type: regular Mode: 0600 Flags: 0x0 mtime: 0x6364f673:00000000 -- Fri Nov 4 14:24:35 2022 Inode: 8 Type: regular Mode: 0600 Flags: 0x80000 mtime: 0x6364f673:00000000 -- Fri Nov 4 14:24:35 2022 Inode: 11 Type: directory Mode: 0700 Flags: 0x80000 mtime: 0x6364f673:00000000 -- Fri Nov 4 14:24:35 2022 Inode: 123 Type: regular Mode: 0664 Flags: 0x80000 mtime: 0x6364f677:00000000 -- Fri Nov 4 14:24:39 2022 cmd is just a command file of "stat <123>" lines from 1 to 20000. -- With best wishes, Sergei Zhmylev Engineering consultant OS development department On Fri, 2022-11-04 at 11:16 +0000, Sergey Zhmylev wrote: > On Thu, 2022-11-03 at 21:51 +0000, Richard Purdie wrote: > > > > On Thu, 2022-11-03 at 18:53 +0000, Sergey Zhmylev wrote: > > > Hi Richard, > > > > > > Thank you for the comment! > > > Well, the environment described in reproducible guides currently > > > does > > > not provide binary reproducability due to extfs implementation. > > > > Agreed, there is an issue here. I just don't think the patch looks > > quite right. > > > > > Moreover, building on some FS (for example mounted with noatime > > > or > > > not supporting crtime field at all like UFS) makes the extfs > > > creation > > > process totally not reproducible in spite of any modifications on > > > the > > > source files. > > > > You're arguing we need to set crtime, ctime and atime which I can > > believe. The mtime however should be fine from the package manager > > so > > I > > don't think this patch should be changing it. > > > > There may be a case for just setting the others to mtime instead of > > SDE > > too? > > Unfortunately, there is no other way to properly get mtime of the > files > in order to clone it into atime/ctime/crtime, than create a large > listing of the files and ask debugfs to print stat information, and > then parse the long output creating a debugfs script. > This process can lead to additional bugs and will take a time. > > > > > > I've checked the behaviour under multiple conditions, double > > > checking > > > that I've set as much reproducible stuff as possible, and it > > > comes > > > out that in certain circumstances rootfs files have incorrect > > > timestamps -- they're set to the build process time. > > > > Which timestamps though? Isn't mtime ok? > > mtime "mostly" looks ok, while the others were definitely bad. > There were several files, not only fstab before my previous patch, > but > also rpmdb.sqlite and some dnf-related stuff, and so on, on which > mtime > was set improperly anyways. > > According to https://reproducible-builds.org/docs/source-date- > epoch/ if > the user specified SDE, the "last modification of something" (aka > mtime) must be set to this value. > > Taking all the above into account, there is nothing bad in changing > all > the inodes timestamps: mtime (SDE requirement) and atime/ctime/crtime > (to overcome extfs building issues) to the same value -- specified by > the user. > > > > > > So I'm sure that if the user set SDE to a particular timestamp, > > > we > > > should also modify atime, ctime and crtime. > > > > > > P.S. overriding only the time later than SDE could have also been > > > an > > > option, but in reality we can not surely gather stat info for > > > each > > > file without debugfs or similar tools and this will tremendously > > > degradate performance of already pretty slow image creation > > > process. > > > Due to this I suggest the patch I've sent. > > > > That stat information should already be present? > > Right, but as I said, it's pretty tricky to obtain it for later use. > > > > > Cheers, > > > > Richard > > > > Thank you, Richard > > -- > With best wishes, > Sergei Zhmylev > Engineering consultant > OS development department > > > >
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#172709): https://lists.openembedded.org/g/openembedded-core/message/172709 Mute This Topic: https://lists.openembedded.org/mt/94758789/21656 Group Owner: [email protected] Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [[email protected]] -=-=-=-=-=-=-=-=-=-=-=-
