Control: reopen -1
16.05.2022 01:07, Johannes Schauer Marin Rodrigues wrote:
Hi mjt,
Thank you very much for this excellent bug report!
thank you for your very quick reply! :D
Well.. it turned out my replies, while quick, aren't that helpful ;)
But let's see..
On Sun, 15 May 2022 10:43:43 +0300 Michael Tokarev <m...@tls.msk.ru> wrote:
...
Speaking of mmdebstrap: why does it try to "fall back"? Did it try this
before, or is it intentional? The thing is that today, qemu-user-static
is transparent (or should be anyway), there's no need to run it explicitly,
it is done the binfmt-misc way so *bootstrap should not notice the arch
it is installing is foreign. It is okay if mmdebstrap does that since
historic times when this transparency didn't work, and it is not okay
if it expects such transparency now but it doesn't work.
I'm not sure what you mean with "fall back". Maybe you mean that mmdebstrap
reads /proc/sys/fs/binfmt_misc/qemu-$arch and then looks for an F in the
"flags" field. If it finds that, then it will not copy qemu-user-static into
the chroot (as was the old way to make this work). As you also pointed out,
today this is automatic.
No, I mean it is possible to try to execute a foreign binary directly, and
if that fails, do it again but this time, prepend "qemu-foo[-static]' to the
command line. Checking binfmt_misc flags is ofcourse too much. I'm asking
because of this:
00:00:00.266 E: + mmdebstrap --mode=root --variant=apt --architectures=arm64
unstable /tmp/debian-chroot.tar http://127.0.0.1/debian
00:00:00.599 E: I: arm64 cannot be executed, falling back to qemu-user
I don't know what it will do with $options->{qemu} after this. I don't see
any reason to mess with qemu-foo-static in tools like debootstrap, - you can
run foreign binaries with it, but you can't - without binfmt_misc support -
you can't run maintscripts or other stuff because this requires executing
multiple binaries which you don't control.
This brings me to a slightly related question: is it possible to disable this
transparent qemu-user-static support of running foreign architecture binaries
without the qemu-user-static inside the chroot? While this is probably very
useful in 99% of the cases, it is very annoying when I try to cross build a
source package and then I get a false positive when the build (wrongly) tries
to execute a foreign architecture binary and succeeds. Thus, on my machine I'm
constantly uninstalling and then re-installing qemu-user whenever I want to do
cross builds. Is there some config option I can set to enable or disable
transparent binfmt-misc emulation by qemu?
Yes this is possible, but only at the binfmt_misc level.
echo 0 > /proc/sys/fs/binfmt_misc/qemu-aarch64 -- disable this particular
entry
echo 1 > /proc/sys/fs/binfmt_misc/qemu-aarch64 -- enable it
echo 0 > /proc/sys/fs/binfmt_misc/status -- disable whole binfmt support
echo 1 > /proc/sys/fs/binfmt_misc/status -- enable it
With systemd you can disable particular formats/architectures entirely
by masking /usr/lib/binfmt.d/qemu-foo.conf in /etc/binfmt.d/ (if you remove
binfmt-support).
If you rename qemu-foo into qemu-foo.conf in /usr/lib/binfmt.d/ and restart
systemd-binfmt.service, it should work. I think.
I cannot confirm that this works (I tried with 1:7.0+dfsg-6).
I am now using 1:7.0+dfsg-7 which calls them *.conf and the problem persists.
Maybe you want to re-open this bug? Or should I open a new one?
Already done.
Then I also want to respond to some of the things you said in #debian-devel:
10:11 < mjt> but now I wonder if - after switching from binfmt-support to
systemd-binfmt (and fixing
this qemu-user-static bug), -- if the whole thing will work when
installed in a chroot
10:13 < mjt> qemu-user should not register its binfmts when installed in
chroot. binfmt-support didn't
care about this, but I've no idea about systemd - maybe that one
cares enough to actually
fix this
10:15 < mjt> in other words: it worked in this context by accident not by1
design
What do I have to change to make it work again?
This is a very good question. Two questions.
First, I still don't know what happened. I tried to reproduce it locally but
failed so far. Probably should try kernel from unstable to begin with, -
I'm on bullseye. And I'm puzzled really, - because nothing had changed in
this area in 7.0+dfsg-3 compared with the previous version, - as it turned
out, even the thing which actually did change - the way it is being registered -
does not work and hence does not affect this, and since you install
binfmt-support
explicitly, everything is exactly the same as before.
And second, the whole thing of registering binfmts in a chroot is, um, wrong.
This is because this affects whole system, inside this chroot, outside it, and
in all other chroots too. And you install it in a chroot. It's okay to install
qemu-user-static and register binfmts on the actual host system, but it should
not be allowed to do in a chroot, because it affects whole system, and it
changes execution domain for the actual host system!
/mjt
