My LXC containers do not start, any of you knowledgeable people know why?
Your insights would be greatly appreciated; also when they do not directly offer a solution, but point me in a direction instead for me to further read-up and learn from.
For now I am totally stumped.. after 2 days of online searching:
Context:
HW: Raspberry Pi 1B (700Mhz-512MB)
OS: Raspbian Jessie Light (Debian based)
LXC: 1:1.0.6-6+deb8u2 (from Raspbian repo)
Container: Debian jessie armhf/armel (tried both archs)
Symptoms
stdout (cli output after trying to start the container as root):
root@raspberrypi:~# lxc-start --name debian8 -d
lxc-start: The container failed to start.
lxc-start: To get more details, run the container in foreground mode.
lxc-start: Additional information can be obtained by setting the --logfile and --logpriority options.
log (excerpt):
lxc-start 1471983006.471 ERROR lxc_seccomp - Error loading the seccomp policy
lxc-start 1471983006.479 ERROR lxc_sync - invalid sequence number 1. expected 4
lxc-start 1471983006.479 ERROR lxc_start - failed to spawn 'debian8'
So it looks like that the root cause of the container not starting lies with lxc-start running into an error while trying to load the lxc_seccomp policy. This assumption is backed up by the workaround:
Workaround
Disable the seccomp configuration loading at startup, by commenting it out in /usr/share/lxc/config/debian.common.conf
:
# Blacklist some syscalls which are not safe in privileged
# containers
# lxc.seccomp = /usr/share/lxc/config/common.seccomp
Than the container starts.. But turning off such a basic security setting that is - moreover - so heavily tied to containerization/sandboxing, is (to say the least) kind of defeating the purpose of LXC. From a security/stability point of view I would very much like to keep blacklisting most of the system calls when running the LXC containers on my Rpi (as configured by LXC defaults in /usr/share/lxc/config/common.seccomp
):
2
blacklist
[all]
kexec_load errno 1
open_by_handle_at errno 1
init_module errno 1
finit_module errno 1
delete_module errno 1
Hypotheses
- root cause of ´the container not starting´ lies with the ´lxc-start´ process running into an error while trying to load the ´lxc_seccomp policy´.
lxc_sync - invalid sequence number 1. expected 4
is that error.
Questions
Main
- Why doesn't the LXC container start?
Subs
- Are the aforementioned explanation hypotheses valid?
- Why can't the seccomp config be loaded (any deeper logging available)?
- What does
lxc_sync - invalid sequence number 1. expected 4
technically mean in this context? - Am I looking at a fundamental / difficult to solve problem (arm6) here (e.g. unsolvable without manually modifying kernels etc.)?
- What are my chances when switching to Docker system (higher level virtualization build on top of LXC)?
- What are my chances when using Raspberry Pi 3 (arm7+)?
You guys/gals are my last hope. So any insight would be greatly valued!
If any more data/local-actions is/are required to advance with this issue, please let me know, for I am more than willing to pick it up!
CONFIG_SECCOMP
is set on the stock Raspbian kernel, although I notice two other options that are set on a default configured x86-64 kernel aren't:CONFIG_HAVE_ARCH_SECCOMP_FILTER
andCONFIG_SECCOMP_FILTER
. The latter depends upon the former and the former is auto-selected by the architecture, so if it's required, then you are probably out of luck. – goldilocks♦ Aug 24 '16 at 15:19make defconfig
which is used implicitly if youmake config
(ormenuconfig
, or whatever); those actually exist per architecture and you can find them, e.g., in[src]/arch/x86/configs/
. The Pi kernel has a few of its own. Not they aren't necessarily what stock distro kernels use. – goldilocks♦ Aug 25 '16 at 11:09SECCOMP
actually isn't in the x86-64 one (which is in the x86 directory, BTW;arch/x86_64
is mostly an empty placeholder) so (not that it matters much) I must have selected it at some point -- technically that's not a "default configured" kernel, its custom rolled, but since I don't recall needing that for anything I presumed it was derived from the defconfig. If I noticed it at some point there's a good chance I would have added it based on the description. – goldilocks♦ Aug 25 '16 at 11:09