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

build: set up WSL Windows Subsystem For Linux (Linux-on-Windows) builder #17365

Open
quentinmit opened this issue Oct 6, 2016 · 28 comments

Comments

@quentinmit
Copy link
Contributor

commented Oct 6, 2016

Even if it's not a first-class port, it's useful to know if/how it's broken.

@quentinmit quentinmit added the NeedsFix label Oct 6, 2016

@quentinmit quentinmit added this to the Go1.9Early milestone Oct 6, 2016

@quentinmit quentinmit self-assigned this Oct 6, 2016

@bradfitz bradfitz added the Builders label Oct 6, 2016

@bradfitz

This comment has been minimized.

Copy link
Member

commented Oct 6, 2016

I'd prefer a Windows 10 builder (or "Windows Server 2016") first, which we don't even have.

But it's not offered on GCE yet: https://cloud.google.com/compute/docs/instances/windows/#windows_server (only 2008 and 2012).

So unless we want to run builders on Azure or our Mac VMWare cluster, this is blocked for now.

@quentinmit

This comment has been minimized.

Copy link
Contributor Author

commented Oct 18, 2016

@bradfitz
Windows Server 2016 is now available on GCE

@quentinmit

This comment has been minimized.

Copy link
Contributor Author

commented Oct 18, 2016

However, more relevantly for this bug, Windows Server 2016 does not support Linux on Windows yet.

@quentinmit

This comment has been minimized.

Copy link
Contributor Author

commented Oct 20, 2016

I ran ./run.bash -no-rebuild and the output is attached here. Obviously, we have a ways to go. @aclements thinks many of the failures may be due to our signal handling, where we apparently modify siginfo_t and expect that to control where we return from the signal handler.
go-run.txt

@bradfitz

This comment has been minimized.

Copy link
Member

commented Oct 20, 2016

"We" don't have a ways to go. We target Linux.

@ianlancetaylor

This comment has been minimized.

Copy link
Contributor

commented Oct 20, 2016

Yes, what we do is modify the stack to look like a call to runtime.sigpanic, and then set the stack pointer and PC in the ucontext_t structure passed to the signal handler. When we return from the signal handler, we expect that to execute the sigreturn system call which should then re-enter the user program with the stack pointer and PC set to the values in the ucontext_t (on some systems we execute sigreturn directly). On tip this is done in sigctxt.preparePanic, which has CPU-specific versions in signal_GOARCH.go and for modifying the ucontext_t struct relies on support in signal_GOOS_GOARCH.go.

Looking at your log that is at least partially working. I see that the signal handler is indeed returning to sigpanic as it should. What seems to be failing is that g.sigcode0 does not have the expected value in sigpanic. That field is set from the si_code field of the siginfo_t passed to the signal handler. If you want to pursue this further, change sigpanic to print out the g.sigcode0 field.

@quentinmit

This comment has been minimized.

Copy link
Contributor Author

commented Oct 21, 2016

@bradfitz: Agreed, this is mostly Microsoft's problem, not ours. I think we should have the goal of Go running on Linux-on-Windows, and we should invest (some) time in debugging problems with that configuration. If the problem is caused by our code, we should change our code. If the problem is a bug in the Windows kernel, we should file a bug upstream and not work around it in Go. Likely most/all of the test failures are kernel bugs, but we should at least do the debugging to find out what the kernel bugs are so we can file issues upstream.

@bradfitz

This comment has been minimized.

Copy link
Member

commented Oct 22, 2016

If the problem is caused by our code, we should change our code.

I think by definition is can not be a problem with our code, ever.

Microsoft has committed to emulating Linux, which isn't a spec. We're targeting Linux, not a spec. If our Linux builders are passing, it's not our fault.

So the onus is on Microsoft to forever play catch-up and react to Linux differences.

But I agree we can help report bugs to Microsoft, and it would be nice to see it work.

@peterGo

This comment has been minimized.

@bradfitz

This comment has been minimized.

Copy link
Member

commented Feb 21, 2017

@peterGo, I don't care about their marketing department. They implement the Linux system calls. There's nothing specific to Ubuntu here other than marketing.

@bradfitz

This comment has been minimized.

Copy link
Member

commented Apr 30, 2017

Update: we have Windows Server 2016 builders now. Maybe this is easier with that?

Or maybe we need to wait for the Nano server builders? #15287

/cc @johnsonj

@quentinmit

This comment has been minimized.

Copy link
Contributor Author

commented May 1, 2017

@bradfitz My understanding is that Linux-on-Windows is not yet available for Windows Server 2016, because it's "not intended for server use".

@bradfitz

This comment has been minimized.

Copy link
Member

commented May 1, 2017

Hah. Interesting.

@johnsonj

This comment has been minimized.

Copy link
Member

commented May 1, 2017

src

I wonder if there's a workaround to enable the feature? I'm not sure if we can run desktop SKUs on GCP.

@johnsonj

This comment has been minimized.

Copy link
Member

commented May 13, 2017

And now that's going to change: WSL on Windows Server

@bradfitz

This comment has been minimized.

Copy link
Member

commented May 13, 2017

Hah... I asked @bitcrazed about this at OSCON on Wednesday about an hour before this was announced. Props to Rich for managing to not spill the beans.

@bitcrazed

This comment has been minimized.

Copy link

commented May 16, 2017

Lol 😀 Thanks! Just for clarity though, WSL on server is just for admin tasks, not for production server workloads.

@bradfitz

This comment has been minimized.

Copy link
Member

commented May 16, 2017

@bitcrazed, yes, I heard the warning at your talk that y'all are apprehensive of people of using WSL on Server and judging its I/O performance going through layers atop NTFS.

But for running builders, we don't really care about speed much. We're mostly curious whether the Go Linux build runs on WSL unmodified, and so we can file bugs against WSL if not. That's neither an admin task nor a production server workload, but I think qualifies as a valid use.

@bradfitz bradfitz changed the title build: set up Linux-on-Windows builder build: set up WSL Windows Subsystem For Linux (Linux-on-Windows) builder Aug 9, 2017

@bradfitz

This comment has been minimized.

Copy link
Member

commented Aug 9, 2017

As of today we can run WSL on Windows Server:
https://blogs.windows.com/buildingapps/2017/08/08/windows-subsystem-linux-windows-server/

(Our builders on GCE use Windows Server 2008, 2012, and 2016)

@johnsonj, want to own this bug to setup WSL builders?

@johnsonj

This comment has been minimized.

Copy link
Member

commented Aug 9, 2017

@johnsonj

This comment has been minimized.

Copy link
Member

commented Aug 9, 2017

We'll need to wait till build 16215+ hits GCE which is currently in the insiders ring. I'll snooze this till Sept and see if it's landed by then.

@johnsonj

This comment has been minimized.

Copy link
Member

commented Oct 11, 2017

Unavailable on GCE, current build is 14393 on Server 2016 image built on 9/16. Snooze till January.

@johnsonj

This comment has been minimized.

Copy link
Member

commented Apr 2, 2018

WSL is now available on GCE as the windows-1709-core family (proof) so this is now possible.

@bradfitz

This comment has been minimized.

Copy link
Member

commented Apr 2, 2018

We wouldn't want to "wsl pull ubuntu" (or whatever the operation is to download a distro) on every build, so I guess we'd want to get ubuntu once in the Powershell that creates the image, eh?

@johnsonj

This comment has been minimized.

Copy link
Member

commented Apr 2, 2018

ACK- The baked image should have the desired distro(s) installed (~5 mins) and I think the Linux(!) stage0 setup to start on boot.

The image is different enough from the existing windows build that its probably a different environment all together. windows-linux, windows-wsl, linux-windows?

@alexbrainman

This comment has been minimized.

Copy link
Member

commented Apr 3, 2018

@bradfitz and @johnsonj sorry to hijack this thread, but I want to ask you if current windows Go builders have SSD installed. I have 2 similar laptops with WIndows 10 - one with SSD and one without. I noticed that SSD makes laptop boot much faster, and makes computer usable quicker after reboot. Laptop without SSD always have CPU 0%, but Disk usage of around 100% well after reboot. Perhaps SSD might make our builders faster. Perhaps builders do not reboot, and reboot speed is not important.

Alex

@johnsonj

This comment has been minimized.

Copy link
Member

commented Apr 3, 2018

It looks like all of the buildlets use persistent SSD disks which are network attached but generally fast (see this table and use 32GB as a disk size). It is possible to use a local SSD which has a significantly higher IOPS but it'd take some profiling to determine if it's worth it for the short lived tasks as there's an overhead of formatting the disk after it's attached.

@bitcrazed

This comment has been minimized.

Copy link

commented Apr 5, 2018

@bradfitz You may find these docs useful: https://docs.microsoft.com/en-us/windows/wsl/install-on-server

Please let @tara-raj know if you bump into any unexpected WSL issues.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
7 participants
You can’t perform that action at this time.