Skip to content

Fix packages.chroot with disabled --apt-indices option (Closes: #994982)

Michał Prochera requested to merge miproch/live-build:master into master

The problem with the #994982 is that the lb build ran with --apt-indices option set to false and some deb files placed in the packages.chroot directory fails with the following message:

E: Unable to locate package squashfs-tools

This error happened to be produced by the apt remove command called inside the Remove_packages function inside chroot_archives during the binary stage of a build process.

After further investigations, it turns out that the problem exists if ALL of these conditions are satisfied:

  • Lack of APT indices - with the indices, an attempt to remove the squashfs-tools package doesn't cause any error. It is because APT recognizes the name of the package, resulting in a message saying that the removal is not needed. That also leads to an alternative solution to the problem (the patch is included in the MR for reference), which tries to ensure APT indices before the Remove_packages call by unconditionally executing apt update. After applying the fix, the following output is produced instead of the error:

      Reading package lists...
      Building dependency tree...
      Reading state information...
      Package 'squashfs-tools' is not installed, so not removed

    That approach should have no negative impact on the generated image because the indices are in the binary stage, so they won't be propagated into a filesystem.squashfs (if I understand the code correctly). The disadvantage of this approach is that this doesn't really change the script behavior, which seems to be incorrect. The best would be to ensure that no two Check_package-Install_packages-Remove_packages blocks (I'll call them CIR blocks for short) are affected by each other (which is what my MR is trying to provide) - that is, only installed temporary packages within a block should be removed there.

  • Having apt-utils inside binary stage chroot - inside the chroot_archives before mentioned CIR block there is actually an apt update call but only executed if the apt-utils package is not available (which is the package to be installed within the block). On the other hand, the apt-utils should be in a chroot under normal conditions because debootstrap downloads it by default.

  • Having placed custom debs in config/packages.chroot or config/packages - these are other conditions that have to be fulfilled to make the execution enter mentioned CIR block.

  • Not removing squashfs-tools package (or equivalent) in binary_rootfs - the squashfs-tools are installed inside a dedicated CIR block, where the Remove_packages function is not always called. This could affect another CIR block because the package names installed within the block are saved to a chroot.installed_tmp_pkgs file and not cleared until the Remove_packages gets called. The other thing is that in this specific case, Remove_packages may not have been called because after preparing a filesystem.squashfs the whole chroot directory is deleted. Therefore there is no need to remove such packages separately. The problem itself isn't only limited to the squashfs filesystem option - all filesystems creation variants should trigger the error in the same way. What's interesting, the behavior seems to be already noticed - it's described in one of the commit messages in this repository: f27d13de. My MR simply makes the Remove_packages calls in binary_rootfs unconditional, which prevents the package names from leaking and being processed elsewhere. After applying the changes, the whole build succeeds with the following squashfs-tools removal output text:

      Reading package lists...
      Building dependency tree...
      Reading state information...
      The following packages will be REMOVED:
      liblzo2-2* squashfs-tools*
      0 upgraded, 0 newly installed, 2 to remove and 0 not upgraded.
      After this operation, 538 kB disk space will be freed.
      (Reading database ... 
      (Reading database ... 5%
      (Reading database ... 10%
      (Reading database ... 15%
      (Reading database ... 20%
      (Reading database ... 25%
      (Reading database ... 30%
      (Reading database ... 35%
      (Reading database ... 40%
      (Reading database ... 45%
      (Reading database ... 50%
      (Reading database ... 55%
      (Reading database ... 60%
      (Reading database ... 65%
      (Reading database ... 70%
      (Reading database ... 75%
      (Reading database ... 80%
      (Reading database ... 85%
      (Reading database ... 90%
      (Reading database ... 95%
      (Reading database ... 100%
      (Reading database ... 9248 files and directories currently installed.)
      Removing squashfs-tools (1:4.4-2+deb11u2) ...
      Removing liblzo2-2:amd64 (2.10-2) ...
      Processing triggers for libc-bin (2.31-13+deb11u2) ...

For the sake of completeness, I've included a bug MWE based on Docker and Bash (you have to provide the live-build source to run it), logs generated before and after applying this MR as well as the patch for alternative solution mentioned earlier (also tested). That is my first merge request, and hence I've prepared so much data about the problem.

994982-fix-mwe.tar.gz 994982-fix-logs.tar.gz 994982-alt-fix.patch

Edited by Michał Prochera

Merge request reports

Loading