Using WSL for Linux Practice on Windows
WSL gives Windows users a fast Linux command-line environment with real Linux binaries and, in WSL 2, a Linux kernel. It is excellent for development and many DevOps exercises, but it is not identical to a separately booted Linux server.
Learning objectives
By the end of this lesson
- Explain the architectural difference between WSL 1, WSL 2, and a conventional VM.
- Install, update, list, and inspect WSL distributions using supported commands.
- Use systemd where available and recognize WSL-specific lifecycle behavior.
- Place Linux projects in the Linux filesystem for correct semantics and performance.
- Back up a WSL distribution and decide which academy labs still require a full VM.
1. What WSL provides
Windows Subsystem for Linux integrates a Linux environment into Windows. WSL 2 runs distributions with a Microsoft-maintained Linux kernel in a lightweight managed virtual machine, while preserving convenient access from Windows Terminal, PowerShell, editors, and the Windows filesystem.
flowchart TD W["Windows host"] --> M["WSL management and lightweight VM"] M --> K["Linux kernel"] K --> D["Installed Linux distribution"] D --> T["Bash, tools, services, and DevOps workloads"] W <--> I["Process, filesystem, network, and editor interoperability"] I <--> D
Translation architecture
Linux system calls are translated rather than executed by a full Linux kernel. It has different compatibility and filesystem characteristics.
Real Linux kernel
Broad system-call compatibility supports containers and many developer workloads.
Independent virtual machine
Offers clearer boot, firmware, disk, network, and machine-lifecycle fidelity for administration labs.
2. Install and inspect WSL from PowerShell
Use an elevated PowerShell session for initial installation when required. The supported one-command path enables the needed Windows features and installs a default distribution. The exact restart behavior depends on the current Windows and WSL state.
# Inspect available distributions.
wsl --list --online
# Install WSL and the default distribution when WSL is not yet installed.
wsl --install
# Or choose a distribution explicitly.
wsl --install --distribution Ubuntu
# Update the WSL platform and inspect versions.
wsl --update
wsl --version
# List installed distributions and whether each uses WSL 1 or WSL 2.
wsl --list --verbose
New installations normally use WSL 2. If an existing distribution is still WSL 1, conversion is available, but back up important data before changing platform state.
# Example: convert an installed distribution to WSL 2.
wsl --set-version Ubuntu 2
# Set WSL 2 as the default for future distributions.
wsl --set-default-version 2
3. First launch and Linux identity
The first launch expands the distribution filesystem and asks you to create a Linux user. This account is separate from the Windows account even when names are similar.
# Run inside the WSL distribution.
whoami
id
cat /etc/os-release
uname -srmo
# Confirm WSL-related kernel and environment evidence.
grep -i microsoft /proc/version || true
printf 'WSL_DISTRO_NAME=%s\n' "${WSL_DISTRO_NAME:-not-set}"
printf 'WSL_INTEROP=%s\n' "${WSL_INTEROP:-not-set}"
# Update the selected distribution using its package manager.
if command -v apt-get >/dev/null 2>&1; then
sudo apt-get update
sudo apt-get upgrade
elif command -v dnf >/dev/null 2>&1; then
sudo dnf upgrade --refresh
fi
4. systemd support and WSL lifecycle
Current WSL supports systemd, and the default Ubuntu installed by the standard WSL installation path may already use it. Verify rather than assume:
ps -p 1 -o pid,comm,args
systemctl is-system-running 2>/dev/null || true
systemctl list-units --type=service --state=running --no-pager 2>/dev/null | head
For a distribution where systemd is installed but not enabled, Microsoft documents the following WSL configuration:
# /etc/wsl.conf
[boot]
systemd=true
After changing /etc/wsl.conf, shut down WSL from
PowerShell with wsl --shutdown, then relaunch the
distribution. A key difference remains: background systemd services
do not necessarily keep a WSL instance alive in the same way a
continuously running server VM remains powered on.
5. Store projects in the correct filesystem
~/projects inside the WSL filesystemLinux metadata and file-intensive operations behave
naturally
C:\Users\...Best location for tools executing directly on Windows
/mnt/c or \\wsl$\Distro\...Convenient interoperability, not necessarily the best build
workspace
mkdir -p "$HOME/projects"
cd "$HOME/projects"
# Open this Linux directory in Windows Explorer.
explorer.exe .
# Invoke a Windows program from Linux.
powershell.exe -NoProfile -Command 'Get-Date'
# Invoke a Linux command from PowerShell using: wsl uname -a
Use WSL-aware access such as \\wsl$ or Linux tools
inside the distribution. Do not manipulate the distribution’s
backing virtual disk or internal package files directly from
arbitrary Windows utilities.
6. Networking and localhost interoperability
WSL networking has evolved across Windows and WSL versions. Many
local development services are reachable through
localhost, but firewall policy, VPN software, mirrored
versus NAT networking, and corporate controls can affect behavior.
# Inside WSL: inspect Linux addresses, routes, DNS, and listeners.
ip -brief address
ip route
cat /etc/resolv.conf
ss -lntup
# Start a temporary local web server for a connectivity test.
mkdir -p "$HOME/devops-academy/wsl-web-test"
printf 'WSL test\n' > "$HOME/devops-academy/wsl-web-test/index.html"
cd "$HOME/devops-academy/wsl-web-test"
python3 -m http.server 8000 --bind 127.0.0.1
Open http://localhost:8000 from Windows while the
server runs. Binding only to loopback avoids exposing the test
service broadly. Stop it with Ctrl+C.
7. Back up and reproduce a WSL distribution
WSL distributions can be exported and imported. Export before major experiments, conversions, or cleanup. Use a destination with enough free disk space and protect archives that may contain credentials or source code.
# Discover the exact registered distribution name.
wsl --list --verbose
# Stop running WSL instances for a consistent export.
wsl --shutdown
# Export a distribution to a tar archive.
wsl --export Ubuntu D:\WSL-Backups\Ubuntu-baseline.tar
# Inspect commands and options supported by the installed WSL version.
wsl --help
wsl --unregister deletes a distribution’s registered
filesystem. Do not use it as a routine reset command. Verify
exports and important data before any removal operation.
8. Which academy labs fit WSL?
Shell, files, Git, scripting
Most command-line, text-processing, package, development, and automation exercises work well.
Services and containers
systemd and container tooling make many service and runtime labs practical, subject to Windows integration details.
Networking and security
Host integration, firewall layers, VPNs, and WSL networking can differ from a standalone server.
Boot, disks, kernel, recovery
Firmware, partitioning, bootloader recovery, independent kernel control, and realistic multi-interface labs need a conventional VM.
9. Hands-on lab: produce a WSL suitability report
lab="$HOME/devops-academy/linux/chapter02/lesson03"
mkdir -p "$lab"
cd "$lab"
{
printf '=== distribution and kernel ===\n'
cat /etc/os-release
uname -a
printf '\n=== WSL evidence ===\n'
printf 'WSL_DISTRO_NAME=%s\n' "${WSL_DISTRO_NAME:-not-set}"
grep -i microsoft /proc/version || true
printf '\n=== init and systemd ===\n'
ps -p 1 -o pid,comm,args
systemctl is-system-running 2>/dev/null || true
printf '\n=== filesystem locations ===\n'
findmnt -T "$HOME"
findmnt -T /mnt/c 2>/dev/null || true
printf '\n=== network ===\n'
ip -brief address
ip route
printf '\n=== interoperability ===\n'
command -v powershell.exe || true
command -v explorer.exe || true
} > wsl-suitability-report.txt
less wsl-suitability-report.txt
Verification checklist
10. Common WSL mistakes
Treating WSL as identical to a remote server
Kernel lifecycle, networking, power state, integration, and storage behavior differ from a separately booted machine.
Keeping Linux repositories under /mnt/c by default
Cross-filesystem workloads can have different metadata semantics and poorer file-intensive performance.
Running destructive WSL commands without export
Distribution removal can delete the entire Linux filesystem. Export and verify important data first.
Using sudo to solve Windows permission problems
Windows and Linux access controls interact at filesystem boundaries. Elevation inside Linux does not automatically correct host policy or mount semantics.
11. Knowledge check
Question 1. Why is WSL 2 closer to a normal Linux system than WSL 1?
Question 2. Where should a Linux Git repository normally be stored for Linux-heavy work?
~/projects, rather than under /mnt/c,
unless a specific cross-OS workflow justifies the trade-off.
Question 3. Which topics still justify a conventional VM?
12. Summary
WSL 2 is a high-value Windows development environment with a real Linux kernel, package-managed distributions, systemd support, and strong interoperability. Keep Linux projects in the Linux filesystem, understand WSL-specific networking and lifecycle behavior, export before risky changes, and retain a full VM for boot, storage, and machine-level administration labs.
13. Further reading
- Microsoft Learn: Install WSL — supported installation and distribution-management commands.
- Microsoft Learn: Basic commands for WSL — listing, conversion, export, import, and lifecycle operations.
- Microsoft Learn: Set up a WSL development environment — filesystem placement, editors, Git, databases, and tooling.
- Microsoft Learn: Use systemd to manage Linux services with WSL.
- Microsoft WSL documentation and release notes — current networking and platform behavior.
Keep the academy open
Support free, practical DevOps education.
Every lesson is designed to remain readable in a browser, downloadable from GitHub, and usable without a paid learning platform. Contributions help expand and maintain the curriculum.
0x716c4Ab160C4B66F31a28AE2448BfF68fc3a2ef0
Send only Ethereum/ERC-20 compatible assets to this
address.