[rb-general] How to modify mount-time and write when you write in a file system

Andres Pavez apavez.zavala at gmail.com
Wed Jul 12 23:04:29 CEST 2017

Andrés Pavez

On Wed, Jul 12, 2017 at 1:26 PM, Ximin Luo <infinity0 at debian.org> wrote:
> Andres Pavez:
>> --
>> Andrés Pavez
>> On Wed, Jul 12, 2017 at 3:39 AM, Ximin Luo <infinity0 at debian.org> wrote:
>>> Daniel Shahaf:
>>>> Andres Pavez wrote on Tue, 11 Jul 2017 16:36 -0700:
>>>>> Problem: during the creation/reproduction of the custom live cd, when
>>>>> i use "mount' to mount the filesystem to copy my sw inside of the
>>>>> rootfs (after unsquashfs) i noted usign tune2fs every time i mont the
>>>>> file system the values "last mount time", "last write time" and
>>>>> "Lifetime writes" changes and i don't know how to fix it.
>>>>> With tune2fs i can only  fix the "Mount Count", but no the mount time
>>>>> and writes.
>>>> Perhaps, instead of backdating the metadata, teach diffoscope to parse
>>>> the metadata, so diffoscope's output would pretty-print the metadata
>>>> diff?  If it's just those three values that differ, presumably that wouldn't
>>>> make the output much harder to audit for your downstream users.
>>> This approach, of adding exceptions to diffoscope and still calling the result "reproducible", isn't scalable (what if you need to put the result inside more containers?) So I wouldn't recommend this.
>>> @Andres: Have you tried `mount -o ro` to mount read-only? `man mount` also suggests some other options, in case that doesn't work:
>>> -r, --read-only
>>> Mount the filesystem read-only.  A synonym is -o ro.
>>> Note that, depending on the filesystem type, state and kernel behavior, the
>>> system may still write to the device.  For example, ext3 and ext4 will replay
>>> the journal if the filesystem is dirty.  To prevent this kind of write access,
>>> you may want to mount an ext3 or ext4 filesystem with the ro,noload mount
>>> options or set the block device itself to read-only mode, see the blockdev(8)
>>> command.
>> Hi Ximin,
>> Thanks for your comment. But i need to copy my sw inside of the ext4
>> file system, so read only doesn't work.
>> [..]
> You are extracting a squashfs container to a ext4 FS, adding extra files to it, and then expecting the ext4 block device to be reproducible when you do this twice?
> Am I correct? If not, can you explain in more detail what you are actually doing?

Yes, you are correct.

> Assuming I am correct, I don't think anyone has tried getting ext4 to work reproducibly after doing normal filesystem operations on it. It would be nice but nobody has looked into this unfortunately. I believe that squashfs "almost" works reproducibly, see https://labs.riseup.net/code/issues/12032 but they have a few remaining issues, perhaps the TAILS folks can elaborate here. That is, you can try it with squashfs instead of ext4 and see what happens.

I have been using the developer version of squashfs (github) and it
works if you have the same file system. The problem is reproduce
deterministic the file system, when you add a file into the file

Thanks for your comments.

> X
> --
> GPG: ed25519/56034877E1F87C35
> GPG: rsa4096/1318EFAC5FBBDBCE
> https://github.com/infinity0/pubkeys.git
> _______________________________________________
> rb-general at lists.reproducible-builds.org mailing list
> To change your subscription options, visit https://lists.reproducible-builds.org/listinfo/rb-general.
> To unsubscribe, send an email to rb-general-unsubscribe at lists.reproducible-builds.org.

More information about the rb-general mailing list