Bug#983494: arch-test breaks debootstrap into empty chroot

Ben Burton

unread,

Feb 24, 2021, 10:00:03 PM2/24/21

to

Package: debootstrap
Version: 1.0.123
Severity: normal
X-Debbugs-Cc: b...@debian.org

Hi - I'm using debootstrap to create a fresh new chroot, and it fails
immediately:

root:~# /usr/sbin/debootstrap --variant=buildd buster /var/chroot/buster-amd64
E: Unable to execute target architecture
root:~# cat /var/chroot/buster-amd64/debootstrap/debootstrap.log
amd64: not supported on this machine/kernel
root:~#

In this example, the directory /var/chroot/buster-amd64 did not previously
exist.

The problem appears to be at the arch-test stage (line 637 of
/usr/sbin/debootstreap), where it runs 'arch-test -c "$TARGET" "$ARCH"'
to see if the host and target architectures are compatible. AFAICT,
when given a chroot via -c, arch-test looks for its test files *inside*
the chroot; however, at this stage debootstrap has not yet done any
unpacking (or even any downloads), which means the chroot is empty.
This maks arch-test fail, even though the host and target architecture
are identical, and in turn this makes debootstrap fail before it has a
chance to do any real work.

If I comment out the arch-test stage at line 632 (i.e., skipping the
arch-test block entirely) then debootstrap runs successfully to completion.

Thanks - Ben.

-- System Information:
Debian Release: bullseye/sid
APT prefers testing
APT policy: (500, 'testing')
Architecture: amd64 (x86_64)

Kernel: Linux 5.10.0-3-amd64 (SMP w/8 CPU threads)
Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.UTF-8 (charmap=UTF-8), LANGUAGE=en_AU:en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages debootstrap depends on:
ii wget 1.21-1+b1

Versions of packages debootstrap recommends:
ii arch-test 0.17-1
ii debian-archive-keyring 2019.1
ii gnupg 2.2.27-1

Versions of packages debootstrap suggests:
pn squid-deb-proxy-client <none>
pn ubuntu-archive-keyring <none>

-- no debconf information

Arnaud R

unread,

Mar 18, 2021, 1:50:02 AM3/18/21

to

Also struggling with something similar, I thought I hit this bug, but actually no. Let me bring more details.

> arch-test looks for its test files *inside* the chroot;

That's not how I read the code. It copies the helper in the chroot, and then it runs it with chroot:

https://github.com/kilobyte/arch-test/blob/28f25fef25cdb09805a20986414bf3435c67d47f/arch-test#L56

And here's a corresponding trace, while running it with '-x':

++ basename
            /usr/lib/arch-test/arm64


        + HELPER_F=arm64


        + cp -p
            /usr/lib/arch-test/arm64
            /builds/kalilinux/build-scripts/kali-docker/arm64/kali-rolling/arm64


        + trap 'rm
'\''/builds/kalilinux/build-scripts/kali-docker/arm64/kali-rolling/arm64'\'''
            0


        ++ chroot
            /builds/kalilinux/build-scripts/kali-docker/arm64/kali-rolling
            /arm64


        + MSG=


        + '[' 127 -eq 0 -a x = xok
            ']'


        + echo 'arm64: not supported
            on this machine/kernel'


        arm64: not supported on this
            machine/kernel

+ exit 1

Cheers,

Arnaud

Ken Sharp

unread,

Feb 4, 2024, 10:30:04 AMFeb 4

to

I've never seen this. Is it fixed?

OpenPGP_signature.asc

cen

unread,

Feb 16, 2024, 3:40:04 PMFeb 16

to

I've seen this in a fresh virt-manager bookworkm VM, uninstalling
arch-test did the trick