The test is passing on the old-style builders because the GO_BUILDER_NAME environment variable hasn't been set on these builders, so the "moved GOROOT" test is skipped.

I will disable the test, but ideally someone with a plan9 environment should figure out why it is failing. The error suggests that on Plan 9 the default GOROOT is overriding the one computed on the basis of where the cmd/go executable is found.

CL https://golang.org/cl/48650 mentions this issue.

Thanks. I'm currently investigating the issue on my side.

I think I figured out the issue.

In findGOROOT, the os.Executable function returns /bin/go. This is not the command being executed by exec.Command (/tmp/workdir_moved/bin/go), but since I did bind -a /tmp/workdir/bin /bin, this is also a valid path for the go tool (returned by fd2path on /proc/<pid>/text). However, it's not possible to recover the GOROOT from this path.

Since the go tool is called directly from the tests, it should be accessible from the $path environment variable. On Plan 9, $path usually only contains "/bin" and "." and the directories containing binaries are bound to the /bin directory.

I think it would be hard to argue that os.Executable is misbehaving here. /bin/go was run, and it returned /bin/go. findGOROOT is just making assumptions about program lookup that only hold on non-Plan 9 systems. It seems like findGOROOT just fundamentally can't work on Plan 9. Of course if the default builds used some canonical path like /sys/go or even /go, then users who want a different Go could bind their Go onto the canonical path. That might be the way forward if we want to support semi-movable GOROOTs on Plan 9. But I'm going to close this issue - the test failing - as working as intended.