misc/cgo/testcshared: 1.8rc1 build from source fails on Yakkety on testcshared #18611

Closed
karalabe opened this Issue Jan 11, 2017 · 6 comments

Projects

None yet

3 participants

@karalabe
Contributor
$ git rev-parse HEAD
3de6e96e4b8147f5267a2e8218a7c780b09a434f

Build log: https://gist.github.com/karalabe/4bb005aec52ea941ac1cdfd8be867695

@bradfitz bradfitz changed the title from 1.8rc1 build from source fails on Yakkety on testcshared to misc/cgo/testcshared: 1.8rc1 build from source fails on Yakkety on testcshared Jan 11, 2017
@bradfitz bradfitz added this to the Go1.8 milestone Jan 11, 2017
@ianlancetaylor
Contributor

Looks like your env program is not behaving as expected. Assuming you use bash as your shell, what does type env print?

@bradfitz
Member

Trying to reproduce in a Yakkety Docker container, I also see:

--- FAIL: TestCloneNEWUSERAndRemapRootDisableSetgroups (0.00s)
        exec_linux_test.go:81: Cmd failed with err fork/exec /usr/bin/whoami: operation not permitted, output: 
--- FAIL: TestCloneNEWUSERAndRemapRootEnableSetgroups (0.00s)
        exec_linux_test.go:81: Cmd failed with err fork/exec /usr/bin/whoami: operation not permitted, output: 
--- FAIL: TestEmptyCredGroupsDisableSetgroups (0.00s)
        exec_linux_test.go:129: fork/exec /usr/bin/whoami: operation not permitted
--- FAIL: TestUnshare (0.00s)
        exec_linux_test.go:177: Cmd failed with err fork/exec /bin/cat: operation not permitted, output: 
--- FAIL: TestGroupCleanupUserNamespace (0.00s)
        exec_linux_test.go:238: Cmd failed with err fork/exec /usr/bin/id: operation not permitted, output: 
FAIL
FAIL    syscall 0.074s
@bradfitz
Member

Actually, those failures I hit are only because I was running as root in a privileged container.

But after fixing that, I'm unable to reproduce this bug. Running all.bash passes for me in a Yakkety container.

Removing Go 1.8 milestone, waiting for info.

@bradfitz bradfitz modified the milestone: Go1.9Maybe, Go1.8 Jan 11, 2017
@karalabe
Contributor

@ianlancetaylor Good catch. evn actually pointed to a binary within my GOPATH bin. If I replace/delete that, everything works fine with building Go. My curiosity now is how did an env get into my GOPATH in the first place. Looking at it in a hex editor, it's definitely a Go binary. Anyway, this issue is unrelated to the Go repository anymore. Closing. Thanks!

@karalabe karalabe closed this Jan 12, 2017
@ianlancetaylor
Contributor

We could consider setting PATH to start with /bin:/usr/bin, but that would bug people who specifically set their PATH differently to run different tools. I guess best choice is to leave as is.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment