eatmydata is not being used in the build chroot
We're using eatmydata to speed up the build a bit. However, it's not actually used for most of the build, since:
- we currently install eamydata via the first huge
apt-get installrun, so this one is not covered by eatmydata, which is too bad since it's likely the biggest generator of disk writes;
Chrootfunction cleans the environment and only passes through a few environment variables to the commands it runs. We need to make it forward
LD_PRELOAD. And while we're at it, we can as well forward
FAKETIME, which will help when working on #5630.
Install eatmydata via debootstrap.
This ensures that the first (and biggest) `apt-get install' run is actually run
with eatmydata available and enabled.
#2 Updated by intrigeri over 4 years ago
- Status changed from Confirmed to In Progress
- % Done changed from 0 to 20
- Feature Branch set to live-build:tails/debian-old-2.0+faketime
The patch has been written and tested. Next step is to update the Debian package and make it so everyone uses the new one when building ISO images.
#3 Updated by intrigeri over 4 years ago
- % Done changed from 20 to 30
Package updated, but the suite it was uploaded to (
bugfix-9419-eatmydata-in-build-chroot) only supports i386. That's an arch:all package anyway, so one can test it by manually installing (with dpkg) the .deb on their builder VM, even if it's most likely an amd64 one.
#8 Updated by anonym over 4 years ago
- Assignee deleted (
- QA Check changed from Ready for QA to Pass
All instances of
ERROR: ld.so: object '/usr/lib/libeatmydata/libeatmydata.so' from LD_PRELOAD cannot be preloaded: ignored.
have disappeared, which is nice. OTOH my builds aren't much faster:
Without this fix:
real 17m41.917s user 21m23.228s sys 4m25.841s
With this fix:
real 17m26.058s user 20m22.752s sys 4m15.108s
(I did take into account all manners of caching when doing this "benchmark".)
Not a huge gain. Any way, the big thing is how this will help #5630.