On Sun, Apr 01, 2018 at 11:24:14AM +0800, Paul Wise wrote: > CCing the maintainer of arch-test who will probably have some input. > > On Sun, 2018-04-01 at 11:32 +0900, Hideki Yamane wrote: > > > + if [ "$HOST_ARCH" = "amd64" ] && [ "$ARCH" = "i386" ] ; then > > + # i386 binary can be run on amd64 host > > It is a bad idea to hard-code this and hard-code it for only two > arches
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. > using arch-test and falling back to a more comprehensive list > would be much better Indeed, making arch-test a Recommends for debootstrap would be a good idea: 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). > 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 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! -- ᛊᚨᚾᛁᛏᚣ᛫ᛁᛊ᛫ᚠᛟᚱ᛫ᚦᛖ᛫ᚹᛖᚨᚲ
