- Package:
- debootstrap
- Source:
- debootstrap
- Submitter:
- Steve McIntyre
- Date:
- 2025-09-18 15:55:01 UTC
- Severity:
- minor
- Tags:
$ sudo debootstrap --arch=armhf sid sid-armhf ftp://ftp.debian.org/debian/ fails with the errors W: Failure trying to run: chroot /tmp/sid-armhf mount -t proc proc /proc W: See /tmp/sid-armhf/debootstrap/debootstrap.log for details because I'm running on amd64. That's fine, but it would be helpful if the --help output mentioned the "--foreign" option to stop this happening. Maybe also pick up on the failure to run something in the chroot if the arch specified doesn't match the native one and tell the user about --foreign then?
Hi Steve, all, 2012-11-14 11:51 Steve McIntyre: Seems that I sent my report too quickly, I failed to check the bug lists for "--foreign", so merging with this previous bug report makes sense, I think. From my report:-------------- --help says:
control: tags -1 +patch
Hi,
Then, how about this patch? It results on amd64 host
diff --git a/debootstrap b/debootstrap
index 9b547ad..2fb87b1 100755
--- a/debootstrap
+++ b/debootstrap
@@ -153,6 +153,7 @@ if [ $# != 0 ] ; then
--foreign)
if [ "$PRINT_DEBS" != "true" ]; then
WHAT_TO_DO="finddebs dldebs first_stage"
+ SET_FOREIGN="true"
fi
shift
;;
@@ -456,6 +457,17 @@ if [ -z "$ARCH" ] || [ -z "$HOST_OS" ]; then
fi
+if [ ! "$ARCH" = "$HOST_ARCH" ]; then
+ if [ ! "$SET_FOREIGN" = "true" ] || [ ! "$SECOND_STAGE_ONLY" = "true" ]; then
+ if [ "$HOST_ARCH" = "amd64" ] && [ "$ARCH" = "i386" ] ; then
+ # i386 binary can be run on amd64 host
+ true
+ else
+ error 1 WHATARCH "Tried to run on different architecture in chroot environment.\n Use --foreign or --second-stage option, instead"
+ fi
+ fi
+fi
+
if [ "$HOST_OS" = "kfreebsd" ] || [ "$HOST_OS" = "freebsd" ]; then
for module in linprocfs fdescfs tmpfs linsysfs; do
kldstat -m "$module" > /dev/null 2>&1 || warning SANITYCHECK "Probably required module %s is not loaded" "$module"
CCing the maintainer of arch-test who will probably have some input. It is a bad idea to hard-code this and hard-code it for only two arches, using arch-test and falling back to a more comprehensive list would be much better, as I suggested in my initial bug report: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=826709#5 I prefer the message I wrote in my initial bug report: This machine cannot run binaries for architecture armhf There are two options to work around this: Use qemu-debootstrap instead of debootstrap Use debootstrap --foreign here and use debootstrap --second-stage on armhf https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=826709#5
Especially that amd64 hosts only _usually_ can run i386. It's a kernel config option that happens to be enabled in Debian kernels, but may be omitted from derivative or self-built ones, usually for reasons of space and security (compat syscalls and ioctls are a source of bugs, sometimes exploitable). Thus, CONFIG_IA32_EMULATION might or might not be enabled. On x86 I'm not aware of any 64-bit only hardware, but elsewhere, 32-bit compat is optional -- skipping it can make chips cheaper and more power-efficient, thus arm64 is often incapable of running armhf or armel. Even on armhf, the manufacturer may choose to skip costly synchronization needed for obsolete SWP instructions required by armel, which means debootstrap (strictly single-threaded I think) will succeed but installed system will run into mysterious corruption. Thus, a hard-coded list would do more harm than good. Sure, most of the time it'd work, but it's the unusual cases when you need accurate error messages. it's a small package, systems that act as hosts are big enough that giving the user helpful error messages is worth it. It wouldn't harm new (not yet supported archs) as answer "can't test" (return code 2) is no different than arch-test being not installed. There is one caveat: binfmt uses interpreters relative to the current process' root directory, thus testing outside the chroot doesn't imply you have an interpreter in the right place inside. Usually, debootstrap is called by tools after doing: mkdir -p $CHROOT/usr/bin && cp -p /usr/bin/qemu-6502-static $CHROOT/usr/bin/ but it's a step you're likely to forget. I guess, this can be done by adding an option to arch-test to copy the helper into the chroot, call chroot(2) then test inside. Obviously, the above is not a concern for hardware or whole-machine emulation (arch-test -n). As an author of a hammer, I'm probably biased towards using it. But, there's at least one possibility: before calling any complex tool inside the chroot, you can run something dead simple like /bin/true. If that fails, then either you have a non-executable arch, glibc is broken or missing, or something else went bad while debootstrapping. These alternatives can't be distinguished between (this is where arch-test would be better), but at least we'd isolate that whole class of problems from other reasons mount can fail. Meow!
Yes, this is a good reason to do a run-time check. It is optional but not "often" omitted. I'm only aware of Cavium leaving it out. [...] I think you're referring to the need for DMB on v6+, right? The ARMv6 ARM claims that memory ordering wasn't specified at all in earlier architecture versions, so older code using SWP was not portable anyway. So far as I can see, OpenSSL still uses SWP when built for ARMv4/v5, and does not use DMB. We should really fix that. dietlibc also uses SWP without DMB - but then its ARMv6/v7 implementation and several other architectures (mips, ppc) are also lacking memory barriers, so I assume no-one really uses it in multithreaded programs. uclibc has some trivial wrappers around SWP that don't seem to be used any more. And... that's it, so far as I can see. Ben.
Hello, Good morning, We have gone through your samples from a partner and Here is our Order List. Please do bear in mind that we are very much in need of this order, quote your competitive prices. Kindly send the Order confirmation. Your early reply will be much appreciated. Best Regards, Maryanah Erwin. PT FINDORA INTERNUSA Jln Pahlawan 66 Kec. Arjawinangun 45162 CIREBON West-Java INDONESIA tel : +62 231 357334 fax: +62 231 357260 email: marketing@findora.com
Hello, Good morning, We have gone through your samples from a partner and Here is our Order List. Please do bear in mind that we are very much in need of this order, quote your competitive prices. Kindly send the Order confirmation. Your early reply will be much appreciated. Best Regards, Maryanah Erwin. PT FINDORA INTERNUSA Jln Pahlawan 66 Kec. Arjawinangun 45162 CIREBON West-Java INDONESIA tel : +62 231 357334 fax: +62 231 357260 email: marketing@findora.com
Hello, Good morning, We have gone through your samples from a partner and Here is our Order List. Please do bear in mind that we are very much in need of this order, quote your competitive prices. Kindly send the Order confirmation. Your early reply will be much appreciated. Best Regards, Maryanah Erwin. PT FINDORA INTERNUSA Jln Pahlawan 66 Kec. Arjawinangun 45162 CIREBON West-Java INDONESIA tel : +62 231 357334 fax: +62 231 357260 email: marketing@findora.com
Mrs maria has a donation of 3.5m for you. Reply mfrancafissolo00@gmail.com<mailto:mfrancafissolo00@gmail.com> for more details.