1

I'm trying to build an extremely minimal chroot environment and / or docker base image with strictly only the packages installed to support the one binary I want to run inside. I'm not interested in tools like deboostrap as these seem to force me to build a complete "system" and that's not what I want. I only want the packages I determine to be necessary.

I can download the .deb files I want manually ensuring I download everything to meet declared depnencies and PreDepends.

The problem comes when I try to install with dpkg --root=<target> and particularly libc6. It's like the pre/post install scripts are not be placed in the correct location, but I can't figure out what I'm missing:

# dpkg --install --root /target /files/archive.ubuntu.com/ubuntu/pool/main/g/glibc/libc6_2.37-0ubuntu2_amd64.deb
(Reading database ... 0 files and directories currently installed.)
Preparing to unpack .../libc6_2.37-0ubuntu2_amd64.deb ...
dpkg (subprocess): unable to execute new libc6:amd64 package pre-installation script (//var/lib/dpkg/tmp.ci/preinst): No such file or directory
dpkg: error processing archive /files/archive.ubuntu.com/ubuntu/pool/main/g/glibc/libc6_2.37-0ubuntu2_amd64.deb (--install):
 new libc6:amd64 package pre-installation script subprocess returned error exit status 2
dpkg (subprocess): unable to execute new libc6:amd64 package post-removal script (//var/lib/dpkg/tmp.ci/postrm): No such file or directory
dpkg: error while cleaning up:
 new libc6:amd64 package post-removal script subprocess returned error exit status 2
Errors were encountered while processing:
 /files/archive.ubuntu.com/ubuntu/pool/main/g/glibc/libc6_2.37-0ubuntu2_amd64.deb
Philip Couling
  • 18,733

1 Answers1

1

I suspect you haven’t installed dash in your target directory... With a non-default installation directory, dpkg invokes maintainer scripts inside a chroot, so their shebang needs to be satisfiable in the chroot.

You’ll probably end up with a dependency loop, which is one of the difficulties tools like debootstrap handle for you. You might find mmdebstrap useful — its “extract” and “custom” variants support installing a given list of packages (and dependencies) with nothing else (not even essential packages).

Stephen Kitt
  • 434,908
  • Fascinatingly debootstrap still appears to assume that there is a "system" being built in the target chroot dir. I would have expected this to succeed mmdebstrap --variant=custom --include=busybox-static unstable ./target/ /etc/apt/sources.list. but it errors complaining that dpkg isn't available. If I read the error right. It's counterpart dpkg --install --root ./target busybox-static...deb works just fine. – Philip Couling Aug 10 '23 at 16:00
  • Yes, this is explained in the mmdebstrap man page: if you don’t want dpkg in your chroot, you need to either use the “extract” variant (and take care of running the maintainer scripts yourself in the appropriate context), or use chrootless mode (which isn’t widely supported). busybox-static is a very simple package to install and shouldn’t be considered representative, but it can be a useful first step in bootstrapping a chroot... – Stephen Kitt Aug 10 '23 at 20:42
  • Was my “missing dash” guess correct? – Stephen Kitt Aug 10 '23 at 20:45
  • Yeah dash was the immediate problem, I'd figured busybox-static might give me a leg up. But I still run into other problems - needing debconf, pulling in perl and others which is deviating from my goal. After reading Teams/Dpkg/Spec/InstallBootstrap I now realise that what I'm trying to achieve is known to be impossible due to the way packages expect the "essential" system packages to be there without declaring it. I wonder if I can use the LFS trick and bind-mount a functional system onto /usr/local/ for the build duration. – Philip Couling Aug 11 '23 at 01:55
  • Ah, I thought you were aware of the requirements around essential packages; that’s why I didn’t elaborate beyond the parenthetical at the end of my answer. You might find it easier to do a staged build rather than a bind mount, at least for your container base image. – Stephen Kitt Aug 11 '23 at 06:52
  • Yeah it's the connection between the essential packages and pre/post I'd not properly understood. I don't really want the essential packages in the final image of I can dodge that. That definitely makes this work experimental. – Philip Couling Aug 11 '23 at 08:21