Windows Subsystem for Linux / Bash on Ubuntu on Windows

Installing Bash on Ubuntu on Windows while behind a proxy server doesn’t work.

I’m reinstalling Bash on Ubuntu on Windows on my work laptop at home, where I’m not behind the work firewall and the need for the work proxy server.
WSL happily activates and downloads Ubuntu from the Windows store while at work, but once it fires up Ubuntu and starts running Apt to install updates, it chokes, as Ubuntu, and Apt, aren’t configured to use the proxy server. This means I have to cancel the install, which results in a working system, but it doesn’t complete its setup. I can fire up Bash, but it always logs in as root (doesn’t get to the user setup step). Once logged in I can configure Apt to use the proxy, and set the proxy environment and run the apt updates, but it still hasn’t gone through the full install process cleanly. This is a weakness in Microsoft / Canonical’s design. Ubuntu should either inherit the proxy config from Windows, or have a way to configure it in the setup, so it can perform a clean install.
I figured I’d give it a try from home, where it doesn’t need to go through a proxy, and see if it will properly complete the install. This worked perfectly on my personal laptop.

Edited: We have success! The prompt for a username means we got past the blocker seen at work.
Bash on Ubuntu on Windows install username prompt

Xen and the art of server maintenance

Aught to be a good title for a book on Xen, no?

Anyway, while discussing Xen with the COO (and it just occurred to me, really this project should be the CTO’s, not the COOs… odd how the COO does all this stuff…) he came to the conclusion that, like openVZ and Virtuozzo, Xen guest systems shared the kernel with the Host. That didn’t sound right to me, but I couldn’t disprove it with my Xen server, where every DomU had an empty /boot.

So I updated the kernel in Dom0, but didn’t reboot. I now have a newer kernel installed than the one it’s currently running.
I then tweaked the /etc/xen-tools/xen-tools.conf and built a new DomU, to use the new kernel. Everything went without a hitch. I now have a Dom0 running 2.6.18-4-xen-686, with a domU running 2.6.18-6-xen-686. So it would seem that while they all “share” a kernel in the sense that they share a single install on the hard drive (all pulling from the dom0 /boot directory), they aren’t sharing a single instance of the kernel in memory.

I then tried to get a working CentOS 5 domU running, but ran into some snags. That will be another post.