Arch Linux

Please read this before reporting a bug:
https://wiki.archlinux.org/title/Bug_reporting_guidelines

Do NOT report bugs when a package is just outdated, or it is in the AUR. Use the 'flag out of date' link on the package page, or the Mailing List.

REPEAT: Do NOT report bugs for outdated packages!
Tasklist

FS#56896 - {mkinitcpio} don't overwrite .img file on identical (extracted) contents

Attached to Project: Arch Linux
Opened by Ceriel Jacobs (cj1) - Friday, 29 December 2017, 17:16 GMT
Last edited by Dave Reisner (falconindy) - Sunday, 31 December 2017, 17:50 GMT
Task Type Feature Request
Category Arch Projects
Status Closed
Assigned To No-one
Architecture All
Severity Low
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 0
Private No

Details

Description:
Despite that identical input results in different output files (due to cpio inode differences), even then mkinitcpio better not overwrite existing initramfs files when the /rootfs/ structures contain identical files.

Additional info:
* mkinitcpio 24

Benefits:
- saves flash lifetime a little
- makes it simpler for humans to detect (real) changes to the initramfs files by comparing `ls` date/timestamps
- less i/o and storage for backups needed


Idea:
For the time being (cpio input output not identical on each run):
1. create .img at /tmp/A,
2. before overwrite extract initramfs-linux.img to /tmp/B,
3. diff /tmp/A/ /tmp/B/,
4. only on differences detected by diff overwrite /boot/{...initramfs-linux...}.img
This task depends upon

Closed by  Dave Reisner (falconindy)
Sunday, 31 December 2017, 17:50 GMT
Reason for closing:  Won't implement
Additional comments about closing:  Too much risk, too little reward.
Comment by Dave Reisner (falconindy) - Friday, 29 December 2017, 20:05 GMT
Why are your initramfs images being regenerated when there are no substantive changes?
Comment by Dave Reisner (falconindy) - Friday, 29 December 2017, 20:31 GMT
This is extremely difficult -- one must consider:

1) The kernel the image is being built for
2) Changes to the config file the image was built with
3) Output from each of the hooks used to build the image

Consider that due to use of tools/functionality which act recursively on the filesystem or external tools which depend on indexes maintained outside of mkinitcpio (depmod/modprobe/modinfo), external changes which are essentially undetectable can impact the resulting contents of the initramfs.

The cost (and risk) of getting this wrong is high, as it might result in an unbootable system. I don't see a compelling reason to do this given the difficulty and risk.
Comment by Doug Newgard (Scimmia) - Saturday, 30 December 2017, 05:49 GMT
I think the initial question is the most important here, why the images being regenerated? Without knowing that, it's hard to determine if this is something that's necessary.
Comment by Dave Reisner (falconindy) - Sunday, 31 December 2017, 17:50 GMT
Well, that's not so far fetched. One could imagine that you have lvm2 or cryptsetup installed and used for something other than the root device. Any time these packages are updated, your initramfsen are rebuilt. I've thought about this before, and concluded that you'd basically need to rebuild the entire cpio image in order to safely determine that it's identical to what you already have in place. Since the building tends to take place in tmpfs, the only write to real disk is a single sequential write per image.

I'd take some well-reasoned patches for this, but the amount of work involved and high level of risk in getting it wrong compared to the tradeoff seems entirely off-balance in the wrong direction.

Loading...