Comment 1 for bug 1555760

I tried to reproduce this with the standard images.linuxcontainers.org trusty container image, on both a wily and a xenial host, but this doesn't happen with obvious steps (otherwise we would have noticed this much earlier already).

From the github issue I take it you are using Ubuntu wily -- which lxd package version do you use? The 0.20-0ubuntu4.1 shipped in Wily or some backport? I tried the wily version and that does not even work any more ("error: json: cannot unmarshal string into Go value of type int64" when trying to list or launch from images:), and there's no newer version in wily-backports.

How exactly did you create the container?

How often does this happen, under the same circumstances? Is this a race condition which only happens sometimes, or is this always reproducible? Can you reproduce this with running

    sudo systemctl stop proc-sys-fs-binfmt_misc.mount
    lxc launch [...]

several times? Stopping proc-sys-fs-binfmt_misc.mount will stop the actual mount and go back to systemd providing a "proxy" mount until the first access.

Please give me the output of "systemctl status proc-sys-fs-binfmt_misc.mount" and "mount | grep binfmt" before and after the failed "lxc launch".

Does it always work after the first failure and after /proc/sys/fs/binfmt_misc actually gets mounted?