qemu-user-static fails to install in WSL and LXD

Note: All the data in the report indicates that you upgrade to 19.04 not 18.10.

hppa was added/enabled in 2.12 so it would make sense that it is called the first time.
To register that it needs the kernels support, maybe in WSL the binfmt has problems with it?

From your log:
Setting up qemu-user-static (1:3.1+dfsg-2ubuntu3.3) ...
update-binfmts: warning: unable to close /proc/sys/fs/binfmt_misc/register: Invalid argument
update-binfmts: warning: unable to enable binary format qemu-hppa

I'll ask around, but if there is anyone out there with WSL that could give this a try that would be great. Just install 19.04 and in there qemu-user-static. Just to check if this is a regular or a one-off issue.

It happens reliably every time I try to do-release-upgrade, would you want me to do it again and get more logs?

Hi Jesse,
thanks for chiming in here. TBH I must admit I don't yet know exactly what data I'd need to be gathered in this case. I'm setting up a WSL environment myself to check it out ...

In case I find something I might come back to all of you with an experimental build to try - to make sure it doesn't only work for me.

I release upgraded before installing qemu-user-static for better debugging - as then I can just install/uninstall that package instead of the much more heavy do-release-upgrade.

With that setup I confirmed the issue matchign the reported log:

$ sudo apt install qemu-user-static
Reading package lists... Done
Building dependency tree
Reading state information... Done
The following NEW packages will be installed:
  qemu-user-static
0 upgraded, 1 newly installed, 0 to remove and 0 not upgraded.
Need to get 13.6 MB of archives.
After this operation, 129 MB of additional disk space will be used.
Get:1 http://archive.ubuntu.com/ubuntu disco-updates/universe amd64 qemu-user-static amd64 1:3.1+dfsg-2ubuntu3.4 [13.6 MB]
Fetched 13.6 MB in 5s (3016 kB/s)
Selecting previously unselected package qemu-user-static.
(Reading database ... 30935 files and directories currently installed.)
Preparing to unpack .../qemu-user-static_1%3a3.1+dfsg-2ubuntu3.4_amd64.deb ...
Unpacking qemu-user-static (1:3.1+dfsg-2ubuntu3.4) ...
Setting up qemu-user-static (1:3.1+dfsg-2ubuntu3.4) ...
update-binfmts: warning: unable to close /proc/sys/fs/binfmt_misc/register: Invalid argument
update-binfmts: warning: unable to enable binary format qemu-aarch64
update-binfmts: exiting due to previous errors
dpkg: error processing package qemu-user-static (--configure):
 installed qemu-user-static package post-installation script subprocess returned error exit status 2
Processing triggers for man-db (2.8.5-2) ...
Errors were encountered while processing:
 qemu-user-static
E: Sub-process /usr/bin/dpkg returned an error code (1)

You see in my case it isn't even hppa, but aarch64 instead (which is another arch that was added recently)

It already has code to skip the format registration for containers which WSL is to some extend.

# check if we're running inside an (lxc) container
# (we may copy or move this to the postinst script too, to skip installing it)
grep -zqs ^container= /proc/1/environ && exit 0

Maybe this just needs an extension to cover WSL?

Oh and "it" in the former comment being the postinst script of qemu-user-static in /var/lib/dpkg/info/qemu-user-static.postinst

We re-run this as-is for debugging via:
  export DPKG_MAINTSCRIPT_ARCH=amd64
  export DPKG_MAINTSCRIPT_NAME=postinst
  sudo -E /var/lib/dpkg/info/qemu-user-static.postinst configure

I checked and as expected in WSL on all of them to register.

BTW I checked the usual container checks and we have:
$ systemd-detect-virt
wsl

$ systemd-detect-virt --container
wsl
$ echo $?
0

So those could be used here instead of the old test that doesn't catch WSL (and probably other containers).
Or to avoid that there might be containers that support this we can make the register call "ok to fail".
But that might hide issues on other environments.
Maybe "ok to fail" if in container ...

I'd need to check the old discussions adding the non-working container check for more details.

Hmm, the 18.04 version of the postinst doesn't look much different.
Why didn't that break as it contains enough arches that failed on the newer versions.

The "not in container" code is rather old of 2014 added by Serge back then.
Back then systemd-detect-virt wasn't really available.
I think we could just modernize this one and we'd be back working, OTOH I want to understand if there is any chance to ever work in a container to avoid re-fixing it then.

18.04 -> 19.10 added
- hppa riscv32 riscv64 xtensa xtensaeb
  And we know we had others failing.
- started to use --fix-binary on update-binfmts (debian bug 868030) That allows on a host able to run this to also use it in chroots and mount namespaces.
  Not a fix for our case, but quite likely the reason why it fails now, but didn't in 18.04 (it
  would have failed later when the lazy open comes)

The capability isn't really good to be checked, binfmt_misc isn't part of the usual caps that you'd get e.g. with getpcaps.

One would think that checking for the MP might be better:
root@Keschdeichel:~# mount | grep binfmt_misc
systemd-1 on /proc/sys/fs/binfmt_misc type autofs (rw,relatime,fd=26,pgrp=1,timeout=0,minproto=5,maxproto=5,direct,pipe_ino=16329)
binfmt_misc on /proc/sys/fs/binfmt_misc type binfmt_misc (rw,relatime)

Or the service /lib/systemd/system/binfmt-support.service which e.g. in a LXD container will not run.
● binfmt-support.service - Enable support for additional executable binary formats
   Loaded: loaded (/lib/systemd/system/binfmt-support.service; enabled; vendor preset: enabled)
   Active: failed (Result: exit-code) since Mon 2019-09-09 08:37:20 UTC; 9ms ago
     Docs: man:update-binfmts(8)
  Process: 551 ExecStart=/usr/sbin/update-binfmts --enable (code=exited, status=2)
 Main PID: 551 (code=exited, status=2)

Sep 09 08:37:20 e systemd[1]: Starting Enable support for additional executable binary formats...
Sep 09 08:37:20 e update-binfmts[551]: update-binfmts: warning: unable to open /proc/sys/fs/binfmt_misc/status for writing: Permission denied
Sep 09 08:37:20 e update-binfmts[551]: update-binfmts: warning: unable to open /proc/sys/fs/binfmt_misc/status for writing: Permission denied
Sep 09 08:37:20 e update-binfmts[551]: update-binfmts: warning: unable to open /proc/sys/fs/binfmt_misc/register for writing: Permission denied

And that is the same for the registering of the formats.
This is only mapped into the container and non-writable (usually).

If I remove the container safety exit I get the same:
$ sudo -E /var/lib/dpkg/info/qemu-user-static.postinst configure
...
update-binfmts: warning: unable to open /proc/sys/fs/binfmt_misc/status for writing: Permission denied
update-binfmts: warning: unable to open /proc/sys/fs/binfmt_misc/register for writing: Permission denied
update-binfmts: warning: unable to enable binary format qemu-hppa
update-binfmts: exiting due to previous errors

But unfortunately qemu-user-static only recommends binfmt-support (as strictly you can use qemu-user-static without binfmt). But to register anything this would need to be available.
The script already has a check if the binary `update-binfmts` exists (as it is only a recommends).

I'm beginning to lean towards `systemctl is-active binfmt-support.service` being the best check.
If it is installed and failed, then the following registrations will fail as well and should not be tried.

While at the same time a container MIGHT be set up with plenty of permissions (privileged, special mapping of the host binfmt as writable). That isn't recommended but could be done.
The check to the active service would catch all of those - fix the bug in WSL (and probably other container formats), while at the same time enable the feature for those who set up privileged-containers just for that.

BTW adding a few references if we need them again here:
- https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=868030
- https://en.wikipedia.org/wiki/Binfmt_misc
- https://www.kernel.org/doc/html/v4.14/admin-guide/binfmt-misc.html

Yeah this seems broken both way, in some containers it activates even if it should not (WSL) and in others it does not activate even if it could (very privileged container setups).

And while non-working in 18.04 (if later used) the effect was negligible but in 18.10 and later it would even break the installation and thereby even a full upgrade.
So 18.04 isn't really affected, 18.10 is no more supported, but lets try to resolve this in Eoan and Disco.

An experimental PPA build started at https://launchpad.net/~paelzer/+archive/ubuntu/bug-1840956-binfmt-containers

Jesse - could one of you give that PPA a try in WSL under 19.04 (Disco) or 19.10 (Eoan)?

Ok, the implementation unintentional "also" covers systems without working systemd.
There it will look like:

  Setting up qemu-user-static (1:3.1+dfsg-2ubuntu3.5~ppa1) ...
  System has not been booted with systemd as init system (PID 1). Can't operate.
  Failed to connect to bus: Host is down

Which is ok, it tried to check if it is up but failed.
So it considers it as "better not go forward" which is the correct thing to do.

Finalized this with a test in LXD and a KVM guest.

LXD:
- binfmt is installed
- service is NOT up
- exits without failing

KVM:
- binfmt is installed
- service is up
- registers types and works

But I have realized this might end up with an ordering issue.
If the service isn't up in time it would not register the types.

We could now either just use
1) systemd-detect-virt --container
2) test install a handler with no effect
   sudo update-binfmts --package test --install test /bin/true --magic 0x1 --mask 0x0

(2) is more functional as it might detect the odd and rare case of a container that does support this.

But I think (1) is more stable. In most containers even if working it might cause near random issue later on. For those rare cases an admin/user can still register the binfmt type on his own.

That seems wiser for the overall majority of Ubuntu users.

Deleted the former Disco build from the PPA.
Added a final Eoan build and added a merge proposal for the fix.

So should I test anything here, or wait for the fix to be merged and just test that?

On Tue, Sep 10, 2019 at 4:55 PM Jesse Schulman
<email address hidden> wrote:
>
> So should I test anything here, or wait for the fix to be merged and
> just test that?

No, I did the testing we need this morning.
I think the next step is someone reviewing my MP and then I can upload
a fix to Eoan.
From there I plan an SRU for this and then I'd appreciate a test by
someone else but me.
But I'll ask for that when the time comes

Alright,

I'm currently reviewing your MP:

PS C:\users\inaddy> wsl --import lp1840956 c:\users\inaddy\wsl\lp1840956 c:\users\inaddy\eoan.tar.gz --version 1

Will give feedback right away.

Alright,

Even with binfmt installed, inside a WSL container, systemd-detect-virt -c did the trick.

$ apt-get upgrade
Reading package lists... Done
Building dependency tree
Reading state information... Done
Calculating upgrade... Done
The following packages will be upgraded:
  qemu-user-static
1 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
1 not fully installed or removed.
Need to get 14.2 MB of archives.
After this operation, 0 B of additional disk space will be used.
Do you want to continue? [Y/n] y
Get:1 http://ppa.launchpad.net/paelzer/bug-1840956-binfmt-containers/ubuntu eoan/main amd64 qemu-user-static amd64 1:4.0+dfsg-0ubuntu8~ppa2 [14.2 MB]
Fetched 14.2 MB in 50s (285 kB/s)

(Reading database ... 91374 files and directories currently installed.)
Preparing to unpack .../qemu-user-static_1%3a4.0+dfsg-0ubuntu8~ppa2_amd64.deb ...
Unpacking qemu-user-static (1:4.0+dfsg-0ubuntu8~ppa2) over (1:4.0+dfsg-0ubuntu7) ...
Setting up qemu-user-static (1:4.0+dfsg-0ubuntu8~ppa2) ...
Processing triggers for man-db (2.8.7-3) ...

I'm replicating my comment in MR just FYIO:

"""
I reviewed PPA contents for Eoan:

https://bugs.launchpad.net/ubuntu/+source/qemu/+bug/1840956/comments/25
https://bugs.launchpad.net/ubuntu/+source/qemu/+bug/1840956/comments/26

And fix indeed works for WSL1.

Just a heads up on WSL2:

I'm not entirely sure how WSL2 binfmt_misc works there, as we currently have a /proc/sys/fs/binfmt_misc/WSLInterop right now in WSL1, and WSL2 uses a Microsoft provided kernel, and there is a feature for you to run Microsoft .exe binaries from WSL2 and app opens in Windows (I have used it and it works :o).

My point is that it might recognize WSL2 as hyperv, but, still, fail to install qemu-user-static due to binfmt_misc issues. I currently have Windows 10 Pro Insider Preview 18970.rs_prerelease.190824-1711 to try if you want, but, I'm afraid of changes for WSL2 as it is still a tech preview. There is also a way to boot WSL2 with a custom (builtin) kernel, setting up a .wslconfig file in %HOME% directory... but, again, that would not be the default for the average user.
"""

> My point is that it might recognize WSL2 as hyperv, but, still, fail to install qemu-user-static due to binfmt_misc issues. I currently have Windows 10 Pro Insider Preview 18970.rs_prerelease.190824-1711 to try if you want, but, I'm afraid of changes for WSL2 as it is still a tech preview. There is also a way to boot WSL2 with a custom (builtin) kernel, setting up a .wslconfig file in %HOME% directory... but, again, that would not be the default for the average user.

Yeah, lets for now fix it for what exists :-)
Thanks for all the checks!

FYI - Fix uploaded to Eoan

This bug was fixed in the package qemu - 1:4.0+dfsg-0ubuntu8

---------------
qemu (1:4.0+dfsg-0ubuntu8) eoan; urgency=medium

  * d/binfmt-update-in: fix binfmt being called in some containers
    (LP: #1840956)

 -- Christian Ehrhardt <email address hidden> Mon, 09 Sep 2019 11:03:13 +0200

Now after the latest release is fixed lets consider SRUs.
As outlined before I don't think we need to change 18.04, but 19.04.
A MP is here: https://code.launchpad.net/~paelzer/ubuntu/+source/qemu/+git/qemu/+merge/372747
I uploaded it to the PPA we already had: https://launchpad.net/~paelzer/+archive/ubuntu/bug-1840956-binfmt-containers/

[DISCO]

# regular installation attempt

Setting up qemu-user-static (1:3.1+dfsg-2ubuntu3.4) ...
update-binfmts: warning: unable to close /proc/sys/fs/binfmt_misc/register: Invalid argument
update-binfmts: warning: unable to enable binary format qemu-aarch64
update-binfmts: exiting due to previous errors
dpkg: error processing package qemu-user-static (--configure):
 installed qemu-user-static package post-installation script subprocess returned error exit status 2
Setting up binfmt-support (2.2.0-2) ...

----

# using the PPA

Preparing to unpack .../0-qemu-user-static_1%3a3.1+dfsg-2ubuntu3.5_amd64.deb ...
Unpacking qemu-user-static (1:3.1+dfsg-2ubuntu3.5) over (1:3.1+dfsg-2ubuntu3.4) ...
Preparing to unpack .../1-qemu-utils_1%3a3.1+dfsg-2ubuntu3.5_amd64.deb ...
Unpacking qemu-utils (1:3.1+dfsg-2ubuntu3.5) over (1:3.1+dfsg-2ubuntu3.4) ...
Preparing to unpack .../2-qemu-system-common_1%3a3.1+dfsg-2ubuntu3.5_amd64.deb ...
Unpacking qemu-system-common (1:3.1+dfsg-2ubuntu3.5) over (1:3.1+dfsg-2ubuntu3.4) ...
Preparing to unpack .../3-qemu-block-extra_1%3a3.1+dfsg-2ubuntu3.5_amd64.deb ...
Unpacking qemu-block-extra:amd64 (1:3.1+dfsg-2ubuntu3.5) over (1:3.1+dfsg-2ubuntu3.4) ...
Preparing to unpack .../4-qemu-system-data_1%3a3.1+dfsg-2ubuntu3.5_all.deb ...
Unpacking qemu-system-data (1:3.1+dfsg-2ubuntu3.5) over (1:3.1+dfsg-2ubuntu3.4) ...
Preparing to unpack .../5-qemu-system-arm_1%3a3.1+dfsg-2ubuntu3.5_amd64.deb ...
Unpacking qemu-system-arm (1:3.1+dfsg-2ubuntu3.5) over (1:3.1+dfsg-2ubuntu3.4) ...
Preparing to unpack .../6-qemu-system-gui_1%3a3.1+dfsg-2ubuntu3.5_amd64.deb ...
Unpacking qemu-system-gui (1:3.1+dfsg-2ubuntu3.5) over (1:3.1+dfsg-2ubuntu3.4) ...
Setting up qemu-system-gui (1:3.1+dfsg-2ubuntu3.5) ...
Setting up qemu-user-static (1:3.1+dfsg-2ubuntu3.5) ...
System has not been booted with systemd as init system (PID 1). Can't operate.
Failed to connect to bus: Host is down
Setting up qemu-system-data (1:3.1+dfsg-2ubuntu3.5) ...
Setting up qemu-block-extra:amd64 (1:3.1+dfsg-2ubuntu3.5) ...
Setting up qemu-system-common (1:3.1+dfsg-2ubuntu3.5) ...
Setting up qemu-system-arm (1:3.1+dfsg-2ubuntu3.5) ...
Setting up qemu-utils (1:3.1+dfsg-2ubuntu3.5) ...
Processing triggers for man-db (2.8.5-2) ...
inaddy@lenovo:~$

Hmm, still waiting for SRU Team as http://launchpadlibrarian.net/442987366/qemu_1%3A3.1+dfsg-2ubuntu3.4_1%3A3.1+dfsg-2ubuntu3.5.diff.gz

Well, it was a sprint and this isn't super urgent. Give it another week before pinging around :-)

Hello Jesse, or anyone else affected,

Accepted qemu into disco-proposed. The package will build now and be available at https://launchpad.net/ubuntu/+source/qemu/1:3.1+dfsg-2ubuntu3.5 in a few hours, and then in the -proposed repository.

Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation on how to enable and use -proposed. Your feedback will aid us getting this update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested and change the tag from verification-needed-disco to verification-done-disco. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed-disco. In either case, without details of your testing we will not be able to proceed.

Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance for helping!

N.B. The updated package will be released to -updates after the bug(s) fixed by this package have been verified and the package has been in -proposed for a minimum of 7 days.

All autopkgtests for the newly accepted qemu (1:3.1+dfsg-2ubuntu3.5) for disco have finished running.
The following regressions have been reported in tests triggered by the package:

systemd/240-6ubuntu5.7 (armhf, ppc64el)
ubuntu-image/1.7+19.04ubuntu1 (i386)
cinder/2:14.0.0-0ubuntu1 (amd64, i386, armhf, arm64, ppc64el, s390x)

Please visit the excuses page listed below and investigate the failures, proceeding afterwards as per the StableReleaseUpdates policy regarding autopkgtest regressions [1].

https://people.canonical.com/~ubuntu-archive/proposed-migration/disco/update_excuses.html#qemu

[1] https://wiki.ubuntu.com/StableReleaseUpdates#Autopkgtest_Regressions

Thank you!

Some tests got resolved by rerunning them.
Two categories are left:
- cinder is an actual bug in cinder, see bug 1845321
  It is up to the openstack team if they will push a fix soon or if we should add froce-badtest
  But this isn't an issue of the qemu update for sure.
- systemd @ ppc64 never worked
  This is and was known
  ubuntu-release:236:force-badtest systemd/240-6ubuntu5.1/ppc64el systemd/240-6ubuntu5.2/ppc64el
  ubuntu-sru:20:force-badtest systemd/240-6ubuntu5.3/ppc64el
  ubuntu-sru:21:force-badtest systemd/240-6ubuntu5.4/ppc64el
  But it seems somebody let 240-6ubuntu5.7 [1] through without updating it ?!
  So do we stop bumping it nowadays, should we instead accept it as-is and do a non versionined
  override that would avoid having many people run into the same over and over again.
  Interestingly 240-6ubuntu5.7 isn't seen on [2] at all.
  I'll propose it as MP ...
- systemd @ armhf known flaky and recently failing for everyone
  I'll do a few retries, but then we might mask it as well

[1]: https://launchpad.net/ubuntu/+source/systemd/240-6ubuntu5.7
[2]: http://autopkgtest.ubuntu.com/packages/s/systemd/disco/ppc64el

MP for the systemd@ppc64 test at [1].

[1]: https://code.launchpad.net/~paelzer/britney/hints-ubuntu-disco-fix-systemd-ppc-hint-that-never-works/+merge/373200

Testing the version in proposed in WSL

$ sudo apt install qemu-user-static
Reading package lists... Done
Building dependency tree
Reading state information... Done
The following packages will be upgraded:
  qemu-user-static
1 upgraded, 0 newly installed, 0 to remove and 6 not upgraded.
Need to get 13.7 MB of archives.
After this operation, 0 B of additional disk space will be used.
Get:1 http://ppa.launchpad.net/paelzer/bug-1840956-binfmt-containers/ubuntu disco/main amd64 qemu-user-static amd64 1:3.1+dfsg-2ubuntu3.5 [13.7 MB]
Fetched 13.7 MB in 7s (1851 kB/s)
(Reading database ... 31013 files and directories currently installed.)
Preparing to unpack .../qemu-user-static_1%3a3.1+dfsg-2ubuntu3.5_amd64.deb ...
System has not been booted with systemd as init system (PID 1). Can't operate.
Failed to connect to bus: Host is down
Unpacking qemu-user-static (1:3.1+dfsg-2ubuntu3.5) over (1:3.1+dfsg-2ubuntu3.5~ppa1) ...
Setting up qemu-user-static (1:3.1+dfsg-2ubuntu3.5) ...
System has not been booted with systemd as init system (PID 1). Can't operate.
Failed to connect to bus: Host is down
Processing triggers for man-db (2.8.5-2) ...
ubuntu@LAPTOP-B2T4QCSH:~$ echo $?
0

Works as expected, issue fixed.

Xenial is facing same/similar issue for qemu-user-static being installed into LXD aarch64 (possibly for other arches as well).

----
The following NEW packages will be installed:
  binfmt-support qemu-kvm qemu-user-static
0 upgraded, 3 newly installed, 0 to remove and 0 not upgraded.
Need to get 5678 kB of archives.
After this operation, 68.4 MB of additional disk space will be used.
Get:1 http://ports.ubuntu.com/ubuntu-ports xenial/main arm64 binfmt-support arm64 2.1.6-1 [44.5 kB]
Get:2 http://ports.ubuntu.com/ubuntu-ports xenial-updates/main arm64 qemu-kvm arm64 1:2.5+dfsg-5ubuntu10.41 [6484 B]
Get:3 http://ports.ubuntu.com/ubuntu-ports xenial-updates/universe arm64 qemu-user-static arm64 1:2.5+dfsg-5ubuntu10.41 [5627 kB]
Fetched 5678 kB in 3s (1434 kB/s)
Selecting previously unselected package binfmt-support.
(Reading database ... 47223 files and directories currently installed.)
Preparing to unpack .../binfmt-support_2.1.6-1_arm64.deb ...
Unpacking binfmt-support (2.1.6-1) ...
Selecting previously unselected package qemu-kvm.
Preparing to unpack .../qemu-kvm_1%3a2.5+dfsg-5ubuntu10.41_arm64.deb ...
Unpacking qemu-kvm (1:2.5+dfsg-5ubuntu10.41) ...
Selecting previously unselected package qemu-user-static.
Preparing to unpack .../qemu-user-static_1%3a2.5+dfsg-5ubuntu10.41_arm64.deb ...
Unpacking qemu-user-static (1:2.5+dfsg-5ubuntu10.41) ...
Processing triggers for man-db (2.7.5-1) ...
Processing triggers for ureadahead (0.100.0-19.1) ...
Processing triggers for systemd (229-4ubuntu21.22) ...
Setting up binfmt-support (2.1.6-1) ...
update-binfmts: warning: unable to open /proc/sys/fs/binfmt_misc/status for writing: Permission denied
update-binfmts: warning: unable to open /proc/sys/fs/binfmt_misc/register for writing: Permission denied
update-binfmts: warning: unable to enable binary format python3.5
Job for binfmt-support.service failed because the control process exited with error code. See "systemctl status binfmt-support.service" and "journalctl -xe" for details.
invoke-rc.d: initscript binfmt-support, action "start" failed.
● binfmt-support.service - Enable support for additional executable binary formats
   Loaded: loaded (/lib/systemd/system/binfmt-support.service; enabled; vendor preset: enabled)
   Active: failed (Result: exit-code) since Sun 2019-09-29 09:54:54 UTC; 30ms ago
     Docs: man:update-binfmts(8)
  Process: 16763 ExecStart=/usr/sbin/update-binfmts --enable (code=exited, status=2)
 Main PID: 16763 (code=exited, status=2)

Sep 29 09:54:54 xenial systemd[1]: Starting Enable support for additional executable binary formats...
Sep 29 09:54:54 xenial update-binfmts[16763]: update-binfmts: warning: unable to open /proc/sys/fs/binfmt_misc/status for writing:... denied
Sep 29 09:54:54 xenial update-binfmts[16763]: update-binfmts: warning: unable to open /proc/sys/fs/binfmt_misc/status for writing:... denied
Sep 29 09:54:54 xenial update-binfmts[16763]: update-binfmts: warning: unable to open /proc/sys/fs/binfmt_misc/register for writin... denied
Sep 29 09:54:54 xenial update-binfmts[16763]: update-binfmts: exiting due to previous errors
Sep 29 09:54:54 xenial systemd[1]: binfmt-support.service: Main process exited, code...

For LXD case, having:

config:
  boot.autostart: "false"
  raw.lxc: |-
    lxc.mount.auto = proc:rw

Might mitigate the issue, allowing /proc/sys/fs/binfmt_misc to be updated by lxd container. Since this is not default, possible SRU would be to detect lxd container in qemu-user-static installation just like it was done for the WSL case.

This bug was fixed in the package qemu - 1:3.1+dfsg-2ubuntu3.5

---------------
qemu (1:3.1+dfsg-2ubuntu3.5) disco; urgency=medium

  * d/binfmt-update-in: fix binfmt usage in some containers (LP: #1840956)

 -- Christian Ehrhardt <email address hidden> Mon, 09 Sep 2019 10:59:15 +0200

The verification of the Stable Release Update for qemu has completed successfully and the package is now being released to -updates. Subsequently, the Ubuntu Stable Release Updates Team is being unsubscribed and will not receive messages about this bug report. In the event that you encounter a regression using the package from -updates please report a new bug using ubuntu-bug and tag the bug report regression-update so we can easily find any regressions.

TBH - unless someone out there "really" is affected by it I'm considering "qemu-user-static on aarch64 on LXD on Xenial" too much of a special case to bother the SRU team with it.

I could keep states as-is, but to reflect that I'd think we should set it to Won't Fix unless someone speaks up about this being more important for Ubuntu than I think atm.

While the fix allows one to configure qemu-user-static, it prevents the installation of the binary formats. In WSL Debian Buster on Windows 10 Pro Build 18363.535, I managed to install the formats by changing the value of --fix-binary from yes to no. I think this eventually should be fixed in WSL, see https://github.com/Microsoft/WSL/issues/2103.

Interesting, thanks for the link to that WSL issue Malte

FWIW, it looks to me that this issue is ought to be fixed in binfmt package, not in all of its users.. This is a general issue for containers, not only qemu is affected