在docker上使用fakechroot的第二阶段失败(/lib/ld-linux-armhf.so.3:没有这样的文件或目录)

Question

我正试着在一个码头集装箱里装一台外国显色机。从脚本中摘录：

apt-get -y install debootstrap fakechroot fakeroot qemu-user-static binfmt-support
mkdir -p $CROSS_ROOT
fakechroot fakeroot -s .fakeroot.state debootstrap --variant=fakechroot --include=fakeroot,build-essential,ca-certificates,debian-archive-keyring,git,sudo --arch=${CROSS_ARCH} --foreign ${CROSS_RELEASE} $CROSS_ROOT $CROSS_MIRROR
mkdir -p $CROSS_ROOT/usr/bin
ln /usr/bin/qemu-*-static $CROSS_ROOT/usr/bin/
fakechroot fakeroot -i .fakeroot.state -s .fakeroot.state chroot $CROSS_ROOT /debootstrap/debootstrap --second-stage

对于Debian buster/armhf，最后一行出现以下错误消息失败：

/lib/ld-linux-armhf.so.3: No such file or directory

但是，当我在最后一行之前插入ls -la $CROSS_ROOT/lib/ld-linux-*时，可以找到库文件：

lrwxrwxrwx 1 root root 30 Mar 15  2022 /opt/chroot/armhf/lib/ld-linux-armhf.so.3 -> arm-linux-gnueabihf/ld-2.28.so

链接目标也存在：

-rwxr-xr-x 1 root root 105840 Mar 15  2022 /opt/chroot/armhf/lib/arm-linux-gnueabihf/ld-2.28.so

所以图书馆肯定是它应该在的地方。这里有什么问题，我能做些什么？

Answer 1

网络上的一些来源表明，fakechroot的行为方式不一致，这可能会解释故障。此外，不应该需要fakechroot，因为chroot在Docker容器中运行时没有任何问题(据我所知，GitLab CI运行程序在非特权模式下运行)。

另一方面，fakeroot似乎是必要的，因为一些特权操作(即挂载/sys和/proc)将在非特权的Docker容器上失败。

这也意味着我们可以选择一个常规的--variant (除了fakechroot以外的任何东西，如果不是在fakechroot环境中运行，就会出错)。

因此，删除fakechroot并使用fakechroot以外的--variant (在我的例子中，buildd是我正在设置的构建系统)。以下操作起了作用，至少到了debootstrap完成这两个阶段都没有错误的地步：

apt-get -y install debootstrap fakechroot fakeroot qemu-user-static binfmt-support
mkdir -p $CROSS_ROOT
fakeroot -s .fakeroot.state debootstrap --variant=buildd --include=fakechroot,fakeroot,build-essential,ca-certificates,debian-archive-keyring,git,sudo --arch=${CROSS_ARCH} --foreign ${CROSS_RELEASE} $CROSS_ROOT $CROSS_MIRROR
mkdir -p $CROSS_ROOT/usr/bin
ln /usr/bin/qemu-*-static $CROSS_ROOT/usr/bin/
fakeroot -i .fakeroot.state -s .fakeroot.state chroot $CROSS_ROOT /debootstrap/debootstrap --second-stage --verbose

一些包也在前面的示例中进行了更改；我没有研究这是否真的有必要。