26.01.2021 18:38, Thorsten Glaser пишет:
Hi Michael,
Mmm. Is there a fix? If there is, I for one don't know it.
AIUI using a wrapper around the qemu binary that adds the
option (I would say which but the qemu-m68k-static manpage
documents qemu 0.9.0 and so doesn’t have it *cough*) to the
invocation, then change the binfmt-misc registration to add
the P flag and call this wrapper script.
Pending a better fix, of course, but that probably involves
changes to the kernel from what I’ve seen.
The problem with the wrapper is that it effectively nullifies
the F flag of binfmt. That is, with F and the binfmt interpreter
being the qemu binary directly, we can use regular, non-static,
qemu-user, or qemu-user-static, and run the thing from outside
of the foreign chroot.
But with the wrapper, we have to have the actual qemu-user binary
runnable within the foreign chroot *too*, - only the wrapper will
be able to reside outside of the chroot, but it will run the
actual qemu binary *within* that chroot.
So in the end it seems this approach with the wrapper breaks more
than it fixes.
I can think of another hack. Qemu-user binary may look at its
name and if it sees some magic prefix (eg, qemu-foo-binfmt-trigger),
it will assume it is run from within the binfmt subsystem with
the P flag in effect. Yes it is hacky, but it *might* work.
Dunno how good it is to perform such experiments this late in
the bullseye development cycle...
What do you all think ?
/mjt
