我正在尝试在 docker 容器中设置一个外部 chroot。脚本摘录:
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
所以图书馆绝对是它应该在的地方。这里出了什么问题,我该怎么办?
网络上的一些来源表明其
fakechroot
行为不一致,这可能解释了失败。此外,fakechroot
不需要,因为chroot
在 Docker 容器中运行时没有任何问题(GitLab CI 运行器,据我所知,它以非特权模式运行)。另一方面,
fakeroot
这似乎是必要的,因为一些特权操作(即挂载/sys
和/proc
)将在非特权 Docker 容器上失败。这也意味着我们可以选择一个常规的
--variant
(除 之外的任何东西fakechroot
,如果不在环境中运行,它将出错fakechroot
)。所以,放弃
fakechroot
并使用--variant
除fakechroot
(在我的例子中,buildd
因为我正在设置构建系统)。以下是有效的,至少可以在debootstrap
没有错误的情况下完成两个阶段:与前面的示例相比,一些包也发生了变化;我没有调查是否真的有必要。