Package: deboostrap Version: 1.0.128 Severity: normal we use ELBE to build Debian-based ARM64 root filesystem images on AMD64 systems. ELBE invokes debootstrap as part of the image build. The target root filesystem is Debian 13 (trixie) for arm64. ELBE performs these three steps:
debootstrap \ --include ca-certificates,gpg-agent,gpgv,gpgv \ --foreign \ --keyring /path/to/chroot/etc/apt/trusted.gpg.d/elbe-xml-primary-key.gpg \ --arch arm64 \ trixie \ /path/to/chroot \ <Debian mirror> cp /usr/bin/qemu-aarch64-static /path/to/chroot/usr/bin/ /usr/sbin/chroot /path/to/chroot /debootstrap/debootstrap --second-stage The debootstrap --second-stage step is particularly slow in our setup. On our build server, it takes approximately 90 minutes. This build VM runs Debian GNU/Linux 12 (bookworm) with: * kernel: 6.1.0-52-amd64, Debian 6.1.180-1 (2026-08-03) * debootstrap: 1.0.128+nmu2+deb12u2 * qemu-user-static: 1:7.2+dfsg-7+deb12u18+b3 * qemu-aarch64: version 7.2.22 * architecture: x86_64 * 8 vCPUs on an Intel Xeon Platinum 8362 host ARM64 executables in the target root filesystem are run through QEMU user-mode emulation via binfmt (aarch64-binfmt-P). During the second stage, the process tree showed the ARM64 target shell running "grep --perl-regexp" to evaluate package metadata. In a representative sample, this emulated Perl process used almost one full host CPU (99.8%). The process also did not finish during the obsevation time. No I/O and swap activity was visible. Could you please advise: 1. Is a runtime of approximately 90 minutes for debootstrap --second-stage of an ARM64 root filesystem on an AMD64 host under QEMU user-mode known or broadly expected? 2. Are there known performance bottlenecks, configuration options, or diagnostic methods that you recommend for this scenario? 3. We also evaluated mmdebstrap. For the same root filesystem definition, the overall image build takes about 30 minutes. Is mmdebstrap considered a recommended replacement for debootstrap in this use case? Kind regards, Kai Staud
