lxc_start - Exec format error - failed to exec /sbin/init

[windowsguy]

I have an up to date Ubuntu 14.04. I followed the guide at https://help.ubuntu.com/lts/serverguide/lxc.html

sudo apt-get install lxc && sudo lxc-create --template download --name u1

- Choose ubuntu-vivid-armhf, then:
sudo lxc-start --name u1 --daemon

      lxc-start 1416996721.249 INFO lxc_apparmor - changed apparmor profile
to lxc-container-default
      lxc-start 1416996721.249 NOTICE lxc_start - exec'ing '/sbin/init'
      lxc-start 1416996721.253 ERROR lxc_start - Exec format error - failed to exec /sbin/init
      lxc-

$ sudo lxc-ls --fancy
NAME STATE IPV4 IPV6 AUTOSTART
------------------------------------
u1 STOPPED - - NO

$ sudo lxc-checkconfig
Kernel configuration not found at /proc/config.gz; searching...
Kernel configuration found at /boot/config-3.13.0-24-generic
--- Namespaces ---
Namespaces: enabled
Utsname namespace: enabled
Ipc namespace: enabled
Pid namespace: enabled
User namespace: enabled
Network namespace: enabled
Multiple /dev/pts instances: enabled

--- Control groups ---
Cgroup: enabled
Cgroup clone_children flag: enabled
Cgroup device: enabled
Cgroup sched: enabled
Cgroup cpu account: enabled
Cgroup memory controller: enabled
Cgroup cpuset: enabled

--- Misc ---
Veth pair device: enabled
Macvlan: enabled
Vlan: enabled
File capabilities: enabled

Note : Before booting a new kernel, you can check its configuration
usage : CONFIG=/path/to/config /usr/bin/lxc-checkconfig

Except apt-get update and apt-get upgrade I didn't install any other packages (okay, I installed vim and git).

[windowsguy (something-f)]

In case it wasn't clear I followed instructions for "basic privileged usage". not user namespaces.

[windowsguy (something-f)]

$ sudo ls -lisa /var/lib/lxc/u1/rootfs/sbin/init
541928 0 lrwxrwxrwx 1 root root 7 Nov 19 23:17 /var/lib/lxc/u1/rootfs/sbin/init -> upstart
$ sudo ls -lisa /var/lib/lxc/u1/rootfs/sbin/upstart
541969 220 -rwxr-xr-x 1 root root 223596 Nov 19 23:17 /var/lib/lxc/u1/rootfs/sbin/upstart

[windowsguy (something-f)]

$ sudo file /var/lib/lxc/u1/rootfs/sbin/upstart
/var/lib/lxc/u1/rootfs/sbin/upstart: ELF 32-bit LSB shared object, ARM, EABI5 version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.32, BuildID[sha1]=401fd3761e2edac12fc6081bebbfd834a985e11b, stripped

[Serge Hallyn (serge-hallyn)]

Hi,

thanks for submitting this bug. Is your host architecture armhf? If not,
then when using the download template you'll need to manually install
qemu-user-static on the host, and copy /usr/bin/qemu-arm-static into
the container's rootfs. The easier way to create such a container,
currently, is still using the ubuntu template, which will link the
qemu-user binary into your container for you.

 status: incomplete

[windowsguy (something-f)]

No my arch is amd64, that's why I specified "-a armhf".
I know about qemu (I wasn't sure whether to use static or binfmt), but errors should be meaningful, instead it seems as if lxc is working fine, but in fact it's not. Obviously it's not a matter of permissions, so the error is wrong.

The image I used is downloaded from debian.org, so I didn't prepare it myself.
Either non-armhf hosts shouldn't list armhf images or should warn (maybe in documentation, if not in code) that those aren't usable without additional packages.

[Stéphane Graber (stgraber)]

I agree it'd be nice for the download template to be clever and filter its output. However the fact that it's very very difficult to know what your CPU is actually capable of running (especially for arm64, armel, armhf and powerpc, powerpc64 and ppc64el) and the name for the architectures changes between distributions too.

So for now, we expect our users to know what architecture their CPU is capable of running and then select something which has a chance to work.

Marking bug report as low priority wishlist.

[Stéphane Graber (stgraber)]

We've not seen any other issue like this in the past 5 years, users usually know to pick something that they can actually run or know that they'll need to setup emulation.

The error reported as weird as it is, is the expected behavior from the kernel when asked to run a foreign architecture binary, so no obvious bug to fix here nor really a way for LXC to distinguish that case from an actual permission issue.