After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 696283 - initramfs vs content-addressed-storage
initramfs vs content-addressed-storage
Status: RESOLVED WONTFIX
Product: ostree
Classification: Infrastructure
Component: general
unspecified
Other Linux
: Normal normal
: ---
Assigned To: OSTree maintainer(s)
OSTree maintainer(s)
Depends on:
Blocks:
 
 
Reported: 2013-03-21 12:53 UTC by Colin Walters
Modified: 2018-08-17 19:00 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
use gzip -n (1.02 KB, patch)
2013-03-21 12:53 UTC, Colin Walters
needs-work Details | Review
avoid mtime (1.15 KB, patch)
2013-03-21 12:54 UTC, Colin Walters
needs-work Details | Review
darcut no mtime rebased (1.08 KB, patch)
2015-08-13 14:52 UTC, Giuseppe Scrivano
none Details | Review

Description Colin Walters 2013-03-21 12:53:26 UTC
There are at present at least 3 things causing each initramfs generated to differ every time it's built.  We should also address this by not rebuilding it every time of course, but this bug is about the cases were we do.

1) The gzip timestamp header; just needs a simple dracut patch.
2) The cpio format contains the timestamps of the source files; also fixed by the
   below dracut patch.
3) The cpio format writes out the inodes of the files it finds.  This is harder
   to fix than I thought because it uses the inode numbers for hardlinking.
   We'd need to patch cpio itself to have a hash table of inode -> serial
   where serial is an internal counter.
Comment 1 Colin Walters 2013-03-21 12:53:52 UTC
Created attachment 239465 [details] [review]
use gzip -n
Comment 2 Colin Walters 2013-03-21 12:54:13 UTC
Created attachment 239466 [details] [review]
avoid mtime
Comment 3 Colin Walters 2013-03-21 12:54:28 UTC
So what we still need is a patch for #3.
Comment 4 Colin Walters 2013-08-19 16:51:34 UTC
This was semi-addressed by manually adding components which force an initramfs rebuild.  But that has many downsides:

1) Manual initramfs-depends list
2) Updating a TODO entry in ostree forces a new initramfs
3) When the initramfs contents actually do change, we'd like to still not have 
   cascading differences in the file, since this hampers static deltas.
Comment 5 Colin Walters 2015-08-13 14:03:26 UTC
See also https://bugzilla.redhat.com/show_bug.cgi?id=1098457
Comment 6 Colin Walters 2015-08-13 14:05:05 UTC
One thing that if the initramfs *does* change, we could delta it better if we used gzip --rsyncable.  http://blog.liw.fi/posts/zsync-deb-updates/ has some links, I'm not sure if there's a canonical reference.
Comment 7 Giuseppe Scrivano 2015-08-13 14:52:44 UTC
Created attachment 309210 [details] [review]
darcut no mtime rebased
Comment 8 Giuseppe Scrivano 2015-08-13 14:53:18 UTC
I rebased the Dracut patch.  It performs very well with rollsums.
Comment 9 Giuseppe Scrivano 2015-08-18 11:51:12 UTC
I previously didn't manage to get good results with --reproducible as the cpio available on Fedora doesn't support --reproducible (supported added by an upstream patch).
I have filed a bug here for the backport:

https://bugzilla.redhat.com/show_bug.cgi?id=1254537

and a small patch for rpm-ostree:

https://github.com/projectatomic/rpm-ostree/pull/166
Comment 10 André Klapper 2018-08-17 19:00:10 UTC
OSTree has moved to Github a while ago.
Furthermore, GNOME Bugzilla will be shut down and replaced by gitlab.gnome.org.

If the problem reported in this Bugzilla ticket is still valid, please report it to https://github.com/ostreedev/ostree/issues instead. Thank you!

Closing this report as WONTFIX as part of Bugzilla Housekeeping.