我正在尝试在 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
所以图书馆绝对是它应该在的地方。这里出了什么问题,我该怎么办?
答案1
网络上的一些来源表明其fakechroot
行为方式不一致,这可能解释了失败的原因。此外,fakechroot
应该不需要,因为chroot
在 Docker 容器中运行没有任何问题(GitLab CI 运行器,据我所知,它在非特权模式下运行)。
另一方面,这fakeroot
似乎是必要的,因为一些特权操作(即 mount/sys
和/proc
)否则将在非特权 Docker 容器上失败。
这也意味着我们可以选择常规--variant
(除 之外的任何内容fakechroot
,如果不在环境中运行,则会出错fakechroot
)。
因此,放弃fakechroot
并使用--variant
其他的fakechroot
(在我的例子中,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
与之前的示例相比,一些软件包也发生了变化;我没有调查这是否真的有必要。