Windows Subsystem for Linux (on a restricted environment)
I work as a web developer for the School of Interactive Games and Media at the Rochester Institute of Technology. As a team lead I manage our two projects in PHP and handle numerous merge requests per week. As it currently stands, the lab computers (which we all work on) have Windows installed, which is (particularly for PHP development) a less than ideal environment. The git solution we have used is the official Git Bash distribution, which is occasionally buggy and slower than a traditional Linux environment. Additionally, newer versions of PHP have conflicts with the installed C++ runtime on the lab machines. Therefore, I requested (and was granted) the ability to install Windows Subsystem for Linux on a subset of lab machines that we use for work.
Windows Subsystem for Linux is a true Linux kernel along with a choice of GNU/Linux system, wrapped (for v1) or modified (for v2) to interact with the Windows kernel. In v1, the version we use, a pure Linux kernel is shipped and wrapped with Windows function calls to avoid the need to open-source the distribution, however for version 2 (which is, at this time, in preview) Microsoft open-sourced their distribution to comply with the GPL. In order to enable WSL, the following powershell command must be issued:
Microsoft encourages you to install images from the Microsoft Store, however, the Store does not function properly on the lab machines, and I needed to keep all data on a secured hard drive (as all users have administrative access to all machines). I was able to download my distribution of choice (Ubuntu 18.04) from Microsoft's website, and there are several others to choose from. Although the files ship as a .Appx file, these are truly zip files and can be extracted anywhere on the system (executing the Appx installs the package within Windows).
Unpackaging the zip file reveals several files of particular note:
After installation, the distribution can be used as a traditional GNU/Linux system, with few caveats (such as hardware issues and general slowness).
On one occasion, I ran into a perplexing issue - I mounted an SD card before mounting my hard drive, giving the hard drive the letter J instead of E. When I went to launch my distribution, the window immediately exited with no notification of what went on.
After reinstalling and seeing that everything worked, I was curious why I needed to reinstall the entire system after a seemingly meaningless change to the path. And it was only later, when I launched the distribution from Visual Studio Code without giving the path to the executable, that I realized what had happened - Windows stored a global registry of the path to each WSL distribution, and was crashing when the paths didn't match.
I found two ways to mitigate this issue - either by using the wsl command to unregister the distribution (wsl --unregister <DistributionName>) or by editing the registry key HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Lxss\<uuid of distribution>\BasePath.
Windows Subsystem for Linux is a true Linux kernel along with a choice of GNU/Linux system, wrapped (for v1) or modified (for v2) to interact with the Windows kernel. In v1, the version we use, a pure Linux kernel is shipped and wrapped with Windows function calls to avoid the need to open-source the distribution, however for version 2 (which is, at this time, in preview) Microsoft open-sourced their distribution to comply with the GPL. In order to enable WSL, the following powershell command must be issued:
Enable-WindowsOptionalFeature -Online -FeatureName Microsoft-Windows-Subsystem-Linux
After enabling the command, a restart must be performed in order to finalize installation (this is why we could not enable WSL on our own - the lab machines are reimaged on each restart).Microsoft encourages you to install images from the Microsoft Store, however, the Store does not function properly on the lab machines, and I needed to keep all data on a secured hard drive (as all users have administrative access to all machines). I was able to download my distribution of choice (Ubuntu 18.04) from Microsoft's website, and there are several others to choose from. Although the files ship as a .Appx file, these are truly zip files and can be extracted anywhere on the system (executing the Appx installs the package within Windows).
Unpackaging the zip file reveals several files of particular note:
- ubuntu1804.exe (or the distribution's exe) - The system executable
- install.tar.gz - The compressed filesystem storage
- rootfs (once the executable is run) - The root filesystem
After installation, the distribution can be used as a traditional GNU/Linux system, with few caveats (such as hardware issues and general slowness).
On one occasion, I ran into a perplexing issue - I mounted an SD card before mounting my hard drive, giving the hard drive the letter J instead of E. When I went to launch my distribution, the window immediately exited with no notification of what went on.
After reinstalling and seeing that everything worked, I was curious why I needed to reinstall the entire system after a seemingly meaningless change to the path. And it was only later, when I launched the distribution from Visual Studio Code without giving the path to the executable, that I realized what had happened - Windows stored a global registry of the path to each WSL distribution, and was crashing when the paths didn't match.
I found two ways to mitigate this issue - either by using the wsl command to unregister the distribution (wsl --unregister <DistributionName>) or by editing the registry key HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Lxss\<uuid of distribution>\BasePath.
Comments
Post a Comment