Bug #9523

Discrepancy between eatmydata versions breaks Jessie build

Added by intrigeri 2015-06-03 09:31:38 . Updated 2015-07-03 03:35:59 .

Status:
Resolved
Priority:
Elevated
Assignee:
Category:
Build system
Target version:
Tails_1.4.1
Start date:
2015-06-03
Due date:
% Done:

100%

Feature Branch:
bugfix/9523-eatmydata-v82-everywhere
Type of work:
Code
Blueprint:

Starter:
Affected tool:
Deliverable for:

Description

Since Bug #9419 was fixed, our build system uses eatmydata (for real, this time). However, a Wheezy builder now fails to build a Jessie ISO, and vice-versa, because Wheezy’s and Jessie’s eatmydata put their LD_PRELOAD’ed libraries in different places. The easiest fix seems to use eatmydata v82 on all kinds of builders, and inside all ISOs. This should be possible now that my backport of Jessie’s eatmydata reached wheezy-backports.

Subtasks

Related issues

Related to Tails - Bug #9419: eatmydata is not being used in the build chroot Resolved 2015-05-17
Blocks Tails - Bug #9262: Port our ISO build system to Jessie Resolved 2015-04-19

History

#1 Updated by intrigeri 2015-06-03 09:31:49

  • related to Bug #9419: eatmydata is not being used in the build chroot added

#2 Updated by intrigeri 2015-06-03 09:47:59

  • Status changed from Confirmed to In Progress

Applied in changeset commit:6043f17c6d8045a9d279175661a9d50c9a219332.

#3 Updated by intrigeri 2015-06-03 09:57:43

  • % Done changed from 0 to 10
  • Feature Branch set to bugfix/9523-eatmydata-v82-everywhere

I can’t test this now since the i386 backport hasn’t been installed into the archive yet: https://buildd.debian.org/status/package.php?p=libeatmydata&suite=wheezy-backports

#4 Updated by intrigeri 2015-06-09 15:57:17

  • % Done changed from 10 to 20

It has reached wheezy-backports, so I can now test this.

#5 Updated by intrigeri 2015-06-10 12:29:27

  • Assignee changed from intrigeri to anonym
  • % Done changed from 20 to 50
  • QA Check set to Ready for QA

#6 Updated by intrigeri 2015-06-10 12:29:47

  • blocks Bug #9262: Port our ISO build system to Jessie added

#7 Updated by anonym 2015-06-10 15:05:12

I merged it into stable and built an image. Then I carefully looked at the buildlog:

1. During debootstrap eatmydata 26-2 is installed as expected.
2. In the first apt-get install after debootstrap I get:

The following packages have been kept back:
  eatmydata


3. Lot’s of ERROR: ld.so spam.
4. But immediately after that version 82-6~bpo70+1 is installed. After that, the ERROR: ld.so spam stops.
5. …except for what I think are when some but not all post-install scripts are run, in particular those that sets up new users/groups. Examples:

Setting up exim4-config (4.80-7+deb7u1) ...
Adding system-user for exim (v4)
ERROR: ld.so: object 'libeatmydata.so' from LD_PRELOAD cannot be preloaded: ignor
ed.
[...]
Setting up tor (0.2.6.7-1~d70.wheezy+1+tails2) ...
ERROR: ld.so: object 'libeatmydata.so' from LD_PRELOAD cannot be preloaded: ignored.


6. Next afte this:

P: Begin executing hooks...
P: Begin executing hacks...
[...]
P: Begin copying chroot...
P: This may take a while.
P: Begin mounting /dev/pts...
P: Begin mounting /proc...
P: Begin mounting /sys...
P: Configuring file /etc/hosts
P: Configuring file /etc/resolv.conf
P: Configuring file /etc/hostname
P: Configuring file /bin/hostname
P: Configuring file /usr/sbin/policy-rc.d
P: Configuring file /usr/sbin/initctl
P: Configuring file /etc/apt/apt.conf
P: Configuring file /etc/apt/sources.list

After this the ERROR: ld.so spam is back and steps 2 and 4 happen again: first it’s held back, then we have the 26-2 -> 82-6~bpo70+1 upgrade again, and the ERROR: ld.so spamming stops completely until the build finishes.

I guess 2-4 and 6 are expected (one is for the real chroot, the other one for the binary hooks), but 5 is strange. I don’t really care though.

Next up, feature/jessie…

#8 Updated by intrigeri 2015-06-10 15:49:33

> After this the ERROR: ld.so spam is back and steps 2 and 4 happen again: first it’s held back, then we have the 26-2 -> 82-6~bpo70+1 upgrade again,

I can confirm I see exactly the same behaviour.

> I guess 2-4 and 6 are expected (one is for the real chroot, the other one for the binary hooks),

That’s my guess too.

> but 5 is strange.

Indeed. I see it happen for some of our chroot hooks too:

Creating the vidalia user
ERROR: ld.so: object 'libeatmydata.so' from LD_PRELOAD cannot be preloaded: ignored.
Adding user `vidalia' to group `debian-tor' ...
Adding user vidalia to group debian-tor
Done.
Creating the tails-install-iuk user
ERROR: ld.so: object 'libeatmydata.so' from LD_PRELOAD cannot be preloaded: ignored.
Adding user `tails-install-iuk' to group `tails-iuk-get-target-file' ...
Adding user tails-install-iuk to group tails-iuk-get-target-file
Done.

… which seems to confirm that it’s strongly correlated to adduser calls. Probably it uses the dynamic loader in a weird way, or something.

> I don’t really care though.

Same here. If it works, I’ll happily look elsewhere.

#9 Updated by anonym 2015-06-10 18:45:13

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

Applied in changeset commit:0da3cafdb1a08aa27a0a8a0084a3e9f8d3f57074.

#10 Updated by anonym 2015-06-10 18:45:40

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

anonym wrote:
> Next up, feature/jessie…

As expected, it has none of 2-4 or 6. It does have the strangeness from 5, though. Whatever. :)

intrigeri wrote:
> > I don’t really care though.
>
> Same here. If it works, I’ll happily look elsewhere.

Yup. However, note that without this branch, i.e. by building stable, we do not have issue 5 at all. Whatever (again!). :)

Merged!

#11 Updated by intrigeri 2015-07-03 03:35:59

  • Status changed from Fix committed to Resolved