The Windows Subsystem for Linux - which is no longer being referred to officially as "Bash on Windows" - has grown up.

You no longer need to put your Windows 10 system into Developer Mode to use the WSL.

And now there are three different WSLs: Ubuntu, openSUSE and SUSE Linux Enterprise Server. Fedora is supposed to be on the way, but I haven't heard anything about progress toward that happening in a long time.

According to Microsoft, you can copy your current Ubuntu files to /mnt/c/tmp/WSL-backup, or a similar directory, and then use lxrun /install from the Windows command line to remove the old WSL. Then you can install a new WSL and move your files back after that.

Fellow Redditors suggested that I create a tar archive of my files, stow it anywhere, and then unpack it in my new /home directory when I remove the old WSL and install the new one via the Windows Store.

The only thing keeping me from doing it is what always keeps me from switching Linux distros: The need to re-install all of my packages.

The other thing keeping me from making this move is that my laptop hasn't yet received the Windows 10 Fall Creators Update. To successfully install the new WSL, your Windows build needs to be 16215.0 or higher. According to my About Windows 10 page, I'm on 15063.674. So not only can I wait, unless I opt to get the updates early (and I'm sure there is a way to do this), I must wait. And honestly, that doesn't bother me one bit.

Update: (July 4, 2018): Here is my Independence Day update to these instructions. The "original" instructions should work fine, but the "new" ones are better:

The original instructions

Originally I created the tar archive of my home directory in my home directory:

$ tar -zcvf steven.tar.gz /home/steven
$ cp steven.tar.gz /mnt/c/Users/steve/OneDrive/Documents/linux_backup/

And to open it up when your new WSL is set up, go to your home directory:

$ tar -zxvf /path/to/steven.tar.gz

Then you'll have a home directory within your home directory (i.e. for me /home/steven/steven, and you can copy what you want from one to the other). It's better not to overwrite everything in your "new" Linux /home directory because it might handle things in your dot files differently, and I can see conflicts arising from npm modules, ruby gems and whatever else you happened to install in the course of working in your Windows box's Linux side.

I'm not sure how much of a problem it is, but creating the tar archive while in your home directory causes tar to throw the following error:

tar: Removing leading `/' from member names
... (lots of output)
tar: Exiting with failure status due to previous errors

There are explanations of what this error message means on the Internet, but they didn't really help me understand it.

So I did things a different way. If you just want to know how to make the backup and restore it, start here:

The new instructions

First, on the Windows side, create a directory in which to hold this backup. I created one called linux_backup in my OneDrive Documents directory.

Then go into your WSL, which will put you in your home directory on the Linux side (which for me is /home/steven).

From there, to avoid the error message I go up one directory and do the tar operation from there. I use pwd a couple of times to confirm where I am in the filesystem, and I use chown to make sure the restored archive belongs to my Linux user and group.

Note: in all of these instructions, things after a $ are things you type at the command line. Lines that don't begin with a $ represent output in the terminal (and you don't have to type them).

Here is what my terminal session looks like:

$ pwd
/home/steven
$ cd ..
$ pwd
/home
$ sudo tar -zcvf steven.tar.gz steven
$ ls
steven steven.tar.gz
$ chown steven:steven steven.tar.gz
$ sudo cp steven.tar.gz /mnt/c/Users/steve/OneDrive/Documents/linux_backup/

Now you have your tar archive on the Windows side.

After you set up your "new" WSL, you can copy the tar archive from the Windows side into your new Linux /home directory. As before, I use a couple of pwd command to confirm where I am in the Linux filesystem. (And remember, use YOUR home directory and Windows path to your tar archive, not mine):

$ pwd
/home/steven
$ sudo cp /mnt/c/Users/steve/OneDrive/Documents/linux_backup/steven.tar.gz steven.tar.gz
$ sudo chown steven:steven steven.tar.gz
$ tar -zxvf steven.tar.gz
$ ls
steven
$ cd steven
$ pwd
/home/steven/steven

Now you have your "new" home directory at /home/steven, and your "old" files at /home/steven/steven. Copy what you want from old to new, and you should be ready to go.

Once you confirm that all your files are in there, you can blow away the old WSL and use your new one. And you should still have a copy of the tar archive on your Windows filesystem if anything goes wrong.

Before going forward, it's a good idea to read up on how to make a tar.gz archive.

My question (and maybe yours): Why do this from the Ubuntu/WSL shell when you could just copy/paste from the Windows file manager, or why not just copy the files via the Ubuntu shell to the Windows portion of the disk?

Answer (and I did test this): In both cases, even when using Bash to do the recursive cp of all the files, you lose your Linux file permissions. In my case, all of my rw-r--r-- files turned into rwxrwxrwx, which is NOT what you (or I) want.

Update on 4/23/18: This entry was written last October but not published until now. It kind of got lost, and I just found and finished it. Though the new WSL is out, and you can now install Debian (which I would) or SUSE (probably not), I'm leaning toward sticking with Ubuntu because it's working so well, though I'm a longtime Debian fan and user (though not so much lately).

Whatever I do, I probably need to move to the "new" WSL, though I haven't done it yet. Everything is working, so it's hard to muster the motivation to mess with what until now has been a successful installation of Ubuntu in Windows 10.

Update on 7/4/18: The new instructions for making an archive of the /home directory are more detailed and a little more roundabout. But they should work, and tar won't throw any errors.

Also, I still haven't moved to a new WSL. The current Ubuntu WSL is still on 16.04 LTS, and that's the same version as my "old" WSL. When the Ubuntu WSL moves to 18.04 LTS, then it'll be time to make the change.

Microsoft is ticking all of the right boxes with the Windows Subsystem for Linux, announcing that it will be bringing Fedora and OpenSUSE to the WSL as well as offering installation via the Windows Store.

There will also be the option of installing the Ubuntu, Fedora and SUSE version of the WSL at the same time, though it is unclear if they will have separate filesystems, and/or the option of sharing a single Linux filesystem.

I'm not a SUSE user but am a longtime Fedora user, and having the option of Fedora is a very attractive one because it's that much easier to get newer versions of things like Node, Ruby, Java, etc., in this developer-centric distribution that is a lot more stable than you'd think.

As far as installation goes, the current way you get the Ubuntu-powered WSL on your Windows 10 system is more than a little bit hacky, and the use of the Windows Store will make it easier and more inviting for new developers as well as "new" Windows "power users" coming over from years of desktop Linux (like me).

There isn't much in the way of announcements on adding graphical capabilities to the Windows Subsystem for Linux, though Microsoft isn't discouraging those who are already adding an X server to their WSL, but I figure official support for Linux GUI software in the WSL is somewhere on the roadmap.

For now I'm happy to be using a Ubuntu-based system for the first time in a long time (after the aforementioned years of Fedora). As I've written previously, the move from 14.04 to 16.04 was pretty crucial because I was able to get away from the super-old Node.js in 14.04, though the newer Unison required me to pin the old Unison from 14.04 to maintain compatibility with the Unison on my server.

While I've been happy to learn that you can pretty much download a Ubuntu package from the archive and install it with dpkg, I haven't yet experimented with PPAs in the WSL. Might be time for that.

Changing the directory: Since the WSL is rapidly going from a Ubuntu-only offering to one that will offer Fedora and SUSE, I'm changing this directory's name from ubuntu_on_windows to linux_on_windows.

I decided to give the new Microsoft Edge browser a try in Windows 10. When I open it, I get this page that says Google Chrome is 5 percent slower than Edge, and Mozilla Firefox is 9 percent slower.

Four things:

• From my use, I would figure that Chrome is at least 25 percent faster than Firefox.
• The scores are based on Google Octane, which is being mothballed because everybody is cheating with it.
• I'm supposed to get excited about a 5 percent speed improvement? Sharing bookmarks and passwords across Google Chrome instances on Windows 10, Windows 7, Linux and Android is more important than a small speed improvement that may not even be real.
• The more I look at this, saying Chrome is 5 percent slower than Edge doesn't mean that Edge is 5 percent faster than Chrome. Am I right, math and statistics experts? According to my calculations, if Chrome is 5 percent slower than Edge, that means Edge is 19 percent faster than Chrome. Why doesn't Microsoft tout that statistic, which sounds a whole lot better?

Nonetheless, I'm giving the browser a tryout while I'm still using Windows 10.

I am using the unison in Ubuntu 14.04 (Unison 2.40) in my Windows Subsystem for Linux-supplied Ubuntu 16.04 (which updated the package to Unison 2.48) because my server is running Unison 2.40, and I forgot that an apt upgrade will replace the .deb I downloaded from the 14.04 repository with whatever is in 16.04.

When I tried to do a unison sync, I got an error.

How do you put a package "on hold" in Ubuntu? It's easy.

First I removed the "new" unison:

$ sudo apt remove unison

Then I installed my "old" one (which I had previously downloaded from the Ubuntu archive):

$ sudo dpkg -i unison_2.40.102-2ubuntu1_amd64.deb

Now I put the package "on hold":

$ sudo apt-mark hold unison

That's it.

Here is the output now for sudo apt update:

$ sudo apt upgrade
[sudo] password for steven:
Reading package lists... Done
[sudo] password for steven:
Reading package lists... Done
Building dependency tree
Reading state information... Done
Calculating upgrade... Done
The following packages have been kept back:
  unison
0 upgraded, 0 newly installed, 0 to remove and 1 not upgraded.

After a Windows 10 update hosed my laptop and took the Ubuntu/Bash command line (aka the Windows Subsystem for Linux) and all of my scripts along with it, I restored Windows 10 from the laptop's backup partition, and activated the Windows Subsystem for Linux (aka WSL).

This time around I got Ubuntu 16.04 rather than 14.04, which is overall better because there are some really, really old packages in 14.04, including a super-old nodejs. Unfortunately, the old unison in 14.04 matched what is on my server (and unison versions across computers must match, or they don't work).

Luckily I was able to download a 14.04 package from the Ubuntu archive and install it in the 16.04-powered WSL. I restored my scripts, including one I made that is very WSL-specific: It takes all of the files in a Windows directory (usually images, sometimes text documents, but it could be anything), copies them into a working directory in the WSL and uses chmod to change their permissions to 644. That way I can download images while in the web browsers of the Windows world, create text files, working on all of them with Windows tools, and then transfer those files into the Linux side, where I can sync them to the server's filesystem with unison.

Aside: It's not impossible to get a Unix-style ssh program that works from the Windows command line, but it's not at all easy, either. That makes the Windows version of Unison less than useful for working with remote servers.

Now I have scripts in the WSL to:

• Transfer and apply proper permissions to image and text files from Windows to the WSL
• Update this Ode blog using unison to sync files and then reindex the blog via Ode's Indexette
• Create [a static blog archive[(http://stevenrosenberg.net/documents/archive.html) by using a custom Ode theme and a query to return all posts, using curl to bring the html down to the laptop, then copying it into the local Ode filesystem, and then syncing with the server via unison.

I have a feeling I've written about most of these scripts before, and if/when I find those entries, I will link them here. If not (or if there have been updates), I will write them up in the near future.

Why Unison? Unison is a file-synchronization tool. While files can be synced from one system to another with rsync, which I use for backups, the situation with this Ode blog is different. Anthor way to synchronize two filesystem is to use git, the version-control tool.

What unison enables me to do is make changes locally, or on the server, and then reconcile those changes across both systems. So if I write or edit a post on my local filesystem, or make any kind of change on the server, running unison ensures that I have the latest files (and versions of files) on both filesystems. If I used rsync, making changes on the server but running rsync on the client wouldn't work. Git would be great, except that it only reconciles changes in the filesystem that have been checked in. Changes on the server are generally not checked in, and even if I scripted that on the server, Ode (through its Indexette and EditEdit addins) itself makes changes to the filesystem and doesn't check them in. So git wouldn't work.

I came up with unison because it's the easiest. Another alternative csync2 looks a lot harder to figure out. But I do recommend csync2 if you're doing something heavy-duty with more than 2 servers.

When I started looking for this kind of tool, I knew what I needed was a kind of Dropbox for servers. I'm sure there are people who have hacked Dropbox to work on a non-GUI server. Actually that would be a pretty good solution.

The difference with unison is that you have to "consciously" run it to sync the two filesystems. You could run it as a cron job, or somehow set it up as a daemon (which might be how Dropbox works), but for the purposes of this particular blog, syncing when needed works fine.

Using the WSL has provided me the opportunity for the first time in quite a while, to set up unison. It's a great thing to run unison -batch and have the entire blog filesystem copied to an empty directory on my laptop in about a minute. (And then any changes I make on either laptop or server can be synced with another unison -batch, or just unison for a more interactive session. Plus, never underestimate software you can install yourself, on your own computers, and use as you wish. I pay for my shared-hosting service, but otherwise I run whatever software I wish without paying any monthly fees for any of it.

Are there other ways to keep two or more filesystems in sync? I'd sure like to know if there were.

I've always been able to get around in Vim, and before that vi. But it hasn't been my primary editor (except in college, where it was my only editor).

In my Linux systems over the last many years, I've gravitated toward Geany and Gedit, mostly using Geany, and using the terrific Notepad++ on Windows.

Now that I am using the Windows Subsystem for Linux (aka Bash command line supplied by Ubuntu), I have the full range of editors available in the Linux console. For whatever reason or reasons, I'm not an emacs person, and I'm not afraid of modal editing, so Vim it is.

This gives me the opportunity to really learn Vim. Already I'm figuring out things in Vim's command mode, like w taking you from word to word and stopping on the first letter of each word, with e doing the same except stopping on the last letter.

Typing gg in command mode gets you to the top of a file, and G (and also L) gets you to the top of the final line. G$ gets you to the end of the final line.

x deletes a single character, dw deletes a word, dd deletes an entire line and d$ deletes from the cursor to the end of the line.

It's nothing like a "standard" GUI editor, but a lot of it falls right under the fingers. While I have used an adm3a terminal, it's been long enough that I didn't know the reason for using the esc key to change from insert to command mode was the placement of the esc key on the adm3a -- where the "modern" tab would be.

To make it easier to change modes, I don't want to remap tab as esc but could try remapping caps lock as esc, or using ctrl-[, ctrl-c or alt-space as esc alternatives. Thus far it doesn't look like remapping caps-lock in the WSL is all that easy.

I ran Fedora from F18 through 25 and never had a problem getting my laptop to boot and run. But in my first month as a Windows 10 user, an upgrade has already hosed my laptop, causing me to restore it to its original state and reinstall my applications.

I'm not sure what the update was supposed to do, only that it was big and would require a lot of time and a number of reboots.

After a bunch of those reboots and a lot of time, I was left with a black screen and a cursor. That's it.

I could ctrl-alt-del and get a prompt to shut down, but I couldn't do anything else. I think the updates "broke" the video driver.

So since I only had a month "invested" in the OS, I could have wiped the entire thing and put Fedora on the laptop. But I decided to give Windows 10 another chance. I liked having the Ubuntu command line, even though it was the ancient 14.04 instead of 16.04. And I had my blog set up to deploy from that Bash command line.

I opted to reinstall the system and keep my user files, which is one of the options available on this HP Envy laptop. I assume it's the same (or nearly so) on most PCs. There is a "restore" partition that contains a copy of the original OS files, and that is what is used to reinstall the system software.

That operation took a long time, but at the end of it I had a working Windows 10 laptop once again. All of my user files were intact. But as promised, my applications were all gone. I did get a handy HTML list of them, mostly with links to the project web sites. However, I did have the install files for all of them in my Downloads file, and all I had to do was reinstall.

I did lose lots of configuration files.

I still have Vim and Gvim WITH configuration files because I elected to use the binaries from my Downloads file and not "install" them the usual Windows way. So when my laptop came back, the only application icons on my desktop were vim and gvim.

In a more grim note, the Windows Subsystem for Linux, aka the Ubuntu command line, aka the Bash command line, is NOT in any user account, nor are the files I created in Bash. That means when I did the reinstall I lost the WSL and everything in it. Pro tip: Back up your WSL files!!

I can re-create what I did in the WSL, though I won't be happy about it. And I have no idea if the laptop now has the update that broke it yesterday, or if it's coming down the pike in the days or weeks ahead. I'm certainly not going to go to the Windows Update screen and click anything that reads "update now," or whatever it says.

I have heard about this black screen issue here and there, but it doesn't seem to be widespread enough to cause any kind of massive panic. And while I'm sure there is some slick way to fix what was broken, I couldn't figure that out, and doing the restore (while keeping my user files) was the quickest, easiest way to get going.

And to elaborate on what I say at the top, if you "keep your nose clean" in Linux, meaning not try to use proprietary video drivers or do anything stupid with dodgy packages, it's pretty hard to unknowingly kill a working Linux installation. I thought the same was true for Windows, but now I know otherwise.

Update: I reinstalled the Windows Subsystem for Linux, and this time I got Ubuntu 16.04 and along with it a much newer node.js (good because 14.04's hella old) and a newer Unison (not so good because now I have to find this same version for the CentOS server I use to host this site). The Unix gods, they giveth, they taketh.

Caveat Emptor: Windows 10 is not a beta, but the Windows Subsystem for Linux is. Back up everything. All the time.

Windows Subsystem for Linux and Unison update: My "old" WSL was Ubuntu 14.04, which has Unison 2.40.102 in its repository. I have Unison 2.40.102 on my CentOS server, so that worked out. Unison requires the same version on both "sides" (i.e both servers/computers) to work. My "new" WSL is Ubuntu 16.04, and that offers Unison 2.48.3.

My choices were to a) get Unison 2.48.3 for CentOS 6, or attempt to compile it on the server (or a CentOS 6 desktop, which I don't have) or b) find Unison 2.40.102 for Ubuntu 14.04.

I thought that it would be easier to compile on the server. I got the source of Unison 2.48.3, but I ran into problems pretty quickly because I needed a newer ocaml. I was already getting in the weeds.

So I switched gears. Could I download a .deb package from the Ubuntu repository into the WSL and install it?

I got the Unison 2.40.102 from the Ubuntu 14.04 repository. Then I used apt to remove the Ubuntu 16.04 version of Unison.

Then I used dpkg -i to install the .deb. I ran unison -version. It was working, and provided the output I wanted: Unison 2.40.102.

$ wget http://mirrors.kernel.org/ubuntu/pool/universe/u/unison/unison_2.40.102-2ubuntu1_amd64.deb
$ sudo apt remove unison
$ sudo dpkg -i unison_2.40.102-2ubuntu1_amd64.deb
$ sudo apt-mark hold unison
$ unison -version

I had already restored my .prf file in the .unison directory (I call it ode.prf to sync this blog), and I ran the command I use for the first sync when all the files are on the server and none on my laptop:

$ unison ode -batch

The -batch switch lets unison sync all of the files without asking you to OK every single one.

I love that I can get a new computer, or start a new directory and use Unison to mirror what's on the server. More on Unison in my next post.