Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

setarch: i386: Unrecognized architecture #4

Closed
jackusm opened this issue Jan 31, 2017 · 4 comments
Closed

setarch: i386: Unrecognized architecture #4

jackusm opened this issue Jan 31, 2017 · 4 comments
Assignees
Labels

Comments

@jackusm
Copy link

jackusm commented Jan 31, 2017

Trying to run the container I get this error and it exits

@jackusm
Copy link
Author

jackusm commented Feb 1, 2017

Not sure if there's a 'proper' way to have this work but adding --security-opt=seccomp=unconfined to the docker command works.

@bencawkwell bencawkwell self-assigned this Feb 1, 2017
@bencawkwell
Copy link
Owner

Thanks for reporting this, and adding a temporary workaround. Can you please just confirm which version of docker you are using, and if you made any changes to the Dockerfile?

@bencawkwell bencawkwell added the bug label Feb 1, 2017
@jackusm
Copy link
Author

jackusm commented Feb 1, 2017

I set to use XPRA and GITWATCH other than that no changes.
Docker version 1.12.6, build 78d18021ec

@bencawkwell
Copy link
Owner

So I have done some research, and discovered that there is something called Seccomp security profiles for Docker (https://docs.docker.com/engine/security/seccomp/). The reason I am unable to reproduce this issue myself is because I run a build of docker that most probably was not built with seccomp.

I discovered this from http://www.bay12forums.com/smf/index.php?topic=145944.245;wap2, which mentions that "personality" is one of the system calls being blocked by default. This page also mentions the same workaround, to add --security-opt=seccomp=unconfined to the docker command.

Right now I can think of two choices:

  1. Document this workaround with an explanation in the README.
  2. Provide my own seccomp profile, based on https://github.com/docker/docker/blob/master/profiles/seccomp/default.json but with changes that permit the system calls required.

Looking at other projects that have run into a similar issue (jlund/docker-chrome-pulseaudio#8, and https://github.com/solita/docker-systemd) we see one of the above choices being used.

Option number 2 to me does not sound feasible in the long term, so for now I think the best option is to document the workaround. Hopefully as this feature becomes more common a better method to enable certain system calls for Dockerfiles turns up.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

2 participants