Location of WSL rootfs filesystem for post - Fall Creator's Update installations

[mjmg]

With the deprecation of the legacy WSL/lxss, the location of the new rootfs directory is seriously lacking in documentation.

From: https://stackoverflow.com/questions/46820268/where-has-c-users-username-appdata-local-lxss-gone-under-windows-fall-creator

For the Ubuntu on Windows app the location is:

C:\Users\%USERNAME%\AppData\Local\Packages\CanonicalGroupLimited.UbuntuonWindows_79rhkp1fndgsc\LocalState\rootfs\

EDIT: As noted in blog post
DO NOT, under ANY circumstances, create and/or modify Linux files using Windows apps, tools, scripts, consoles, etc.

The rootfs location is useful for backing up files, symlinking for read only access, etc.

If anyone can add the roots location for the other distros, that would be much appreciated.

[therealkenc]

#2528, #2348, blog post.

[BeErikk]

follow the course of a server install may be the answer:
https://msdn.microsoft.com/en-us/commandline/wsl/install-on-server

I got C:\distros\Ubuntu\rootfs which is pretty perfect

edit
No, don't do this. After a reboot the installation seem to be unpredictable and back in some kind of legacy mode. No idea how to uninstall it now.
The Windows Subsystem for Linux has an install or uninstall operation pending.

edit2
Not knowing what to do, I installed Ubuntu via store and this instance points to the above. Did I normalise it now to a custom path?

edit3:
C:\distros\Ubuntu>ubuntu.exe clean
This will remove this distro from the filesystem. The app will remain on your PC, but all linux files for this distro will be removed. Are you sure you would like to proceed? (This cannot be undone)
Type "y" to continue: y
Uninstalling...
Failed to clean this distro installation.
Error: 0x80070091
Press any key to continue...
....
C:\distros\Ubuntu>bash
Windows Subsystem for Linux has no installed distributions.
Distributions can be installed by visiting the Windows Store:
https://aka.ms/wslstore
Press any key to continue...

yet, C:\distros\Ubuntu\rootfs is still there

edit4
#2387

sorry for the thread hijack

[ghost]

I was wondering if a minimal GUI could be added. Not sure if it is worth the time investment from the BashOnWindows team, but my idea would be that people would start this, perhaps even from the subsystem itself, and it could then show lots of information, with tabs too, about all the subsystems on that machine (including where it is installed and which versions etc...). Like, where things are installed, how many and which distro-systems are available presently etc...

The reason why I mean a GUI specifically is because it may be the simplest and most convenient way for people to query information. Sorry for being off-topic too.

[therealkenc]

I was wondering if a minimal GUI could be added.

I keep looking at it on and off. Mostly off. I really wanted it to be a UWP GUI, but that turns out to be artificially difficult for reasons, and I time sunk a few evenings with not much of practical use to show for it. Vote for this User Voice (unrelated to WSL) if you have a chance. It is pretty straightforward to do with WPF and C++/CLI, but ick.

[MikeGitb]

Sometimes I think the WSL/Console team really doesn't like GUI's...

[BeErikk]

@Biswa96 I would love to see FreeBSD as an instance

Do you get the store infrastructure and is the instance possible to uninstall?

[mezzode]

I do think that there should be a more straightforward way to access the filesystem than having that whole path, especially since it can change depending on where you install the app too. Maybe an environment variable?

[mezzode]

Tangentially, I also wonder whether there's a better way to handle situations like this. There are definitely situations where we need access to the actual filesystem, but going via the app folder feels hacky in a way.

[bitcrazed]

@MikeGitb "Sometimes I think the WSL/Console team really doesn't like GUI's..."

Command Line is the new Black :)

Our stated and still remaining current goal is to deliver a command-line toolset & environment in which you can run your favorite Linux command-line tools. This has been our position since we first unveiled WSL back at Build 2016.

While many people get their favorite GUI apps and desktops running via an X Server, we're not currently testing or improving GUI app experiences on WSL. Again, WSL is primarily a tool to enable dev's to build and run the *NIX & open-source tools & projects that they need to get their work done.

HTH.

[MikeGitb]

@bitcrazed: I'm pretty sure I was not referring to graphical applications inside the WSL but to a GUI for the WSL as suggested by @shevegen.

The windows console still doesn't have tabs, the options menu still doesn't allow us to configure colors from the full spectrum available and there is no nice management GUI showing us what distributions are installed or that would allow us to configure them (e.g. deciding whether we want interop activated and whether the windows path should be appended to the linux PATH variable.

[bitcrazed]

Ahhhh. Gotcha. Thanks for the clarification.

Tabs: Not yet, but it's high on our backlog once we've completed our core re-engineering
Settings: Needs a MAJOR overhaul too

HOWEVER, note that it's unlikely allowing users to customize terminal colors will have the effect you expect: Many apps control color config themselves and emit specific RGB color VT sequences that bypass terminal settings.

We wanted to add the WSL config settings you suggest above: Just didn't have time * resources necessary this time around. If it turns out to be something many are asking for, we'll reconsider. Be sure to let @tara-raj know if you think we should.

[MikeGitb]

No worries - except for the tabs I consider none of it a high priority feature (and I do come by without them) but couldn't resist making that comment.

My personal top item on the whish list is running the clang sanitizers in wsl (#121)

[bitcrazed]

We have a LOOOONG list of things we need to address - all part of the biggest overhaul the Console's received in > 30 years! Tabs, replace text renderer, zoomable text, support for more Unicode/UTF-8 symbols, emoji, PowerLine, ..., etc.

We're taking some time to address some core internal rearchitecture & feature work, after which we'll return to more user-visible features.

Bear with us ;)

[raymod2]

This issue bit me as well. I use "git difftool --no-symlinks" from within Bash and it places the left/right output in my /tmp folder. I have my difftool configured to launch a script which opens the diff in a Windows application. The script points to the Windows path equivalent of /tmp. This stopped working with the Fall Creator's Update.

[BR0kEN-]

@bitcrazed Is it possible to get the UUID of current WSL instance within itself?

I'll try to clarify:

• We have a listing of available WSLs at HKCU:\Software\Microsoft\Windows\CurrentVersion\Lxss.
• When open, let's say, Ubuntu, can I get its ID to fetch additional information from winreg, like HKCU:\Software\Microsoft\Windows\CurrentVersion\Lxss\CURRENT_INSTANCE_UUID?

[therealkenc]

BR0kEN has a different question, and it's actually a pretty good one. I can't think of a straightforward way to get installation UUID of the running instance from inside WSL. Note the hypothetical registry entry CURRENT_INSTANCE_UUID proposed wouldn't fly because you can have multiple instances (say SUSE and Ubuntu) running simultaneously. If I follow the ask, anyway.

If you just want to query the registry for whatever then use interop to spawn a powershell script from WSL and parse the output. Some info on querying the registry here.

I suspect what you really want here though is just an environment variable passed from the windows side.

[BR0kEN-]

@therealkenc, I've used the CURRENT_INSTANCE_UUID as just a placeholder of unknown (to me) path part. Ideally would be to have the whole group, represented by the registry item, passed to WSL. Not sure, environment variables are good because they are modifiable (of course changes of them won't be replicated back to the registry but it might break something within current shell session). But some executable, dumping the info - seems good (like lxss_instance).

Example:

Ubuntu -> HKCU:\Software\Microsoft\Windows\CurrentVersion\Lxss\UBUNTU_ID
SUSE -> HKCU:\Software\Microsoft\Windows\CurrentVersion\Lxss\SUSE_ID

$WSLREGKEY="HKCU:\Software\Microsoft\Windows\CurrentVersion\Lxss"
$WSLDEFID=(Get-ItemProperty "$WSLREGKEY").DefaultDistribution

Above script will set $WSLDEFID to, let's say, UBUNTU_ID if it's default one. It's ok, but I don't know about the way to get SUSE_ID from SUSE shell and the same for whatever shell (your suspicion is correct, in short 😄).

[BR0kEN-]

I've realized that in WSL we have /dev/lxss, which is locked by the /init (PID 1) and /dev/lxssclient.

But still, I don't know how to get the ID of the current shell within itself. Will try to seek in processes/buses.

ionescu007/lxss#3 (comment)
https://blogs.msdn.microsoft.com/wsl/2016/10/19/windows-and-ubuntu-interoperability/

[BR0kEN-]

Found the https://stackoverflow.com/questions/46877300/how-to-get-path-to-linux-installation-from-within-wsl-in-fall-creators-update which is more or less the answer to the question.

All that should be known it's the name of a package. Now I'm wondering whether there's a nicer way to tackle this.

[therealkenc]

That SO post will get you a known default distribution (such as Ubuntu), but not the one that is running. The instance that is running might or might not be the default. It might or might not be Ubuntu. It might be Arch Linux. It might be Gentoo. It might be KLD (Ken's Linux Distro) with GUID 5b43b5f9-111e-49fe-8de3-55efbcf3fd8f.

The right approach here will depend a lot on why you want this GUID. That is, what you plan to do with it once you have it.

[BR0kEN-]

I don't agree that SO approach is for getting the default distro. Let's have a look:

(Get-ChildItem "HKCU:\Software\Microsoft\Windows\CurrentVersion\Lxss" -Recurse | ForEach-Object { Get-ItemProperty $_.pspath } | Where-Object { $_.PackageFamilyName -eq ($(get-appxpackage).PackageFamilyName | findstr SUSE) }).BasePath

What will the above script return? IMO, the BasePath of the openSUSE distro. If we change the SUSE in there by, let's say, Ubuntu - it'll return us the BasePath of the Ubuntu. If I'm not mistaken and we can't have more than one distro of the same type, then this approach is not bad (except the fact you have to compute the distro ID somehow, like cat /etc/*-release with further parsing).

At the moment I need this GUID to get the BasePath of a WSL installation in a scope of the hashicorp/vagrant#9298.

[BR0kEN-]

But despite it's working it doesn't seem stable since you have to invent a way to realize what instance you are currently in. I can't believe there's no other and elegant way to get the concrete signs that I'm in particular WSL.

By the way, the hashicorp/vagrant#9300 is a PoC implementation of SO post in Vagrant.

[therealkenc]

What will the above script return? IMO, the BasePath of the openSUSE distro.

That's because you knew to search for the magic four character string SUSE in advance.

you have to invent a way to realize what instance you are currently in

Exactly. You can't know if you are in Ken's Linux Distro (KLD), because you've never heard of it. And KLD might not even have lsb_release installed, because I might not be inclined to follow the LSB (n.b. the most popular Linux distro in existence doesn't).

If I'm not mistaken and we can't have more than one distro of the same type

I can have many GUIDs that return the same string 'Ubuntu 16.04.3 LTS' from lsb_release when running. I had a couple of Ubuntu trees installed myself back in Sept. If the Name ➞ GUID mapping were one-to-one, you wouldn't need a GUID. Because the name alone would be globally unique already.

All of which might be (and probably is) academic for your use case, whatever it is. So no need to explain that. I'm just sayin' how the relationship works, and why it is "a good question".

[BR0kEN-]

Yeah, I do understand that and fully agree with all of the statements. That's why I don't really like the implementation I made.

[BR0kEN-]

I found a weird and hacky way to get the information (from HKCU:\Software\Microsoft\Windows\CurrentVersion\Lxss) about current WSL instance from within itself.

Based on that, whole entry from the registry could be looked up by the PackageFamilyName which is in the path.

RUN_ID="/tmp/$(date +%s)"

# Mark our filesystem with a temporary file having an unique name.
touch "${RUN_ID}"

powershell.exe -Command '(Get-ChildItem HKCU:\Software\Microsoft\Windows\CurrentVersion\Lxss | ForEach-Object {Get-ItemProperty $_.PSPath}).BasePath.replace(":", "").replace("\", "/")' | while IFS= read -r BASEPATH; do
  # Remove trailing whitespaces.
  BASEPATH="${BASEPATH%"${BASEPATH##*[![:space:]]}"}"
  # Build the path on WSL.
  BASEPATH="/mnt/${BASEPATH,}/rootfs"

  # Current WSL instance doesn't have an access to its mount from within
  # itself despite all others are available. That's the hacky way we're
  # using to determine current instance.
  #
  # The second of part of the condition is a fallback for a case if our
  # trick will stop working. For that we've created a temporary file with
  # an unique name and now seeking it among all WLSs.
  if ! ls "${BASEPATH}" > /dev/null 2>&1 || [ -f "${BASEPATH}${RUN_ID}" ]; then
    echo "${BASEPATH}"
    # You can create and simultaneously run multiple WSL instances, comment
    # out the "break", run this script within each one and it'll return only
    # single value.
    break
  fi
done

rm "${RUN_ID}"

Actually, it's not a Bash or PowerShell, - it's PowerBash. Does someone have a patent? 🤣

UPD 1: checked on the old distro, installed via lxrun /install /y, openSUSE, SUSE Server and Ubuntu from Microsoft Store. Basically, it'll work on any distro that's listed in winreg.

UPD 2: modified a script that will continue operating correctly even if the directory with WSL FS will become available someday. A simple trick with creating a file having an unique name in /tmp seems enough.

[jbarros35]

I create a dir inside bash at /home/ubuntu how can I access read and write access outside bash? If its not possible would be the app almost useless. We still need to change the files using our tools! Why not?

[bitcrazed]

@jbarros35 Did you read the blog post mentioned above several times that explains why you cannot and should not try to access your Linux files from Windows or apps and tools running in Windows?

We recommend storing files that you want to be able to access from both Windows and Linux in your Windows filesystem. This way, Windows tools can access said files, and so can Linux tools via /mnt/<drive>/<path>. If you want, you can even create a Linux symlink to link your files under /home/ubuntu/…

[benhillis]

Thanks for the discussion.

[jcrben]

Note: commentary here suggests that you cannot access Windows files from Linux, but see this https://devblogs.microsoft.com/commandline/whats-new-for-wsl-in-windows-10-version-1903/ which notes:

WSL is primarily a command line tool, and so of course this feature also works in the command line. 
You can find your distro’s files by accessing \\wsl$\{distro name}\ where {distro name} is the name of a running distro. 
Here’s what it looks like to access Debian with PowerShell.

I discovered this article from the message at the top of https://devblogs.microsoft.com/commandline/do-not-change-linux-files-using-windows-apps-and-tools/