Your message dated Wed, 13 Jul 2022 10:58:08 +0200
with message-id <165770268886.2702895.16922714981278240109@localhost>
and subject line Re: Bug#1012163: qemu: fails to fail after removal
has caused the Debian Bug report #1012163,
regarding qemu: fails to fail after removal
to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.
(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact [email protected]
immediately.)
--
1012163: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1012163
Debian Bug Tracking System
Contact [email protected] with problems
--- Begin Message ---
Source: qemu
Version: 1:7.0+dfsg-7
Severity: normal
X-Debbugs-Cc: [email protected]
Hi,
thanks a lot for your help with #1011003, much appreciated. With the
`-cpu host` flag I now have a working workaround. Unfortunately I just
stumbled across another strange problem which I'm again able to
reproduce inside QEMU with qemu-user-mode emulation. Have a look at this
log file:
https://jenkins.debian.net/job/fakeroot-foreign-worker/645/consoleText
And search for "apt-get remove --yes qemu-user-static binfmt-support
qemu-user". This used to successfully remove qemu-user support from the
virtual machine. As you can see from a few lines below, running
mmdebstrap --architectures=arm64 [...]
succeeds. Why? Is this because I'm now running qemu with "-cpu host"? Or
is this due to another change in qemu-user from recently?
How do I disable user-mode if removing the package isn't doing it? Do I
*additionally* have to run:
echo 0 > /proc/sys/fs/binfmt_misc/qemu-aarch64
or
echo 0 > /proc/sys/fs/binfmt_misc/status
I'm filing this bug because I expected package removal to also disable
it, but as evident from the log, it doesn't. Why?
Thanks!
cheers, josch
--- End Message ---
--- Begin Message ---
Hi,
Quoting Michael Tokarev (2022-05-31 17:12:22)
> 31.05.2022 16:45, Johannes Schauer Marin Rodrigues wrote:
> ..
> > I'm very surprised it keeps working even though the package providing the
> > emulation binary got removed. This must mean that the qemu-user binaries are
> > loaded into memory where they remain until reboot?
>
> There's nothing surprising in there. This is exactly what makes your chroots
> working without copying qemu binaries into each chroot. This is what the "F"
> (fix binary) binfmt_misc flag is for. See the kernel binfmt_misc
> documentation,
> https://www.kernel.org/doc/html/latest/admin-guide/binfmt-misc.html . Yes,
> the
> kernel keeps the binary open since the registration of each binfmt.
>
> > I have another funny observation: the test is actually flaky and doesn't
> > always
> > produce the same results. I ran the same test 100 times and in 10% of the
> > cases, qemu-user-mode emulation still worked despite the packages being
> > removed. In 90% of the cases, foreign-arch mmdebstrap failed as I expected
> > it
> > to happen. Given your explanation above, I don't understand why I do not get
> > the same result every time I run this test.
>
> This is because you explicitly request/install binfmt-support, so it and
> systemd-binfmt.service are working in parallel. The result is
> non-deterministic.
this problem is now fixed with the upload of src:systemd 251.2-4
https://tracker.debian.org/news/1332902/accepted-systemd-2512-4-source-into-unstable/
Changes:
systemd (251.2-4) unstable; urgency=medium
.
* Use try-restart in systemd-binfmt dpkg trigger
Thanks to Jochen Sprickerhof for making me aware of this.
cheers, josch
signature.asc
Description: signature
--- End Message ---
