Bug 1261541 - Docker FTBFS on ppc64 and s390x due to undefined SYS_SETNS
Summary: Docker FTBFS on ppc64 and s390x due to undefined SYS_SETNS
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Fedora
Classification: Fedora
Component: docker
Version: 23
Hardware: Unspecified
OS: Linux
unspecified
unspecified
Target Milestone: ---
Assignee: Matthew Heon
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Keywords:
Depends On:
Blocks: ZedoraTracker PPCTracker
TreeView+ depends on / blocked
 
Reported: 2015-09-09 15:10 UTC by Jakub Čajka
Modified: 2016-02-16 17:24 UTC (History)
14 users (show)

(edit)
Clone Of:
(edit)
Last Closed: 2016-02-16 17:24:13 UTC


Attachments (Terms of Use)
Proposed fix (705 bytes, patch)
2015-09-09 15:10 UTC, Jakub Čajka
no flags Details | Diff

Description Jakub Čajka 2015-09-09 15:10:51 UTC
Created attachment 1071812 [details]
Proposed fix

Hello, would it be possible to include attached patch fixing up mentioned issue?

It contains definition of "SYS_SETNS" constant for s390x(from netns upstream) and in addition also for ppc64.

Latest version of netns was included in upstream commit https://github.com/docker/docker/commit/eecf6cd48cf7c48f00aa8261cf431c87084161ae, but only on master(also it lacks ppc64).

Failed builds:
http://ppc.koji.fedoraproject.org/koji/taskinfo?taskID=2734887
http://s390.koji.fedoraproject.org/koji/taskinfo?taskID=1947612

Note that build on ppc64 fails with one more error, looking in to it now and I will open separate BZ for that issue.

Comment 1 laboger 2015-09-10 15:56:07 UTC
The const SYS_SETNS is defined in the syscall package.  It should be referenced as syscall.SYS_SETNS, or change the way syscall is imported.  I tried both of these examples with gccgo and they compiled successfully:

Example 1:
package main

import (
        "fmt"
        . "syscall"
)

func main() {
    fmt.Printf("Hello, World: %d\n", SYS_SETNS)
}

Example 2:
package main

import (
        "fmt"
        "syscall"
)

func main() {
    fmt.Printf("Hello, World: %d\n", syscall.SYS_SETNS)
}

The problem related to mismatched data types is discussed in https://github.com/golang/go/issues/12124.  I talked to the person here who is working on submission of this fix to Docker and she said they are still waiting for it to be accepted.

She has a branch with the fix in at https://github.com/clnperez/runc/tree/power-ci-main.

Comment 2 clnperez 2015-09-10 20:15:03 UTC
If you want to open a seperate BZ for the mismatched data types issue, we can move this conversation there. 

In the meantime, here are the two patches you can cherry-pick into a runc branch to build with (and change the runc line in your hack/vendor.sh):

Merged upstream, but not in the runc version docker has in its vendor.sh
https://github.com/opencontainers/runc/commit/
9bc81d16999c324d6c04a3baa124065fc73e3133

Won't be merged upstream, b/c docker plans to move from runc's seccomp to seccomp/libseccomp:
https://github.com/clnperez/runc/commit/a12d6c602066f74723dbf29d32501b523affefad

Comment 3 Daniel Walsh 2015-09-28 18:04:36 UTC
clnperez, so what do you want us to do now?

Comment 4 Matthew Heon 2015-09-28 19:27:56 UTC
Libseccomp support has already landed in Runc and been vendored into Docker, and should be in the upcoming 1.9 release (and rawhide docker-1.9 builds). Given this, both compile failures you note should be solved in the 1.9 release, which I believe will be hitting F22 stable once it's released in late October.

In the meantime: we already carry a patch to strip out Seccomp support from Runc to enable compilation on non-AMD64 architectures, so you shouldn't be seeing build failures from that. I'll see about getting the other patch into our existing 1.8 builds for Fedora.

Comment 5 Peter Robinson 2015-09-29 05:05:25 UTC
> In the meantime: we already carry a patch to strip out Seccomp support from
> Runc to enable compilation on non-AMD64 architectures, so you shouldn't be
> seeing build failures from that. I'll see about getting the other patch into
> our existing 1.8 builds for Fedora.

We have seccomp in ARMv7 and aarch64 so it's likely only needed for PPC64/s390x

Comment 6 Dan Horák 2015-09-30 08:32:51 UTC
s390(x) and ppc64 support are already in libseccomp master branch, so should be just matter of a new libseccomp release. The missing ppc SECCOMP_FILTER kernel support is also merged since 4.2.

Comment 7 Matthew Heon 2015-09-30 13:31:04 UTC
We also have a build flag in Docker/runc upstream (not yet in any releases) to completely remove Seccomp support as well, so systems without a compatible libseccomp can still use both.

Comment 8 Dan Horák 2015-10-15 12:54:01 UTC
Hi, could we get a patched package soon? Currently we are stuck on docker 1.7 for s390 and ppc :-(

Comment 9 Daniel Walsh 2015-10-15 14:23:47 UTC
Dan can we start building docker-1.9?

Comment 10 Matthew Heon 2015-10-15 19:58:12 UTC
Patch is now in the Fedora docker-1.8 tree - sorry for the delay on this.

Next build should contain it.

Comment 11 Dan Horák 2015-10-15 20:02:11 UTC
(In reply to Daniel Walsh from comment #9)
> Dan can we start building docker-1.9?

If this "Dan" is me :-) then I don't see a problem with going to 1.9 in F-23 from the secondary arches point of view. I guess it might be easier to fix possible issues in docker 1.9 than in 1.8.

Comment 12 Peter Robinson 2015-10-16 00:53:13 UTC
(In reply to Dan Horák from comment #11)
> (In reply to Daniel Walsh from comment #9)
> > Dan can we start building docker-1.9?
> 
> If this "Dan" is me :-) then I don't see a problem with going to 1.9 in F-23
> from the secondary arches point of view. I guess it might be easier to fix
> possible issues in docker 1.9 than in 1.8.

Probably a bit late in the cycle for a 1.9 rebase, either way it'll need to be filed (sooner rather than later) as either a blocker or freeze exception to get an update in. Can someone make the decision and file this bug as one or the other RSN.

https://qa.fedoraproject.org/blockerbugs/propose_bug

Comment 13 Daniel Walsh 2015-10-28 14:05:44 UTC
Fixed in docker-1.9.


Note You need to log in before you can comment on or make changes to this bug.