Bug #16452

Consider dropping call to update-initramfs in config/chroot_local-hooks/99-initramfs-compress

Added by intrigeri 2019-02-09 08:28:53 . Updated 2019-03-20 14:26:30 .

Status:
Resolved
Priority:
Normal
Assignee:
Category:
Target version:
Tails_3.13
Start date:
2019-02-09
Due date:
% Done:

100%

Feature Branch:
bugfix/16452-remove-useless-extra-initramfs-update
Type of work:
Code
Blueprint:

Starter:
Affected tool:
Deliverable for:

Description

If I read this correctly:

08:18:36 Configuring compression of the initramfs
08:18:36 update-initramfs: Generating /boot/initrd.img-4.19.0-2-amd64
08:18:41 cryptsetup: WARNING: could not determine root device from /etc/fstab
08:18:45 live-boot: core filesystems devices utils memdisk udev wget blockdev dns.
08:20:33 Setting correct file permissions
08:20:33 Removing *.pyc
08:20:33 Setting mtime on large files whose content generally do not change
08:20:33 Checking for .orig files
08:20:34 Checking UIDs and GIDs stability
08:20:34 Truncating log files
08:20:34 Post processing filesystem to make it reproducible
08:20:34 P: Begin executing hooks...
08:20:34 P: Begin executing hacks...
08:20:34 update-initramfs: Generating /boot/initrd.img-4.19.0-2-amd64
08:20:39 cryptsetup: WARNING: could not determine root device from /etc/fstab
08:20:44 live-boot: core filesystems devices utils memdisk udev wget blockdev dns.
08:22:38 P: Begin ensuring chroot contents are reproducible...

… we force an initramfs update ourselves, to apply our compression settings, and this takes ~2 minutes. But then live-build does the same again, which takes ~2 minutes as well.

So it looks like we could remove the update-initramfs -u call from our own hook and save 2 minutes on the build time, i.e. ~3%, which is pretty good for a one line change :)

Bonus points if, to avoid future regressions in case we ever update to a version of live-build that does not update the initramfs anymore, we add a sanity check (probably in binary_local-hooks/) which verifies that the size of the resulting initramfs is within expected bounds.

Files

2019-03-15_08-48.png (36776 B) lamby, 2019-03-15 12:48:13

Subtasks

Related issues

Blocks Tails - Feature #15507: Core work 2019Q1: Foundations Team Resolved 2018-04-08

History

#1 Updated by intrigeri 2019-02-09 08:29:12

#2 Updated by intrigeri 2019-02-09 09:25:29

  • Subject changed from Consider dropping call to @update-initramfs@ in config/chroot_local-hooks/99-initramfs-compress to Consider dropping call to update-initramfs in config/chroot_local-hooks/99-initramfs-compress

#3 Updated by intrigeri 2019-03-13 08:23:24

  • Status changed from Confirmed to In Progress
  • % Done changed from 0 to 10
  • Feature Branch set to bugfix/16452-remove-useless-extra-initramfs-update

#4 Updated by intrigeri 2019-03-13 10:38:44

#5 Updated by intrigeri 2019-03-13 10:38:46

#6 Updated by intrigeri 2019-03-13 11:34:14

  • Assignee changed from intrigeri to lamby
  • Target version changed from Tails_3.14 to Tails_3.13
  • % Done changed from 10 to 50
  • QA Check set to Ready for QA

Builds fine and I’ve checked that the initramfs hasn’t grown (which confirms that live-build regenerates it). I observed 3-4% total build time decrease on my local Jenkins ⇒ as I suspected, that’s a pretty cheap improvement :) I did not bother benchmarking on our shared Jenkins because I’ve already analyzed above that the removed call took 2 minutes.

@lamby, would you like to review this, ideally by the end of the week so this makes it into 3.13? The changes are tiny (30 insertions — most of it being boilerplate — and 7 deletions).

#7 Updated by lamby 2019-03-15 03:29:46

Sure thing. :)

#8 Updated by lamby 2019-03-15 12:53:14

Methodology:

  • (I did not build this myself as my provisioning is currently broken for some reason.)
  • Noted new `P: checking the size of the initramfs` in build log as well as the now-removed manual initramfs compression.
  • Booted the ISO - boots fine (see attached screenshot)
  • Mounted the ISO on a loopback device and observed `live/initrd.img` is 31,543,032 bytes which not only LGTM and is comparable to an ISO built as part of Bug #16559 (31,543,032 bytes) so we are still applying xz compression.

#9 Updated by intrigeri 2019-03-15 13:20:54

  • Status changed from In Progress to Fix committed
  • % Done changed from 50 to 100

Applied in changeset commit:tails|87b44edbe8f9b49e28658bf6c37980267c2db076.

#10 Updated by intrigeri 2019-03-15 13:22:17

  • Assignee deleted (intrigeri)
  • QA Check changed from Ready for QA to Pass

#11 Updated by CyrilBrulebois 2019-03-20 14:26:30

  • Status changed from Fix committed to Resolved