If debootstrap installed qemu-user-static into the chroot
when --foreign was used, it could then immediately chroot in
and run commands (assuming the host system has binfmt-support
installed).

This would allow debootstrap to go ahead and run the second stage
itself, under qemu emulation, and leave the user with a foreign chroot
that could be transparently chrooted into.

https://wiki.debian.org/QemuUserEmulation for details

qemu-user-static includes "qemu-debootstrap" which does exactly this.

You're thinking that should be merged into debootstrap directly?

live well,
  vagrant

Vagrant Cascadian wrote:

Ok.. No docs pointed that out.

I think it would be a net loss of complexity to roll this into
debootstrap. Unless there are a lot of other qemu-user-static like
things that this might slippery slope debootstrap into being responsible
for, but that seems unlikely.

The existence of wrappers like this that use --foreign do argue that a
new switch should be needed for this behavior. Something like
--with-qemu

That would get you the foreign binary of qemu-user-static, wouldn't it?

What is needed is to copy /usr/bin/qemu-$ARCH-static from the host
environment.

Ian.

I use "mk-sbuild" utility which debootstraps native,
"qemu-user-static" native (copies from host, and i believe by means of
qemu-debootstrap), and cross chroots for any debian/ubuntu/custom
releases.

Works very well. Not sure it's at all appropriate for debootstrap to
grow such / similar extra features. Most recently using it for arm64
qemu-user-static native chroots and arm64 cross-compilation chroots.

(mk-sbuild has other tricks up it's sleeve as well, like setting up
snapshots using lvm/overlayfs/aufs, opting-in to use eatmydata, add
custom sources etc.)

Ian Campbell wrote:

Yes, but then nothing will upgrade it, which is important since user
mode qemu often has missing syscalls that get added in newer versions.

deboostrap could arrange for the package to be installed in the chroot,
using multiarch.

True, this is why tools like schroot copy it on each entry (actually, UI
think schroot uses a bind mount, but anyway...)

That would be neat I suppose.

Totally out of scope for this bugreport but I wonder how hard it would
be to create a chroot which used the host versions of things like bash
etc but the target versions of things like gcc. I expect any effort
expended on that would be better spent on getting the proper cross
environment stuff working...

Ian.

With version 2.12~rc3 (currently in unstable), qemu-user-static doesn't
require copying the qemu-ARCH-static binary into the chroot.

You can simply call:

  debootstrap --arch=ARCH sid CHROOT

... and it just works now, without any debootstrap --foreign or
qemu-debootstrap wrappers!

You might still want the binary copied into the chroot to make it easier
if moving the chroot to another machine, but that seems well outside the
scope of what debootstrap should worry about.


live well,
  vagrant

With version 2.12~rc3 (currently in unstable), qemu-user-static doesn't
require copying the qemu-ARCH-static binary into the chroot.

You can simply call:

  debootstrap --arch=ARCH sid CHROOT

... and it just works now, without any debootstrap --foreign or
qemu-debootstrap wrappers!

You might still want the binary copied into the chroot to make it easier
if moving the chroot to another machine, but that seems well outside the
scope of what debootstrap should worry about.


live well,
  vagrant

I think this depends on a new feature in binfmt_misc in Linux 4.8, so
the copy will also be needed on a jessie or wheezy host.

Ben.

Isn't this what happens now? If I run a foreign debootstrap it completes
automatically on version 1.0.123+deb11u2.