How to install Linux on Windows 11 with WSL and put Debian to work

Windows Subsystem for Linux lets you open Debian on a Windows 11 PC, run a Linux build and switch back to a Windows application while the build is still running. You keep your Windows desktop and avoid the disk partitioning and reboot between operating systems that a dual boot setup would require. On a fresh installation, WSL 2 runs the Linux kernel in a virtual machine that Windows manages. Opening Debian therefore feels much like opening another application, even though the commands at its prompt run in a Linux environment. The distinction matters the moment you need to decide where a tool belongs or which update will fix a problem.

Linux inside Windows 11

The window itself adds another layer. Windows Terminal hosts shells, so a PowerShell tab and a Debian tab can look nearly identical even though they read commands in different environments. PowerShell runs on Windows and invokes wsl to request operations such as installation or launch. Bash inside Debian runs Linux tools and reads Debian’s files. Give each tab a recognizable name or keep the two in separate windows while setting up. If a guide tells you to use a Linux package manager and PowerShell reports an unknown command, check the tab before trying to install another copy of the tool. A correct command still needs the right prompt.

A distribution supplies the environment above that kernel. In Debian, that includes a shell, libraries, command line utilities and a package system that can install more software. Windows supplies the host and WSL supplies the machinery that starts the environment. In WSL 2, installed distributions run in separate environments inside the managed virtual machine. One Windows PC can hold more than one distribution, each with its own Linux filesystem and installed packages. For a team that maintains software for two Linux releases, separate installations give each test its own package inventory. The same arrangement is useful on a personal PC when you want to try a tool without installing it in the distribution where you do your regular work.

The original WSL architecture addressed Linux compatibility through translation. A Linux program asks an operating system to perform tasks such as opening a file, starting a process or allocating memory. The request it makes is called a system call. WSL 1 translates Linux system calls, so compatibility depends on what that translation layer implements. WSL 2 lets a Linux kernel handle the calls. That difference can stay invisible while you run a shell script made up of familiar commands. It becomes harder to ignore when an application expects a kernel facility that the original architecture lacks. This is why a successful shell launch, by itself, is poor evidence that a particular development stack will run.

The virtual machine in WSL 2 changes where the kernel runs without giving you a separate virtual desktop to maintain. Windows brings the environment up when you launch the distribution, and its integration lets you work from a familiar terminal window. You still need hardware virtualization available to Windows. On a physical machine, that can depend on a firmware setting. On a Windows guest running in another virtual machine, the outer host needs to expose virtualization to the guest. The second arrangement is especially easy to overlook on a remote development box. A copy of the Debian image can download successfully even though the machine cannot yet start the environment that would run it.

The practical differences between WSL 1 and WSL 2

Microsoft recommends WSL 2 and documents a particular reason to consider WSL 1. If a project must stay on the Windows filesystem and Linux tools repeatedly read or write it, the older architecture can perform better across that boundary. The location of the project therefore belongs in any comparison.

A build makes the filesystem tradeoff concrete. Fetching a dependency tree, checking source status and compiling code can touch large numbers of small files. Each operation is quick in isolation, but the workload depends on how often those operations cross between Windows and Linux. Judge performance on the workflow and file location together. If the compiler and package tools run in Debian, keeping their working tree on Debian’s filesystem is the sensible first test. If a Windows build tool and a Linux build tool must repeatedly write to the same Windows directory, measure a representative build before drawing a conclusion. A benchmark that copies one large file tells you little about how such a build will behave.

Microsoft also lists systemd support in WSL 2 as a difference between the architectures. A tool that merely needs a shell can be indifferent to the init system. A developer following a service installation guide may see commands that assume a systemd service manager is running. The architecture tells you whether that arrangement is supported, while the distribution’s configuration determines whether it is active. This is a useful distinction when a package appears to install successfully but its service control command fails. Before replacing packages or starting over with a new image, establish whether the running distribution is configured to provide the service manager the instructions expect.

WSL fits many jobs that start and end above the kernel. A developer can reproduce a Linux command line build, a student can learn shell tools, and an analyst can process files with Linux utilities while keeping the Windows programs they use for the rest of their work. Choose a full Linux system for work that depends on the target’s boot or hardware behavior. A driver experiment or a test of a specific server boot sequence has requirements beyond a matching shell and package set. WSL can still be useful for preparing source and scripts for those projects. Their decisive tests belong on the actual target or on a virtual machine configured to represent it.

Changing a distribution from one architecture to the other is possible, but it is a separate operation on an existing installation. Microsoft warns that the process can take time and fail, and recommends backing up substantial projects first. A default for future installs leaves existing distributions on their current architecture. A machine with an older WSL 1 distribution can receive a new WSL 2 distribution without converting the older one. Verify the architecture of the named distribution before moving a project or debugging an application. The default tells you what WSL will do for a new installation and the installed list tells you what it did for each existing one.

A clean install with the distribution you intend to use

The plain installation command is the shortest path if you want Ubuntu. Microsoft’s Windows 11 instructions start in an administrator PowerShell window and call for a restart after installation. A bare wsl --install installs Ubuntu on a clean machine. That choice has consequences even though the installation mechanism can also fetch other distributions. A tutorial written for Ubuntu is easier to follow when its repositories and package versions match your shell. If the project instead expects Debian, selecting Debian at the start avoids setting up an extra Linux account and then wondering which environment the next command will open. The commands here are examples to run on your own Windows 11 PC.

# Windows PowerShell as administrator — use this route for Ubuntu
wsl --install

For Debian, start by querying the online catalog from PowerShell. The catalog name is the value the installer accepts. Copy the relevant entry rather than guessing from the display name of a download or from a release codename in an article. The commands below use Debian’s documented distribution name. Run the listing first and run the installation line when the listing confirms the name. Keep the installer in the administrator PowerShell window, let it finish and restart Windows. If Debian has yet to open after the restart, launch it yourself from Start. Use the Debian route in place of the Ubuntu route if you want only Debian.

# Windows PowerShell as administrator — use this route for Debian
wsl --list --online
wsl --install -d Debian

There are two downloads to think about on a clean machine. One supplies WSL, the Windows package and its components that make it possible to run Linux. The other supplies the Linux distribution and its initial files. Microsoft has moved routine WSL servicing into a separately updated package on the standard Store route, while its command reference also documents an inbox option serviced through Windows Update. In a personal setup, the standard command keeps the process short. In a managed setup, the distinction helps explain why someone might see WSL installed but still need approval or a different distribution delivery method before they can get to a Linux prompt.

A machine that already has WSL presents a different starting point. Microsoft says that the unqualified install command is for a machine without WSL and that seeing the WSL help text can mean you should specify a distribution instead. Check the installed list before retrying an installation. The online list tells you what the catalog offers, while the verbose local list tells you which distributions are registered for your Windows user. If Debian already appears, try launching that named installation. If the machine has Ubuntu and you need Debian as well, the Debian install command adds a second environment. There is no reason to remove Ubuntu just to choose the other shell.

The distribution choice should follow the work. Pick the release used by the deployment target when you are reproducing a package or library issue. Pick the distribution assumed by a course or a project guide when following its installation instructions matters more than comparing environments. Debian and Ubuntu both use APT, but that shared command does not guarantee matching versions or repository contents. A script that says to install a package from a named release can fail long before it reaches the application code if you have followed the wrong instructions. An explicit distribution name gets you to the right family. Checking the release after launch tells you which instructions within that family apply.

For Debian, the project’s own release page explains the difference between stable, testing and unstable. Debian recommends stable for production, and testing carries packages on their way toward a future stable release. Debian’s public release status and the WSL catalog answer different questions. Debian 13 is named trixie, while Debian 12 is named bookworm. Those labels help you read instructions for a particular release, but they cannot establish what was installed by the generic catalog entry or what still lives in a distribution set up months ago. Treat a release name in the setup guide as a requirement to verify in the running shell before you add repositories or use a release-specific install recipe.

An installation stalled at zero percent calls for a different test from one that downloads the image and fails to start a virtual machine. Microsoft suggests the --web-download installation route for a download that hangs at that point. It obtains the distribution from an online source outside the Store route and still needs working network access. Use the alternate command only if it applies to your machine and is permitted on your network. Microsoft also documents a separate offline procedure using a WSL MSI, the Virtual Machine Platform feature and a distribution file. For a managed PC, the administrator can tell you which delivery route is approved and whether the necessary components are already in place.

# Windows PowerShell as administrator — alternate download if applicable
wsl --install --web-download -d Debian

An error such as 0x80370102 points in another direction. Microsoft’s troubleshooting instructions pair that code with a virtual machine that could not start and tell readers to check the Virtual Machine Platform feature and firmware virtualization. Restart after enabling the Windows feature. For a Windows guest on a hypervisor, the equivalent check belongs on the outer host, where nested virtualization has to be exposed. Keep the exact error code, because the same window that reported an installation problem can contain evidence of several different failures. Changing the download source will leave a missing virtualization feature in place, just as changing a firmware setting will leave a blocked network download unresolved.

Downloading the distribution and opening a usable shell are separate milestones. Microsoft says a first launch can take extra time while the new distribution’s files are unpacked and written. Wait for the first launch to finish before opening another terminal to check whether it worked. Once the Linux account setup is complete, subsequent launches can go straight to the shell. If you need help, record whether the command got as far as the catalog, the distribution download, the virtual machine startup or the Linux username prompt. Giving the person troubleshooting an exact stage and message is more useful than reporting that Debian failed to install.

If the storage location matters, check the installed client’s help for the optional --location flag before registering the distribution. Microsoft’s command reference documents the flag for choosing the folder during installation. Once WSL is set up, the following PowerShell example places a fresh Debian installation under a folder on C. Choose a new location on a drive with enough room for the projects and packages you plan to keep there. Use this command in place of the earlier Debian installation line if you have set up WSL and are choosing a location for a fresh Debian registration.

# Windows PowerShell — alternative for a new Debian registration
wsl --install -d Debian --location 'C:\WSL\Debian'

The first Debian session and the versions that matter

Launch Debian by name from the Windows Start menu or from an ordinary PowerShell window. Naming it is useful on a PC with more than one distribution, especially if Ubuntu was installed earlier. A plain wsl opens the default distribution, which can differ from the one you just added. The command below asks Windows to open the registered Debian instance directly. Keep its PowerShell origin in mind, because later commands in the article will go inside the Debian shell. If you opened Debian within an existing PowerShell window, entering exit at the Linux prompt returns you to that window’s PowerShell session.

# Windows PowerShell — start the named distribution
wsl --distribution Debian

The first interactive launch asks you to create a Linux username and password. This account belongs to the Debian installation and is separate from your Windows sign-in. Microsoft describes the account created during ordinary setup as the distribution’s default user and says it can run commands with sudo. The password prompt hides everything you type, including the usual dots or asterisks. Type the password, press Enter and confirm it when prompted. Use that Linux password when Debian asks for it later. A second distribution has its own Linux accounts, so setting up the same username there does not give it access to the account you just created in Debian.

The Windows and Debian accounts come into play at different stages. Microsoft documents ordinary WSL distribution installations as specific to a Windows user account. If an administrator installs a distribution while signed in as a different Windows user, you should check whether it actually appears under the account that will use it. Once inside Debian, use whoami to verify the current Linux account. For ordinary work, run as the Linux user you created and use sudo only when a command needs administrative rights. That leaves normal files and development tasks under the ownership you expect in later sessions.

A name shown in Start is only the first clue to a machine’s setup. Open a separate PowerShell tab and check the Windows side while the Debian session is still available. wsl --list --verbose reports a row for each registered distribution with its state and WSL architecture. Look for Debian and read the number in the VERSION column. A two means WSL 2. A stopped state on another row means the listed distribution is registered but currently idle. The inventory is useful on a shared project because two developers who both say they have Debian may be launching different registered distributions or running Debian on different WSL architectures.

# Windows PowerShell — inspect the registration and WSL components
wsl --list --verbose
wsl --version
wsl --status

In the same PowerShell tab, wsl --version reports the version of WSL and its components, while wsl --status describes aspects of its configuration, including its default distribution and kernel information where available. Microsoft documents older inbox builds for which wsl --status is the alternative when the version option is unavailable. Preserve the distinction in a support request. A problem with a newly introduced WSL feature calls for the Windows side version and the affected distribution’s architecture. A report that gives only a number from the distribution list tells the reader which architecture is in use and leaves the installed WSL package unidentified.

Now run the next commands at the Debian prompt. uname -r reports the kernel release visible to that session. Reading /etc/os-release gives the distribution’s identifying fields. The file can carry a human-readable name, a version identifier and a codename. On WSL 2, the kernel release comes from the environment WSL runs, and the Debian release information comes from Debian’s installed files. Those pieces are maintained separately. This explains how a Debian instance and an Ubuntu instance can report the same kernel release and still have different library versions, packages and upgrade instructions. The kernel release and the distribution release can change independently.

# Debian shell — inspect the Linux user, kernel release and distribution
whoami
uname -r
cat /etc/os-release

Keep processor architecture separate from distribution and WSL versions, too. Microsoft lists support for x64 and Arm64 CPUs. The GNU uname command can print the machine hardware name with the -m option, so check it in Debian when choosing between native Linux downloads for the same application. A Linux release can be available on more than one processor architecture, and the release codename stays the same across those builds. A maintainer investigating a problem with a downloaded executable will often need to know which build you chose. Give them the platform and architecture on the download as well as the distribution release, especially when the application offers both Windows and Linux packages.

Read the release file before applying instructions that name trixie, bookworm or any other release. Treat the operating system release as the starting point for package instructions. The fields describe the distribution. Check the application’s own version before assuming a release name establishes which copy of the tool you are running. For that, inspect the application or package directly. A problem report about a compiler should give the compiler version alongside the Debian release. If a colleague can reproduce the issue only after changing compiler versions, that tells you more about the bug than observing that both machines show the same kernel release.

If you keep Ubuntu and Debian, there is value in using explicit names in scripts and instructions sent to other people. From PowerShell, the --distribution option chooses a target for one launch. wsl --set-default Debian changes the destination for future unqualified invocations for that Windows user. Apply it if Debian is the environment you mean to use by default, then check the result with the installed list. A teammate whose default points elsewhere can still follow instructions that name Debian. By comparison, wsl --set-default-version 2 controls the architecture for newly installed distributions. The two similarly named options change different kinds of defaults.

A usable baseline records the installed distribution name, its WSL architecture, the Windows WSL component version, the running kernel release and Debian’s release identifier. Keep that inventory with the project notes if you are comparing machines. Changes at each layer can be checked independently. An update to WSL can change its components without updating Debian’s installed packages. An update through Debian’s package manager can change a library while leaving the Windows WSL package alone. Record which command revealed a version or exposed a difference. Once you can identify which environment is running and which user is at the prompt, you have enough context to choose where to keep the project and how to maintain its tools.

The right home for project files

A Windows 11 machine running WSL 2 gives you two useful places to keep files. The Linux distribution has its own file system, with a home directory such as /home/maya. Windows keeps its own volumes, and WSL normally makes the Windows C drive available as /mnt/c. A path such as /mnt/c/Users/Maya/Documents refers to the same folder Windows shows under that profile. Let the tools that do most of the work determine the location. Microsoft recommends keeping files in the Linux file system when working primarily from Linux and on Windows storage when working primarily from Windows. The choice still leaves both systems with ways to reach the files.

A repository puts that guidance to a useful test. A single export to a Windows folder is an occasional transfer. A build that inspects thousands of source files, opens dependency files and writes many small results can spend much of its time making file system calls. Microsoft identifies mounted Windows folders as a poor fit for Linux builds and Git work on WSL 2 because those calls cross a file system boundary. Keep a Linux build and its working files together. That includes the checkout, generated files and project dependencies, even when a Windows application needs the final deliverable. Build under a directory such as ~/projects and copy the deliverable across once it is ready. A document maintained in a Windows application can stay on C, with Linux reading it when needed.

The question becomes more concrete when a teammate hands you a directory full of material. Suppose the input is an occasional batch of data from a Windows application and the output is a single file for that same application. A Linux script can read and write those files under /mnt/c while the script, tests and scratch files stay under the Linux home directory. If the script repeatedly reads the whole batch as it develops intermediate results, bring a working copy into Linux and keep the source directory as the handoff point. Separate working data from the exchange folder so a teammate can tell which copy represents the latest result. Give exports names that identify their purpose and leave the authoritative input in one agreed location.

To see a Linux project from Windows, navigate to its directory in Bash and run explorer.exe .. The dot stands for the current directory. File Explorer opens there, so you can inspect or copy a file without transcribing a Linux path by hand. You can also enter \\wsl$ in Explorer’s address bar to browse registered distributions. The name of the distribution matters because each has its own root directory. Windows access through the WSL share uses the distribution’s default Linux user. If your file belongs to a user with different permissions, a Windows editor opening that same file through Explorer can encounter an access error. Inspect the file from Linux and check its owner and mode before changing anything.

Crossing the shell boundary works in the other direction too. Windows PowerShell can call a Linux executable with wsl.exe and name a distribution explicitly. The example uses Ubuntu as the registered name and asks its Linux program to list the contents of the Windows Program Files folder. Use the distribution name reported on your machine. The Linux command still expects a Linux path. Quoting keeps the space in the folder name inside one argument, and the mount path tells Linux which Windows volume to read. The same pattern works for a script launched by a Windows tool. Writing down which shell interprets each path saves time when a colleague moves the command into a different terminal.

# Windows PowerShell example
wsl.exe --distribution Ubuntu -- ls -la "/mnt/c/Program Files"

Linux can also pass text directly to a Windows program. The interop guide shows a Bash pipeline handing output to the Windows clipboard program, clip.exe. The Linux shell runs the pipeline, and the Windows program receives its output. The example below uses pwd to copy the current Linux directory path to the Windows clipboard. Paste it into a note to record where you ran a command. The text retains its Linux path syntax. If you want to browse that directory in Explorer, open it with the earlier Explorer command or locate it via the WSL share.

# Linux shell example
pwd | clip.exe

File names can make a project look healthy on one side and broken on the other. A normal directory in the distribution’s Linux file system distinguishes Parser.py from parser.py. A typical Windows directory treats the two spellings as equivalent. Imagine an import that uses lowercase while the actual file begins with an uppercase letter. A Windows checkout may conceal the mismatch until Linux resolves the name. Fix the spelling where the file is referenced, and avoid sibling files that differ only in case if the project has to work in ordinary Windows directories. That policy is useful even for teams that keep their own WSL checkouts in Linux. It protects contributors who work directly from Windows.

Windows does have a per-directory case sensitivity flag on NTFS. Microsoft documents fsutil.exe file queryCaseSensitiveInfo for checking it. Changing the flag requires elevated permissions, and Microsoft instructs users to start with an empty directory. Its documentation also warns that some Windows applications alter the spelling of paths before opening them. A case sensitive folder can expose that behavior because the new spelling may point to no file at all. Treat a case sensitive NTFS directory as an exception for a specific toolchain. A project that needs distinct names has a simpler home in the Linux file system. If the project has to reside on Windows storage, check the applications that will use the directory before choosing that arrangement.

File permissions have their own rules on mounted Windows drives. By default, WSL derives the Linux view of permission bits from Windows access rights. It can also use additional metadata on NTFS to represent Linux ownership and modes when the relevant mount option is enabled. Windows permissions still limit access when Linux metadata is present. A successful chmod can therefore change the mode you see in Linux and leave the underlying Windows denial in place. With the default behavior and no metadata, the effect of chmod is limited, including setting the Windows read only attribute when you remove all write bits. If a project needs conventional Linux permissions for scripts or generated files, put it under the Linux home directory before trying to fix the symptom with broad mode changes.

A Windows editor with a Linux workspace

Visual Studio Code lets the project keep its Linux tools and still gives you a regular Windows editor window. Install Visual Studio Code on Windows and add its WSL extension. The Windows client opens a workspace backed by VS Code Server inside the distribution. That arrangement matters when the editor runs a test, starts a debugger or calls a program to inspect a dependency. Those actions can use the Linux installation that a colleague would use on a Linux machine. The server is separate from any copy of the full editor you might have installed inside the distribution. An editor on the Windows desktop therefore tells you very little about the operating system doing the work.

To open a project, start the intended Linux distribution, change to the checkout and run code .. This example assumes an existing Git checkout named notes under the Linux home directory and Git already available in that distribution. VS Code can fetch the server components the first time it connects. Once the window opens, look for the WSL connection indicator in the lower left. Open an integrated terminal there and compare its working directory with the one you expected. If a version check reports the wrong tool, it is useful to establish which window is running the check before reinstalling anything. A regular local editor window can sit beside a WSL window, and their terminals follow their own contexts.

# Linux shell example
cd ~/projects/notes && git status --short && code .

An editor extension may need to run in the same place as the compiler or interpreter it supports. VS Code splits extensions between its Windows client and the WSL workspace. Themes and other interface extensions can stay local, while most extensions that work on the project run in WSL. Look at the installation group for the connected distribution if a language feature worked in a Windows folder and disappeared in the Linux workspace. Then check the interpreter or toolchain the extension selected. As an example, a Python project using a Linux virtual environment should point its tooling at the interpreter in that environment. A path copied from a Windows setup guide can select the wrong executable or fail outright.

A successful test in the terminal tells you what that shell can see. If the same test launched from the editor cannot find a tool, check the environment where the editor action runs. VS Code documents that its WSL server starts without running shell startup scripts. For a compiler installed under your home directory, an interactive shell might find the binary because a startup file extends its search path. The server can start with a different path. Use the project’s documented toolchain setting when it provides one. VS Code also documents a dedicated setup script for changes to the server environment.

Git is a useful way to test that arrangement because you can ask it about the working tree before touching any code. In the WSL workspace, run git --version and git status from the integrated terminal. Check that the status applies to the intended checkout, then compare it with the Source Control view. Use one Git environment as the everyday owner of a checkout. That is a practical convention for teams that have both Windows and Linux Git installed. It gives each checkout one routine set of filesystem assumptions and makes it easier to identify which installation supplied the settings or credentials when a commit or push behaves unexpectedly. VS Code documents an explicit way to share Windows Git Credential Manager with WSL if that is your preferred credential setup.

Line endings are especially visible when several tools share a repository. Git’s .gitattributes file can define what happens to particular text paths when Git stages or checks them out. Give shell scripts an explicit LF rule in a shared repository if contributors work across Windows and Linux and the project has no existing policy for them. Git documents *.sh text eol=lf as the form of such a rule. Changing the rule in an established project can affect many files, so review the resulting diff separately from the change you were making. If the repository already defines an end of line policy, start there. A setting that lives in the repository gives contributors a common rule they can inspect.

A Linux program can also draw its own window on the Windows desktop through WSLg, the graphics component of WSL 2. Microsoft supports Linux applications built for X11 and Wayland and documents using the Windows taskbar, Start menu and clipboard with integrated applications. WSLg presents individual Linux applications on the Windows desktop. It can be useful for inspecting the output of a Linux image pipeline or opening the graphical utility a project already uses. A complete Linux desktop session calls for a different setup. The distinction matters when you choose what to install. Start with the application the task calls for and check its behavior in a regular window before adding desktop components around it.

Microsoft’s examples include the X11 test programs packaged as x11-apps in Ubuntu. The following example installs that package in the Linux distribution and launches xclock. A small clock window makes a good first display check. It exercises the graphics path with a small application and no project files or settings to interpret. Look for the clock on the Windows desktop and close its window when you are done. If the program runs and your target application still fails, you have narrowed the next check to something about that application or the display path it uses. A successful X11 check says little by itself about a specific Wayland client or a graphics workload that needs acceleration.

# Ubuntu shell example
sudo apt update
sudo apt install x11-apps
xclock

A display error is worth reading before trying a workaround found in an older WSL tutorial. The WSLg project documents that its X11, Wayland and PulseAudio servers run in a system distribution, with sockets and relevant environment values made available to the user distribution. Start troubleshooting with the environment WSLg supplies. If you previously set DISPLAY in a shell startup file for a separate X server, compare your modified shell with a clean one before layering on more changes. Microsoft’s GUI guide also points to Windows graphics drivers for hardware accelerated OpenGL. A tool that opens but renders poorly presents a different investigation from a program that cannot connect to a display. Checking which symptom you actually have keeps the diagnosis focused.

Packages and services belong to the distribution

Ubuntu and Debian give you APT for installing and maintaining software inside their Linux environments. Each distribution has its own packages and configured software sources. Refresh the package index before asking APT to install or upgrade software. The index tells APT which packages and versions the configured sources publish. It is possible to refresh it and finish the operation without changing any installed program. An install is a separate action that retrieves the selected package and its needed dependencies. On a machine with two WSL distributions, open the shell for the one that needs the software. Adding a utility to Ubuntu leaves the Debian environment untouched, and PowerShell still has its own commands and software installations.

The Ubuntu example below searches for details about jq, a command line JSON processor, before installing it. apt show can report the package description, dependencies and download information from the index. Read the proposed changes before accepting the install. That becomes useful with tools that pull in a language runtime or a collection of libraries. If APT cannot find a package after a refresh, check the spelling, the distribution release and the configured sources before following an unrelated installation recipe. The package name in instructions written for another distribution may be missing or may represent a different part of the same program. A Linux version check after installation confirms which executable the shell can actually invoke.

# Ubuntu shell example
sudo apt update
apt show jq
sudo apt install jq
jq --version

Package maintenance offers a different choice. apt list --upgradable shows available updates based on the current index. An ordinary apt upgrade can add dependencies and leaves existing packages installed. It holds back an upgrade if applying it would require removing an installed package. apt full-upgrade is allowed to remove packages to complete the operation. Read the proposed removals before approving one, particularly on a distribution used for several projects. That difference is a reason to avoid treating every upgrade command you find in a support thread as interchangeable. Package versions in a team’s environment may also be part of a deliberate project setup, so compare against the project’s requirements before changing the whole distribution to resolve one missing executable.

Removing an experiment has its own details. APT’s remove action usually leaves system configuration files, which can be useful if you intend to reinstall the package later. The manual describes purge for removing that package’s remaining configuration and leaves user data and settings in the home directory outside the purge operation. Applications can keep settings and data in your Linux user files. Examine those files on their own terms before deciding whether they belong to the experiment or to work you want to keep. apt autoremove proposes packages that were installed automatically as dependencies and are now unneeded by APT’s dependency records. Read the list before accepting it, especially if you began using one of those utilities directly after it arrived as a dependency.

For changes you discover after the fact, Canonical identifies the package log in the Linux distribution as a record of operations such as installs and removals. Open /var/log/dpkg.log in the Ubuntu instance that changed and compare the package events with the time the problem appeared. Suppose a test runner starts failing after a morning update. Check whether the package or library you suspect was changed before investigating the update as a cause. The log can narrow down candidates, while a failed test or error message is still needed to show what broke.

Services add a separate question about what starts and keeps running inside the distribution. Microsoft documents systemd as the default init for the current Ubuntu distribution installed by wsl --install. An existing distribution or another distribution can still use a different init. Run ps -p 1 -o comm= in the Linux shell to see the name of its first process. If systemd is running, you can use systemctl to inspect its units, the objects it manages. Services are one kind of unit. A tool you run for a moment from your prompt has no automatic need for a service. Reach for the service manager when the application supplies a unit or you need to examine a background job that the distribution manages.

For a WSL 2 distribution that needs systemd and has it installed but inactive, Microsoft documents a setting under the [boot] heading in /etc/wsl.conf. Edit that distribution’s file with administrative Linux permissions. Add a boot section if it is missing, then put systemd=true under that heading. Preserve the other settings in the file. Microsoft also notes that Debian, Ubuntu and Kali Rolling need both systemd and systemd-sysv installed. Save active work, run wsl --shutdown from Windows PowerShell to stop the running WSL distributions, then open the intended distribution again and verify the first process. That check distinguishes a configuration you just wrote to disk from the init process that actually started.

On a systemd distribution, start by looking at the services the distribution already has. The example below lists installed service unit files and shows any service units the manager currently considers failed. An installed unit, an enabled unit and an active unit describe different things. A unit file describes work systemd knows how to manage. Enabling a unit with an installation target arranges for it to start when that target is reached. An active service is running or otherwise considered active now. If you are testing a service for a project, inspect it with systemctl status and the unit name before changing the start policy. That tells you whether the distribution recognises the name and what state the manager reports.

# Linux shell example with systemd running
systemctl list-unit-files --type=service
systemctl --failed --type=service

Use systemctl start to request an immediate start for a specific service and systemctl stop to stop it. Enabling a service without --now changes its future start policy without starting it immediately. Read the journal for the unit that actually failed. Supply its exact name with journalctl -u, using -b when you want messages from the current Linux boot. If a test service fails after an edit, review its messages and current state before deciding to restart it again. Microsoft also says that a systemd service does not by itself keep a WSL instance alive. An enabled unit makes sense for a local dependency that you want available during a development session. Treat Windows startup and continuous availability as separate requirements when a job has to run on a schedule.

A Debian web lab you can verify from Windows

A single static page is enough to test the path from a Windows client to a Linux process. Start in Debian with a temporary server bound to IPv4 loopback. Python’s standard library can serve one disposable file on an unprivileged port, with each request visible in the terminal. You avoid installing a web stack before knowing whether the basic network path works. The distinction pays off when a larger application fails. If the little server still answers from Windows, you can focus on what the larger application does differently, such as the address it listens on, the port it picked or the path its router expects.

Open a Debian shell and check that Python, curl and the socket inspection tool are available. A fresh distribution can have a smaller set of packages than another developer’s machine, so a missing command is a setup problem in its own right. Use the package manager if you need to install the tools. Only package installation needs elevation in this lab. The server itself runs as your ordinary Linux user and stays in the foreground. The package manager’s downloads use the network, so a failure at this point belongs in a different category from a failure to reach a server already running on the machine.

# Debian shell — install any missing lab tools
sudo apt update
sudo apt install python3 curl iproute2

In the same Debian tab, make a new temporary directory, write one page into it and start the server. The distinctive response text identifies your file if another program already uses the same port. The shell variable keeps the path available in this tab for cleanup and lets you rerun the server on another port if necessary. The --directory argument tells Python what to serve even if your shell is currently in a repository or home directory. A fresh directory also avoids putting work files in the document tree by accident. The following commands are a reproducible example, and their results will depend on the software and policy on your machine.

# Debian shell — tab 1
lab_dir=$(mktemp -d) &&
printf '%s\n' '<h1>Debian WSL lab</h1><p>WSL-LAB-READY</p>' > "$lab_dir/index.html" &&
python3 -m http.server --bind 127.0.0.1 --directory "$lab_dir" 8000

The address is doing as much work here as the port. In Python’s command line interface, the default bind covers all interfaces, so keep the explicit loopback bind even if everything seems to work without it. Keep the new directory limited to the test page. The Python documentation warns that its simple file handler follows symbolic links, which means a link in the served tree can expose a file outside it. The module has basic security checks and is intended here as a short diagnostic. For the same reason, skip credentials, real customer data and copied application configuration in the page itself. The test needs only a recognizable string.

Leave the first tab open and start another Debian tab. Check the listening socket before making the HTTP request. The ss flags select listening TCP sockets, show numeric addresses and attempt to display the owning process. Look for the local address 127.0.0.1:8000 and, where shown, the expected Python process. The socket shows what actually bound, which may differ from the settings you meant to use. If the first tab reports that the address is already in use, choose another unused port, such as 8001, and update the port throughout the exercise. That avoids stopping an unrelated process and keeps both clients pointed at the same service.

# Debian shell — tab 2
ss -lntp
curl --noproxy 127.0.0.1 --max-time 5 -i 127.0.0.1:8000/

Curl treats this numeric address as HTTP without a scheme. Its proxy exception here applies to the specified loopback destination for this invocation, leaving general proxy settings alone. The request has a five second time limit so a stalled test returns control to your shell. Expect an HTTP 200 response containing the marker and a corresponding request in the first tab. The status, body and server log corroborate one another. Try a deliberately absent filename in the same directory if you want to recognize an application error. A 404 from this server means the request made it all the way to the HTTP handler and the requested file was unavailable.

Next run the matching command from a Windows PowerShell tab, with the Debian process still running. Spell the command curl.exe to select the Windows executable explicitly. Calling a Windows executable from a Debian tab can obscure which side performed a check, so give each shell a clear role. If the same body appears and the Python tab logs the new request, you have verified the Windows to Debian path for this address and port. That result provides a baseline before testing with a Windows browser. A browser can add its own proxy or protocol behavior to the connection, while the command fixes the destination and prints the response directly.

# Windows PowerShell
curl.exe --noproxy 127.0.0.1 --max-time 5 -i 127.0.0.1:8000/

A response with the wrong body calls for a check of which process served the request. Run the Debian check again, then watch the Python tab while you repeat the Windows one. If Debian still sees the marker and Windows sees another page without a new request in Python’s log, investigate another listener or a different destination before changing network settings. If both clients get the wrong page and Python logs the requests, check the directory argument and the contents of the file. Choosing an alternate port for the lab is a quick way to test the possibility of a collision while leaving both applications alone.

You can also edit the test page while the server is running and request it again. Changing the marker gives you a second check that both clients reach the same file. Do this before pointing a real application at the port. Once you stop Python and start the application, request a path the application actually serves and watch its own log. The simple page has established which connection worked with a known listener. The application may use a different HTTP path or require credentials. Treat an HTTP error from that application as evidence to read alongside its log before making a change to the address or port.

Stop the Python process with Ctrl+C in the first tab once you have finished. Run the same Windows request again if you want a check in the other direction. The marker should disappear when the Linux listener goes away. If a page still comes back, check which service answered and whether the browser had cached an earlier copy. Curl provides a fresh command line check. The temporary directory stays on disk until you remove it. After confirming the path in the first tab, delete the test page and use rmdir to remove the now empty directory, or save the page as a known response for the next diagnostic session.

The network path depends on which side starts the request

In Microsoft’s default WSL 2 NAT setup, Debian has a virtual network adapter and an IP address inside the virtual network. Windows applications can usually still use their own loopback address to reach the Debian server. WSL provides localhost forwarding from Windows to Linux for ports the guest binds on loopback or a wildcard address, with the NAT forwarding setting enabled by default. That is why the web lab does not require tracking a guest address. It also means an app bound only to Debian’s loopback can answer a request made at Windows loopback, even though those endpoints are on different sides of the virtual machine.

Reverse the direction and the same default NAT shortcut does not follow. A Debian application dialing 127.0.0.1 goes to Linux loopback. To reach a Windows service under NAT, use the Windows address visible from the guest. Microsoft shows how to identify it from the default IPv4 route in Linux. The service must accept connections on the interface addressed, and any firewall that applies must permit the traffic. For a local Windows database, check its actual listener before touching a firewall. A service bound only to Windows loopback will still be listening on the wrong interface for a connection arriving at the host’s virtual network address.

# Debian shell — inspect the default IPv4 route under NAT
ip -4 route show default

A separate diagnostic from PowerShell, wsl.exe -d Debian hostname -I, prints the Linux addresses as seen in Debian. Use the installed distribution name if yours differs. The uppercase letter requests interface addresses, and the output can contain several. A guest address and a loopback endpoint test different listeners. Substituting the guest address into the Python lab will not reach a server bound only to loopback. Use the guest address as evidence when a service is already intended to listen on that interface. Avoid recording it as a permanent endpoint in shared project instructions. If the virtual network changes, the current address needs to be checked again.

Endpoints for testing a WSL connection

The first two checks belong together. A failure in Debian gives you a reason to inspect the server. A failure only from Windows narrows the problem to the Windows side of the path or the link between the two. The last row is a distinct test for a service that was intentionally made available to the network.

Mirrored mode changes the arrangement. Microsoft documents it for Windows 11 version 22H2 and later and describes it as mirroring Windows network interfaces into Linux. It supports IPv6 and multicast, improves compatibility with some VPN setups, and can let another machine reach WSL directly over the LAN when the listener and policy permit it. It also lets a Linux client reach a Windows service at IPv4 loopback. Microsoft specifies that IPv6 loopback ::1 is unsupported for that cross-boundary use. Keep the numeric IPv4 address for the lab so that address-family selection cannot be mistaken for a change in whether the service is running.

If the lab works in NAT and the project only needs a Windows client to reach a Debian development server, keep the existing configuration as a baseline. Mirrored mode earns its place when the actual problem is one of the paths or features that it changes. To try it, Microsoft places the networking mode in the Windows user’s profile, in .wslconfig under the existing [wsl2] section. The setting applies across WSL 2 distributions for that Windows account. Preserve the rest of the file, and save work in every running distribution before restarting WSL. Shutting down the subsystem will interrupt the lab and any other WSL workloads that are running.

# Windows user profile — .wslconfig

[wsl2]

networkingMode=mirrored

From Windows PowerShell, wsl --shutdown stops WSL so it can read the changed configuration at the next launch. Start Debian, recreate the disposable lab at the same port, and repeat the same two checks. Rerun the baseline before changing any other setting. If you need to undo the change, restore the previous networking value or remove the new line if it was absent before, then restart WSL again. A malformed file can leave WSL running with its settings unapplied, so a successful shell launch alone tells you little about whether you are using the configuration you edited.

If HTTP from Windows fails while Debian responds, a read-only TCP test on the same Windows endpoint adds useful evidence. PowerShell’s Test-NetConnection reports whether a TCP connection was established for the supplied port. A true TcpTestSucceeded result establishes that something answered at the transport layer. To identify the responder, compare the HTTP status, body and Debian log. If the TCP test fails, confirm that the Linux listener remains active, check the exact port and note which network mode is configured. In NAT, review whether localhost forwarding has been disabled. That setting is ignored in mirrored mode, where troubleshooting belongs on the mirrored path.

# Windows PowerShell — test TCP separately from HTTP
Test-NetConnection -ComputerName 127.0.0.1 -Port 8000 -InformationLevel Detailed

A different failure pattern starts when Debian cannot download a package or resolve a work hostname while the local page still loads. A numeric loopback request takes DNS out of the lab. Microsoft’s DNS tunneling feature on supported Windows releases answers WSL DNS requests through virtualization, a design intended to improve compatibility with VPNs and complex networks. Microsoft also documents autoProxy as a way to use Windows HTTP proxy information in WSL. Compare the same approved service from Windows and Debian on the same network, and separate a name lookup failure from an HTTP error or a connection timeout. Changing the local server’s address will do little for a repository hostname that Debian cannot resolve.

For a service identified by a hostname, Debian’s getent ahosts followed by the approved name lets you inspect what the Linux system resolver returns before attempting HTTP. Its output may include more than one address, and it reflects the system’s configured name sources. An address in that output establishes that the system could resolve the name for that lookup. It says nothing about whether the returned endpoint accepts connections. Conversely, if the application relies on a proxy to reach the destination, a failure to resolve the destination locally may leave the proxy path untested. Record both observations if they differ.

Keep the environment in the record when a result varies. Which shell initiated the request, which address family and port it used, whether a VPN was connected, and whether the server logged it are enough to make a second run meaningful. Compare one change at a time so a successful retest has an explanation. Switching network modes, rebooting a VPN client and changing the HTTP bind in one pass can leave the failure apparently fixed with no evidence of which action mattered. If ordinary loopback HTTP works with the VPN connected but an approved internal service fails, hand off the service-specific evidence instead of describing the whole Linux network as down.

A working port still has a security boundary

The web lab starts from a narrow promise. Loopback means access from the same machine through the supported host and guest paths. A phone, a colleague’s laptop or a test runner on another computer uses its own loopback address, so it needs a different endpoint to reach your laptop. Even on one machine, however, the loopback bind offers no authentication of the client. Any client with access to that local endpoint can ask for the page. Keep the files disposable and the lifetime short, especially on shared workstations where the same computer may run software under other accounts or carry several development environments.

Think of an inbound connection as having separate gates. First, the application must listen on an address the client can reach. Next, the traffic must have a network path to that address, and the firewalls and organizational policy along the way must permit it. A Linux listener can appear healthy while a firewall drops packets. A firewall exception can exist while the service is stopped or bound to the wrong interface. Reading these layers in order gives you a useful diagnosis. A list of firewall rules alone rarely tells you which server was running when a test failed or whether the request ever got to it.

Under default WSL 2 NAT, the Windows loopback shortcut provides no automatic LAN forwarding. Microsoft describes configuring a Windows port proxy as a way to forward a host port to the guest address. Such a proxy adds a Windows listener and a second destination to maintain. Mirrored mode can support direct LAN connectivity without that NAT proxy arrangement, subject to the app’s bind and applicable filtering. Keep the temporary Python lab on loopback in either mode. If a project requires access from another device, choose an appropriate service and a defined test network before discussing which inbound path to approve.

On Windows 11 version 22H2 or later with WSL 2.0.9 or later, Microsoft says Hyper-V firewall is enabled by default for WSL. It can filter inbound and outbound traffic, and Microsoft documents how host firewall policy can affect the rules applied to WSL. Its loopback setting governs traffic exchanged by Windows and WSL on the same machine separately from traffic arriving from elsewhere. When diagnosing managed systems, treat the firewall state as something to read and report. Changing policy to see whether the failure goes away removes evidence about the original conditions and can affect traffic beyond the single test port.

Microsoft documents an applied policy store for reading the settings that actually apply. On a machine where you are authorized to inspect them, an administrator can query WSL’s Hyper-V firewall settings in PowerShell using the WSL creator identifier. The result can show whether the firewall is enabled, the default actions, whether loopback is enabled and whether host policy can merge. A separate profile query shows how settings can vary with the Windows network profile. These checks do not open a port. Record the output for the team responsible for the device if you need its interpretation, especially where a result changes between an office network and another connection.

# Windows PowerShell — authorized administrator, read-only inspection
Get-NetFirewallHyperVVMSetting -PolicyStore ActiveStore -Name '{40E0AC32-46A5-438A-A0B2-2B479E8F2E90}'
Get-NetFirewallHyperVProfile -PolicyStore ActiveStore

A work machine can have centrally managed rules that supersede local ones. Microsoft documents that Hyper-V firewall profiles can be configured to disregard local rules and that applicable Windows Firewall settings from Group Policy can carry over when the Hyper-V firewall has no policy set through its configuration service provider. Microsoft also supports managing access to WSL and some WSL security settings through Intune. An apparent contradiction between a rule you see locally and a blocked connection may therefore reflect the intended device policy. Send the address, direction and port to the administrators who can view the effective policy and explain how the machine is configured.

When a team actually needs a device on the LAN to reach an app, frame the request around the smallest required scope. Give the administrators the protocol, service port, intended client device or subnet, network profile and period of use. A narrow test on an approved network is easier to check and undo than a standing exception that follows a laptop between networks. Confirm that the intended client can connect, then use a separately approved client to check the edge of that scope if verification is required. A working browser on the host provides no evidence about which remote clients were allowed, so the network test needs a real client at the agreed location.

The address also matters when developers share a computer or move a laptop. A Linux app listening on all IPv4 interfaces makes itself available on whatever interfaces its environment presents, subject to network reachability and firewall policy. A wildcard bind expands the set of possible clients compared with loopback. The final audience depends on the rest of the path, which can change when the host joins another network. For the web lab there is no need to take on that ambiguity. When checking someone else’s development server, read the bind address from its actual startup output or listening sockets before assuming that a label such as development or local describes its reach.

An incident report for this kind of failure can fit in a few lines. Start with the observed result, such as a response with the lab marker from Debian and a failed TCP test from Windows. Add the Windows and WSL versions, network mode, address, port and whether the failure changes on the VPN. If an administrator queried the firewall, attach the relevant settings through the team’s approved channel. Report the boundary where the evidence changes. That lets the person receiving the report reproduce the useful part of the test without opening a port, handling production data or trying to reconstruct what the original client did.

Closing a shell and stopping a distribution

A Windows Terminal tab is a way into Linux. Closing it ends that session, but a task launched through a different terminal or a Windows application may still be using the distribution. Check the running state in PowerShell before assuming Linux has stopped. The verbose distribution list reports each registered name, its state and whether it uses WSL 1 or WSL 2. The running list answers the narrower question of which distributions are active. The names matter as much as the states. A profile in Windows Terminal can have a friendly label, while the WSL management commands expect the registered name. Use the spelling from the list when a command asks for a distribution. Run both commands in PowerShell on Windows.

wsl --list --verbose
wsl --list --running

When a command is running in the foreground, let it finish or stop it using the application’s own controls. For a local database, ask the database to shut down and wait for it to finish before bringing down the distribution. Save editor buffers, end active copies and let a package operation return to the prompt. An application connected from Windows may need its own close or disconnect step. An orderly application stop comes before the WSL stop command. If a build has frozen, stopping the distribution may be a reasonable choice after you check what else would be interrupted. The next launch starts new processes. Any work that existed only in memory has to be redone.

Use termination for work confined to one registered distribution. In the example below, the name Ubuntu is illustrative and should match the relevant row on your machine. If Debian is running alongside it, you can leave Debian’s session alone while you restart Ubuntu. Microsoft describes the command as stopping the targeted distribution. It leaves the registration and the files on disk in place. The state check in the middle is deliberate. Launching Ubuntu first would immediately change what the list reports, which makes it harder to tell whether the stop worked. If a Windows tool reconnects and starts Ubuntu again during the check, close that tool before trying again. Run the sequence from PowerShell after saving work in Ubuntu.

wsl --terminate Ubuntu
wsl --list --verbose
wsl --distribution Ubuntu

A full WSL shutdown stops every running distribution and the WSL 2 virtual machine. Use it to apply changes to the VM or when a maintenance procedure calls for it. If your editor is attached to Ubuntu and a second distribution is running a background job, both are in scope. Finish what is running in each, then issue the command from PowerShell. It is also useful to know the difference between deliberately stopping a machine and waiting for it to become idle. Microsoft’s configuration guide says the subsystem typically takes about eight seconds to stop after all shells close. Treat that as a typical delay. The configuration takes effect after the relevant environment has actually stopped and started again. Run the checks below in PowerShell.

wsl --shutdown
wsl --list --running

The two configuration files live on different sides

The nearly identical names conceal a useful difference. The Windows profile’s .wslconfig sets options for the shared WSL 2 virtual machine. It applies across that Windows user’s WSL 2 distributions and has no effect on a WSL 1 distribution. Within Linux, /etc/wsl.conf holds settings for the distribution that contains it and works with either WSL version. The leading dot belongs to the Windows file. A file called .wslconfig in your Linux home directory is in the wrong place. A copy of wsl.conf in your Windows profile is equally misplaced. If the symptom is that only an imported copy signs in as the wrong user, start with the Linux file in that copy.

Changing a setting inside one distribution gives you a simple test of that boundary. For example, if you adjust a launch setting in /etc/wsl.conf, save the file, close related work and restart the affected distribution by its registered name. Open that same name to inspect the result. Where an application offers a choice of Linux targets, check that it reconnects to the one you changed. A default launch may send you to another distribution altogether. A global file change follows a wider procedure. Once all workloads can stop, shut down WSL and start a WSL 2 distribution again so the VM picks up the new settings.

Windows and Linux get their updates separately

The version reported by wsl --version identifies WSL and its components. The number in the final column of wsl --list --verbose identifies the kind of WSL environment a particular distribution runs under. Check WSL components and Linux packages separately. The WSL update command goes in PowerShell. Debian and Ubuntu both use APT from their respective shells, with their own configured package sources and installed software. Check the window you are typing into before approving changes, particularly if you maintain a working system and a test copy side by side.

wsl --version
wsl --update

Bash in Debian, using an account with sudo access.

sudo apt update
sudo apt upgrade

Debian’s reference separates an index refresh from a package change. Read the result of apt update before proceeding to apt upgrade. The refresh downloads the metadata APT uses to determine candidate versions. If it reports a failed source, check the failure before relying on that list. The upgrade step installs candidate versions without removing installed packages. Run it interactively so you can read what it proposes. Debian documents a separate full upgrade operation that can remove packages to resolve changes. A report of packages being held back is a reason to inspect the proposal and the distribution’s own instructions before choosing that broader operation. For a system you rely on, make a restore copy before a major change.

When a fault appears after an update, record what changed before trying another fix. Debian’s package logs and the WSL version describe different parts of the machine. Debian’s reference points to /var/log/dpkg.log for package activity and /var/log/apt/term.log for APT output. Look at the entries around the time the fault first appeared. If a tool fails in Debian while the corresponding workflow still works in Ubuntu, a shared WSL change is only one possibility. If both fail, record the WSL version and the symptom in each. Start by changing one layer at a time so the next test gives you a result you can interpret.

Giving WSL a budget for memory and disk

If Windows starts to feel crowded during a build, first separate memory pressure from CPU activity. A burst of compiler activity can saturate the processors even when both Windows and Linux have enough RAM. Conversely, a modest CPU reading says little about a workload that keeps pushing data through swap. Microsoft documents the default memory limit as half of the host’s total memory, with access to the host’s logical processors by default. Those settings describe the WSL 2 VM, and the same VM budget serves the distributions running inside it. There is little reason to invent a tighter cap on a machine that already runs the workload comfortably.

Microsoft recommends using WSL Settings from the Windows Start menu to change WSL configuration. To edit the file directly, use a plain text editor and save it as .wslconfig in the Windows user profile. If the file already exists, merge the values you intend to change under the existing section and keep a copy of the old settings. If you create it from scratch, make sure the editor did not append .txt. Microsoft says that WSL can still start when the file is missing or malformed. A working shell therefore does not establish that it read your changes. For a file in the right place, use the section and value syntax shown below in %UserProfile%\.wslconfig on Windows.

[wsl2]
memory=6GB
processors=4
swap=2GB

The values are illustrative. A low limit might suit a light shell and an editor but leave too little room for a large build or several services. Swap uses disk space and comes with a performance cost when programs depend on it heavily. Microsoft documents the default swap allocation as a quarter of the host’s memory rounded up to a whole gigabyte, and allows zero to disable the swap file. If your trouble began with sluggish Windows response, change one setting at a time and run the same Linux task after a full WSL shutdown and restart. Watch both sides while you run it. A calmer Windows desktop and a much slower or failing build tell you that the change carried a cost.

After that restart, check the budget from inside the Linux environment that runs the workload. Run the Bash command first with the default settings, then again after the change. free -h shows guest memory and swap in readable units, using data from the Linux kernel. Open Windows Task Manager separately if you want to see how much pressure the workload puts on the host. For comparisons, use the same build or data job under similar conditions. Comparing a first build that compiles everything with a repeat that reuses its outputs will tell you little about the change in resources.

free -h

A memory report taken immediately after a large job can show plenty of space in the cache. The available column in free estimates how much memory new applications could use without swapping. The raw free column counts unused memory, so it can be low even when Linux could release some of its cache as needed. Microsoft also documents autoMemoryReclaim under the experimental settings for reclaiming cached memory. Leave it alone while you test a new VM limit. If you alter the cache policy and the limit together, you give yourself two explanations for any change in memory use after the job.

The free space numbers answer two different questions

Each WSL 2 distribution has a virtual disk holding its Linux filesystem. The amount of space Linux thinks it could use and the capacity of the Windows drive that holds the disk file are separate limits. Microsoft describes the current default ceiling of a distribution’s virtual disk as 1 TB, with smaller defaults on older releases. The file grows with use. This is why the guest can report hundreds of gigabytes available on a computer that has nowhere near that amount physically free. The discrepancy becomes practical the moment an import, database load or build expands a distribution on a nearly full Windows drive.

From Bash inside the distribution, use df -h / to read the free space on its root filesystem. In Windows File Explorer, open This PC and check the free space on the drive that holds the virtual disk. Check the disk’s actual location before comparing the numbers, especially after importing a distribution to a drive you chose. Microsoft’s disk guide describes a PowerShell lookup by registered name to locate the disk. For an imported copy in the example later in this article, you already know the Windows drive from the install directory you supplied. If the application writes to a Windows mount instead of the Linux root filesystem, inspect the drive that backs that destination too.

df -h /

If the Linux filesystem is nearly full, start by finding out what you can recreate or remove safely. Build outputs and old downloads are worth checking before deleting caches or application data at random. If the Windows drive is nearly full, moving unrelated Windows files elsewhere may solve the immediate constraint. Deleting files in Linux can restore free space inside its filesystem without a matching drop in the size of a dynamically expanding virtual disk. Microsoft’s DiskPart documentation describes compaction for that class of disk and requires it to be detached or attached read only. Keep a verified export before attempting that separate maintenance operation, and stop WSL before touching its virtual disk.

When the guest really has hit its virtual ceiling and there is capacity on the host, Microsoft documents a resize operation. The documented wsl --manage resize procedure requires WSL 2.5 or later, referring to the WSL package version you see with wsl --version. The distribution itself must run under WSL 2. Check the present ceiling and shut down WSL before resizing. In PowerShell, the documented syntax is wsl --manage <name> --resize <size>, with the actual registered name and a whole number followed by a supported unit such as GB or TB. After it finishes, reopen the same distribution and check its root filesystem again. Increase the ceiling only where the guest is the constraint. On a full Windows drive, free host space before increasing the guest ceiling. The maximum is also a poor estimate of the archive size you will need for a backup.

A second distribution gives you somewhere to recover

A second Linux installation gives an experiment a place to run while the primary workspace remains available. Choose between a clean install and a copy according to the question. A fresh distribution gives a colleague a baseline for checking prerequisites. An imported copy preserves the state that made a problem reproducible, down to a configuration edit or an old dependency. Use a name that identifies which of those jobs the second installation does. A clean installation of a different Linux distribution also makes a useful comparison when you need to check whether a problem follows the distribution’s packages or appears in multiple environments on the same Windows host.

For a change that needs the application, packages and configuration you already have, make a copy before running the test. Microsoft’s export command makes an archive of a named distribution, and import registers a new distribution from that archive. That gives you a way to test a restore while keeping your working registration. It also means a cloned installation starts with the data and configuration you exported. Treat a copy used for testing with the same care as the original if either contains private files or credentials.

Before exporting the Debian example, stop applications that are writing and leave the shell. If data lives in a database, take the application’s own backup as well. A distribution archive is a filesystem recovery tool, and the application’s own export can also be useful if you only need to recover one database. Make a record of what lives outside the distribution before relying on the archive. Work under a mounted Windows drive belongs to the Windows filesystem, and the Windows profile’s .wslconfig lives outside the distribution too. Save those separately if they matter to recovery. Choose a Windows volume with room for the archive and enough remaining capacity for a separate import. For the PowerShell examples, create D:\WSLBackups and an empty D:\WSL\Debian-Recovery folder on an existing D drive, or substitute paths on your own drive. Use a fresh archive name.

wsl --terminate Debian
wsl --export Debian 'D:\WSLBackups\Debian-before-change.tar'

Run the export only after Debian’s work is saved. If a stop command reports that the distribution is already stopped, confirm that state in the verbose list. Check that export succeeded before moving on to import. The example uses the default tar format. Microsoft also documents a virtual disk format for WSL 2, which has distinct command options. For the tar example, keep the archive and the import destination separate so you can preserve the untouched archive even while you test the restored copy. Choose a registration name you can tell apart at a glance from the live one. The name is a useful reminder when a terminal tab is otherwise indistinguishable from the original. Use PowerShell again for the import.

wsl --import Debian-Recovery 'D:\WSL\Debian-Recovery' 'D:\WSLBackups\Debian-before-change.tar' --version 2
wsl --list --verbose
wsl --distribution Debian-Recovery

An imported distribution can put you at a root prompt on first launch. Check the account with whoami before editing or creating project files. Root can leave new files owned by root in directories you usually edit from an ordinary account. If you exported an existing Debian installation, your ordinary account may already be there. Check that it exists in the restored distribution, then set the default in that copy’s /etc/wsl.conf if it needs changing. Microsoft documents this file as the route for imported distributions because those registrations lack the distribution launcher used by the Store-style default-user command. Merge the section below into any existing file, keeping the other settings. In Debian-Recovery, replace alice with an existing account in that copy.

[user]
default=alice

After saving the configuration, exit the recovery shell, terminate the named copy in PowerShell and reopen it. A restore test should check files and applications as well as whether Linux starts. Open the project in the account that will use it, inspect access to a representative file and run a small operation your normal work requires. If the original and the copy point to the same Windows data directory or remote service, choose a disposable test target before running anything that writes. A second registered name keeps the Linux filesystems apart. Any destination the two configurations deliberately share remains writable from either copy.

If a change breaks the original, begin by launching the verified recovery copy explicitly. Keep the failed environment until you know whether it contains newer work. You may only need to recover a configuration file, or you may decide to use the restored distribution for day-to-day work. If you change the default WSL distribution to the recovery copy with wsl --set-default Debian-Recovery, check any editor or Windows Terminal profile that names the old registration directly. The WSL default governs a launch that leaves the distribution unspecified. A tool that expressly asks for Debian still opens Debian. A dated backup and an explicit launch name make these decisions easier when time is tight.

If the archive matters beyond the immediate test, keep another copy on a separate drive or in a backup location you already trust. An archive and a restored distribution on the same physical disk share the same point of failure. Giving the files different paths is still useful for protecting the archive from routine work inside the imported copy. A separate device covers a different problem. Record which distribution and account the export contains, which configuration lives in Windows, and the date you actually tested it. A recovery record is particularly useful when the person restoring a team environment is someone other than the person who made the archive.

Deletion belongs after recovery. The wsl --unregister command permanently deletes the selected distribution’s data, settings and installed software. It is different from stopping that distribution or choosing another default. Check the exact registered name in the verbose list before using it, even if you mean to remove a disposable copy. Keep the export in a location outside the distro’s install directory, and preserve any newer files that the archive predates. If your only objective is to get back to work, open the verified copy and leave the original registered while you investigate. A little extra disk space is easier to reclaim later than the one file that was never backed up.

A WordPress rehearsal on Debian

A WordPress team can put WSL to work before it has any reason to rebuild its whole hosting environment. Take a change to a site that has accumulated years of plugins, media, redirect rules and custom templates. Give the change a specific failure to reproduce. A useful case might involve a request for a paginated archive that returns a server error after a plugin update, or a form handler that behaves differently after a PHP change. Record the steps that reach the faulty code and the expected result on a working version. A screenshot of the error page helps the person reproduce the symptom. The request path, runtime error and relevant configuration give that person something to investigate.

Write down which parts of the hosting setup can affect that request. The WordPress project publishes recommended hosting requirements covering PHP, the database and HTTPS. Those recommendations answer a different question from the one posed by a rehearsal. For this exercise, identify the PHP series and extensions the affected site actually uses, the database engine, the active plugin version and the web server route that sends the request to PHP. If a team knows its hosting control panel by name but lacks an inventory of the worker process and database, the control panel is an imprecise description of the target. The package version visible in the Debian lab is likewise a fact about the lab. Keep it alongside the corresponding fact about the server.

A shell check gives the engineer a quick starting point. On a Debian instance with PHP CLI installed, the following Bash commands display the CLI version, the configuration files the CLI loads and the modules present in that command environment. The example expects a working PHP binary and makes no package or configuration changes.

php --version
php --ini
php --modules

Treat the result as an inventory of the CLI process. The PHP manual describes a separate set of process and configuration choices for FastCGI Process Manager, including pools that can use different configuration and run workers under different users. A hosting setup that uses FPM needs a separate inspection of the pool or service that handles the browser request. Compare the relevant directives, the worker identity and the error log for that request. A local script that succeeds under the developer’s shell account establishes that the shell command works with its own environment. A browser test through the lab’s web server exercises the service path where a permissions issue or a missing module may actually appear.

Decide how much data the fault requires before choosing the test input. A reproducible problem with pagination might need a small set of synthetic posts, a taxonomy and the plugin options that drive the query. A template warning might need one record with an empty custom field. Use the smallest fixture that still triggers the failure. That choice makes the case easier to hand to a colleague and reduces the temptation to copy a client database onto a workstation. If a client-authorised copy is necessary, establish where it can live, who may open it and when it will be removed. Strip data and credentials unrelated to the reproduction under the team’s approved process. Check whether the application has mail, webhook, analytics or payment settings that would contact external systems during a local test.

Treat configuration changes as part of the investigation record. Suppose the lab starts with copied settings for a staging hostname and the browser lands on that hostname every time the tester opens an archive. The lab may have reached PHP correctly and then followed an application redirect. Change the test configuration deliberately and preserve the original observation. A separate local database identity gives the developer a concrete way to check which database the lab connects to before changing values. Keep local credentials separate from the application copy, and verify that an assistant, scheduled job or script acting in the working directory cannot accidentally apply the same command to the hosted instance. A familiar site title on screen offers weak evidence about which database is open.

WP-CLI can shorten that feedback loop once it is installed from the project’s documented distribution path and pointed at the intended local WordPress root. Its wp search-replace command understands PHP serialised values. It also has a dry run that reports proposed changes without writing them. In a disposable local copy, someone investigating stale branding could first check how many occurrences a substitution would affect. The strings in this Bash example are literal sample phrases. Run it from the root of the intended local installation with the test database already configured.

wp search-replace 'Old brand text' 'New brand text' --dry-run

Inspect the report and table scope before applying any replacement. A plugin can maintain data beyond the tables included by default, and a multisite installation introduces additional scope choices that the command documentation describes. An unexpectedly broad report is a reason to refine the test, especially when the team needs to separate a stored content change from an application bug.

Another worthwhile check is the integrity of the distribution files the team thinks it is testing. In the same local setup, run the following in Bash to check the installed core files.

wp core verify-checksums

The command compares installed WordPress core files with the project’s published checksums. The command documentation explains the version and locale arguments for cases where the default selection needs to be made explicit. Treat the result as evidence about the files covered by that comparison. Plugin files, themes, the database, uploaded media and server configuration each need their own inspection if they are relevant to the case. A successful comparison leaves those parts of the reproduction open. Record an unexplained mismatch before replacing anything. The presence of a modified file may be precisely what made the failure reproducible.

A short test matrix usually teaches the team more than an elaborate one. Start with the known state that fails and one plausible change, such as the previous plugin release under the same PHP configuration. If the first state fails and the second passes, repeat the original test once with a fresh request and record the error or result for both. Change one relevant variable per run when the case allows it. A simultaneous plugin rollback, PHP update and theme swap can produce a useful emergency recovery on a server, but it leaves the cause unsettled in a rehearsal. The Debian workstation gives the team time to separate those changes before deciding which risk belongs in a production release.

The lab report should travel with the fix. Include the fixture or its construction steps, the commands that can be repeated, the exact request or user action and the difference observed between the two states. Mention which server conditions the lab could not represent, such as a hosting proxy, a rule managed by another provider or an extension that differs between environments. Mark those as checks for staging. A short record that identifies one missing dependency gives the next person a real task. A declaration that the entire production stack was simulated invites them to skip the very check that still matters. The test’s authority comes from the conditions it reproduced and the evidence it preserved.

Local automation and the clean runner

The first version of a useful WSL automation can be small enough to read during a code review. A Windows editor saves the change, a Linux shell runs the project’s validation and the result decides whether the change is ready to commit. Give that validation one named entry point in the repository. The developer can run it from the Debian checkout and a colleague can invoke it in continuous integration. Put machine-specific setup in onboarding instructions and keep the validation independent of personal directories, terminal shortcuts and any shell aliases the original author happens to have. Once the command is shared, the team has a fixed place to improve diagnostics or add checks without asking every colleague to rewrite a local batch file.

Windows automation can call that same entry point through WSL. Select the distribution explicitly and start from the intended Linux working directory. The following PowerShell example assumes an existing distribution called Debian and an executable Bash script tracked at scripts/check.sh in a hypothetical Linux checkout. Use the actual path and distribution name on the machine running it.

wsl.exe --distribution Debian --cd /home/dev/projects/site --exec bash ./scripts/check.sh
$LASTEXITCODE

A reviewer can reason about the selected distribution, working directory and command directly from this call. If a script reads relative fixture paths, the working directory becomes part of its interface. Capture the exit status before running another native command in the same PowerShell session. A job should identify which check failed and use the native command’s status to decide whether subsequent release steps may proceed.

Start the shared check with something observable. A PHP project could run the CLI syntax checker over the source files it plans to publish. When the PHP CLI is installed and the team has checked out the application, a developer can run a small example inside Bash. The sample file is part of the hypothetical checkout.

php -l ./src/example.php

The PHP manual describes the syntax-only option. A passing result here supports one claim about the file’s syntax under that PHP binary. The command does not exercise a database connection, render a page or call the hosting pool. Use a separate integration check where the project depends on those paths. For instance, the WordPress rehearsal might verify that a particular local request renders a populated archive. Keep its failure output distinct from the syntax check so the reviewer can immediately see whether to inspect PHP parsing, fixture construction or the server process.

A long-lived WSL installation gradually acquires history. Yesterday’s dependency install may have left a module or binary on the path that today’s checkout quietly assumes. One developer may have a local config file ignored by Git. Another may have installed a second package to experiment with and forgotten that the project’s check uses it. A clean runner exposes some of that hidden setup. GitHub documents that, except for its single-CPU hosted runner class, a GitHub-hosted runner is a new virtual machine. Its images carry their own preinstalled tools. Use the workflow to declare the required runtime and install project dependencies explicitly. A new VM still has an image and defaults, so document what the job expects from those as well.

When local and hosted runs disagree, log a few fingerprints close to the failed test. Print the selected runtime’s version, identify the executable that ran, and record the test entry point and the application revision. Check whether a path comes from the project’s dependencies or from the base environment. Compare the earliest observable difference before diagnosing the most conspicuous later error. A deployment script may fail after the application cannot connect to a database, while the original difference is that the local developer ran it with a configuration file that the hosted job never received. Clear observations keep the team from blaming WSL for differences that can be reproduced between any two Linux environments built with different inputs.

Keep CI credentials and workstation credentials separate. The test scripts should tell an operator which variables are required, use disposable accounts where feasible and avoid dumping their full environments when a test fails. Local automation that calls a remote resource also deserves a visible check of its target. Make a deployment target an explicit argument when a script has permission to write to more than one environment. Give the command a low-risk verification step before it writes and keep an independent record of the revision it was meant to deploy. This is an engineering choice for teams using WSL alongside Windows tools. The same discipline applies when a teammate runs the release from a native Linux shell or a hosted job.

Containers provide another way to distribute parts of a test environment. Docker documents a WSL 2 backend for Docker Desktop and describes how its distribution integration gives access to Docker commands from a selected distribution. It also documents differences in what the integration can do under its Docker VMM mode, including limitations on bind mounts from Linux distribution paths. Confirm the engine and integration mode before writing onboarding instructions that assume a Linux checkout can be mounted directly. A command entered in Debian may act on an engine managed elsewhere. The actual engine, image and mount mode belong in the reproduction notes when a bind mount or missing file is part of the failure.

Docker provides a command for displaying the current context, and Compose provides a command for rendering the configuration it would use. With a working Docker CLI and Compose in the intended project directory, these examples display a context name and list the resolved service names without printing the full Compose configuration.

docker context show
docker compose config --services

Check the target and service selection before issuing a write or a start command. Use the context name as a starting point for inspecting the selected endpoint if it is unfamiliar. The service list helps confirm that the shell is reading the intended project, especially when a checkout contains multiple Compose files or uses profiles. A command that printed the expected name gives the engineer one more concrete observation. It still leaves the application image, secret delivery and volume contents to be verified separately when the case depends on them.

A team can apply the same method to jobs that involve no containers at all. A marketing site might have a script that checks whether images referenced by articles exist in the exported tree, verifies that generated pages have a title and exercises a redirect rule against a local fixture. Give the fixture some awkward but realistic inputs, including an accented filename or a nested archive path if those are supported on the actual site. Record the inputs alongside the expected outputs in a form that a second person can read. A contractor should be able to confirm the observed failure on a clean system without learning the original author’s directory layout or borrowing an account with access to the live CMS.

The strongest handoff starts with a failed check the next person can see and ends with the same check passing after a defined change. Keep the log concise enough to identify the failure while leaving detailed output available for the person diagnosing it. Preserve the application revision and runtime assumptions. If the check requires a Windows browser as well as the Linux shell, label those as separate actions and say where each runs. An automation has a useful boundary when its result can be repeated by somebody else. Debian inside WSL is one place to reach that result. A hosted runner, a staging server and a colleague’s machine each offer a different opportunity to find assumptions the original workstation concealed.

The point at which a workstation test ends

For a Windows-based team, WSL earns its place through ordinary work. Someone can change a shell script in a familiar editor, run it under a Linux user, inspect the resulting files and open a local preview without switching machines. A sensible adoption decision begins with a recurring task the team can name. A developer preparing a patch needs a repeatable shell and a clean checkout. A site operator rehearsing a PHP change needs representative package and application configuration. A support engineer debugging a network fault may need the exact conditions of a remote server. The first two often fit on a workstation. The third depends on which part of the network actually produced the fault.

Treat a clean workstation experiment as the first rung of a verification ladder. A local application test is cheap to repeat and gives the engineer a convenient place to change one thing at a time. A controlled staging environment brings the real hosting stack closer, including its operating system configuration, account privileges and proxy layout. A supervised production check observes the conditions customers actually encounter. Write down what each rung establishes. A successful WSL test of a redirect handler gives evidence about the application code. If production has an external cache or a proxy that redirects before PHP receives the request, repeat the relevant browser or HTTP check through that layer on staging before approving the release.

When an exercise depends on the machine’s boot process, choose the environment accordingly. A student editing unit files can learn a great deal from service management in a WSL distribution. An administrator practising the recovery of an unbootable Linux machine needs access to the boot path they intend to recover, with its firmware, virtual or physical disks and a console available before the root filesystem is mounted. A separate virtual machine can make those controls available for a reproducible exercise. Microsoft documents full guest operating systems and virtual networking in Hyper-V. Check the supported Windows edition and hardware before adopting that particular hypervisor. A lab for firmware, drivers or device behaviour may need the corresponding physical equipment if the failure depends on a real component.

The separation is also useful when a team measures performance. Record which system owns the files, which processes share the machine and where the incoming request originates. A local build time is evidence about the machine and configuration that produced it. To investigate an effect, hold the project revision and inputs steady, use comparable caches and repeat the run enough to distinguish a pattern from a one-off result. If a client’s production problem is a queue backing up under traffic through a reverse proxy, a single request from the Windows host answers a narrower question. Measure the service on representative infrastructure for decisions about customer load, and retain the local measurement when it helps explain the cost of the development workflow.

An incident can give the boundaries more weight. Suppose a site operator has an archive containing an unfamiliar executable discovered during a compromise. The task changes from reproducing a normal application defect to handling potentially hostile material. Select an approved analysis environment for the material and threat before opening it. WSL’s ability to exchange files with the host and launch tools across environments is precisely what makes everyday work convenient. Treat that connection as part of the incident analysis. For a managed organisation, the incident process should specify where evidence may be copied, how access is recorded and who can run any recovered sample. A normal local WordPress sandbox containing work credentials has a different purpose and different exposure.

A dedicated staging server makes sense when several people need the same results at the same time. In an agency, one person may update a theme, another may review a preview and a third may check that the checkout flow still works. Their workstations can each host useful Debian instances. The shared environment gives the group a common application revision and review target. It also gives the operator a place to practise deployment, retain logs and reset a shared fixture under an agreed process. When the preview is subject to client access restrictions, give it its own access policy and ownership. The decision to maintain it follows from how the team collaborates and what it needs to verify.

On an employer-managed computer, adding WSL changes the software the organisation must be able to support. Microsoft provides an enterprise setup guide for WSL, covering deployment and management considerations. A team adopting it can define the approved distribution, update route and support owner as part of onboarding. Record what work may use mounted Windows drives, where credentials belong and which applications may make network listeners reachable beyond the workstation. Choose examples that operate under the actual policy. A teammate who lacks administrator rights should be able to distinguish an expected policy block from a broken installer and route the request to the right person with the relevant error.

The practical decision becomes clearer when it is phrased in terms of responsibility for a failure. If the owner is a developer trying to fix an application error, provide a local fixture and a repeatable command. If the owner is a systems administrator validating a kernel change, provide a guest or machine whose boot state they control. If the owner is the service operator trying to understand customer impact, provide a representative route to the service and a way to see its logs. Choose the environment that exposes the fault to its owner. Teams can keep WSL on Windows machines even when an important subset of tests belongs on separately managed Linux hosts.

An onboarding exercise can prove more than a slide about tool choice. Give someone a clean Windows 11 workstation that meets the organisation’s requirements and ask them to install the approved distribution, check its identity, clone a practice project and run its validation. Let them use the editor they know. Add a genuine exercise such as reading a Linux service log or identifying the listener used by a local preview. Record where the written procedure fails to predict what they see. A second person completing the workflow from written instructions tests the quality of the setup guide as well as the state of the machine. The resulting guide can focus on the places that actually cost people time.

The best reason to keep Debian on that Windows machine may be a modest one. The next time a change looks harmless in the editor, the person who made it can open the terminal, run the same check a colleague will run and see the failure while the reasoning behind the change is still fresh. The application can then move to staging with a record of what passed and what still needs the hosted environment. Linux becomes part of the workday at the point where a test is cheaper to run than to skip. The Windows browser and editor remain at hand. The release proceeds with evidence gathered under the conditions that matter to it.

Author:
Jan Bielik
CEO & Founder of Webiano Digital & Marketing Agency

This article is an original analysis supported by the sources cited below

How to install Linux on Windows with WSL
Microsoft documents the Windows installation commands, the default Ubuntu choice, the named distribution option, the first launch, and online and offline alternatives.

Comparing WSL Versions
Microsoft compares the two WSL architectures, including system call handling, the managed virtual machine, systemd support, file access, and WSL servicing.

Basic commands for WSL
Microsoft documents installation, custom storage locations, launch, version checks, updates, export and import, and distribution lifecycle commands.

What is the Windows Subsystem for Linux?
Microsoft describes the Linux environment, per-distribution filesystem, and development tools available through WSL alongside Windows.

Set up a WSL development environment
Microsoft explains initial Linux account creation, per-user installations, Windows Terminal profiles, and package maintenance inside WSL.

What is Windows Terminal?
Microsoft identifies Windows Terminal as the tabbed host application for shells such as PowerShell and Bash through WSL.

Troubleshooting Windows Subsystem for Linux
Microsoft documents how to identify WSL versions and diagnose installation failures caused by disabled virtualization features.

Frequently Asked Questions about Windows Subsystem for Linux
Microsoft’s general WSL reference states which processor architectures WSL supports.

Use systemd to manage Linux services with WSL
Microsoft documents systemd support, how it is enabled for a WSL distribution, and how enabling it changes the Linux process hierarchy.

Debian Releases
The Debian project explains stable, testing, and unstable and lists Debian release numbers alongside their codenames.

Debian “trixie” Release Information
The Debian project’s trixie release page identifies the processor architectures supported by the same Debian release.

uname(1) — coreutils — Debian trixie — Debian Manpages
Debian’s packaged GNU coreutils manual describes the options for printing the kernel release and machine hardware name.

os-release(5) — systemd — Debian trixie — Debian Manpages
Debian’s manual entry explains the operating system identification file and the fields used for the display name, release identifier, and codename.

Chapter 6. Maintenance and Updates: The APT Tools
The Debian Administrator’s Handbook explains the link between APT’s package inventory and the repositories configured for the Debian installation.

Install and manage packages
Ubuntu’s documentation explains APT installation and updates, and identifies the Ubuntu repositories used to build its available package index.

Working across Windows and Linux file systems
Microsoft explains where to keep project files, how to open Linux files in Windows File Explorer and how commands cross the Windows and Linux boundary.

WSL interop — Windows and Linux integration
Microsoft documents shell interoperability and explains why a Linux build or Git checkout can suffer on a mounted Windows volume.

Adjust case sensitivity
Microsoft describes default name matching on Windows and Linux, the per-directory NTFS case flag and pitfalls for Windows applications.

File Permissions for WSL
Microsoft explains the permission checks and optional Linux metadata for mounted Windows files and the identity used by Windows apps to access Linux files.

Developing in WSL
The Visual Studio Code documentation explains remote editor setup, server startup, extension placement, terminal context and Git integration for WSL.

Source control in VS Code
The Visual Studio Code guide explains how its Source Control view works alongside command-line Git on the same repository.

Git – gitattributes Documentation
The Git documentation explains per-path line ending rules and shows how to give shell scripts LF line endings in the working directory.

Run Linux GUI apps on the Windows Subsystem for Linux
Microsoft documents WSL 2 support for individual X11 and Wayland applications, Windows desktop integration and a simple X11 application test.

GitHub – microsoft/wslg: Enabling the Windows Subsystem for Linux to include support for Wayland and X server related scenarios · GitHub
The WSLg project documents the system distribution and the graphics and audio resources it exposes to Linux applications.

Ubuntu – Details of package jq in noble
Ubuntu’s package index identifies jq as a command line JSON processor available in Ubuntu 24.04 LTS.

apt(8) — apt — Debian trixie — Debian Manpages
The Debian APT manual distinguishes package index updates, package inspection, upgrades, removals and cleanup of unused dependencies.

systemctl(1) — systemd — Debian trixie — Debian Manpages
The systemctl manual describes listing and inspecting service units, starting and stopping them and configuring them to start automatically.

journalctl(1) — systemd — Debian trixie — Debian Manpages
The journalctl manual documents filtering the systemd journal by unit and by boot.

Accessing network applications with WSL
Microsoft documents the NAT and mirrored connection paths, the use of loopback and LAN addresses, and the role of DNS tunneling, proxy settings and Hyper-V firewall.

Advanced settings configuration in WSL
Microsoft explains the scope and location of WSL configuration files, the network settings available to WSL 2, and when changes take effect.

Configure Hyper-V firewall
Microsoft describes effective Hyper-V firewall policy for WSL, including PowerShell inspection, loopback settings, profile behavior and the role of enterprise controls.

Enterprise environment: Set up Windows Subsystem for Linux for your company
Microsoft’s enterprise setup guide explains Intune management of WSL access and security settings alongside advanced networking controls.

http.server — HTTP servers
The Python standard library reference covers the test server’s command line, bind behavior, directory selection, HTTP file handling and security limits.

curl man page
The curl project documents scheme inference, response headers, per-request proxy exclusions and transfer time limits used by the lab.

ss(8) — iproute2 — Debian trixie — Debian Manpages
The Debian manual documents the socket inspection options that identify numeric listening TCP endpoints and show processes where available.

Test-NetConnection
Microsoft’s PowerShell documentation source explains how to test a specific TCP port and interpret the reported connection result.

getent(1) — manpages — Debian trixie — Debian Manpages
The Debian manual describes looking up addresses through the configured system name services with getent ahosts.

How to manage WSL disk space
Microsoft explains how a WSL 2 distribution’s virtual disk grows, how to inspect Linux free space and find the disk on Windows, and the prerequisites for expanding its ceiling.

Import any Linux distribution to use with WSL
Microsoft’s import tutorial shows how to register a Linux filesystem archive under a chosen name and install path and configure its default Linux user.

Chapter 2. Debian package management
The Debian Reference describes what APT update and upgrade do, how full upgrade differs, and where Debian records package activity.

compact vdisk
Microsoft’s DiskPart reference explains why deleting guest files does not automatically shrink a conventional dynamically expanding VHD and describes the compaction prerequisite.

free(1) — procps — Debian trixie — Debian Manpages
The procps manual describes the memory and swap columns reported by free and explains what its available memory estimate includes.

Free up drive space in Windows
Microsoft Support shows where Windows 11 File Explorer reports the available capacity on a Windows drive.

Requirements
WordPress publishes its recommended PHP, database and HTTPS requirements for hosting.

Options
The PHP manual documents the CLI flags for version, modules, configuration files and syntax checking.

FastCGI Process Manager (FPM)
The PHP manual describes FPM and the process, identity and configuration choices available for its worker pools.

Installing
The WP-CLI handbook gives the project’s installation and download verification instructions.

wp search-replace
The WP-CLI command reference explains serialised data, table scope, multisite options and the dry run.

wp core verify-checksums
The WP-CLI command reference documents WordPress core checksum comparison and the version and locale options.

WSL/src/windows/common/WslClient.cpp at master · microsoft/WSL · GitHub
Microsoft’s WSL client source shows argument handling for a selected distribution, working directory and explicit command.

about_Automatic_Variables
PowerShell documents the automatic variable that stores the exit code from the last native program.

GitHub-hosted runners
GitHub explains hosted runner environments, preinstalled tools and the single-CPU runner exception.

Docker Desktop WSL 2 backend on Windows
Docker describes its WSL integration and the different command and bind-mount behaviour under Docker VMM.

docker context show
The Docker CLI reference explains how to display the active context name.

docker compose config
The Compose CLI reference describes resolved configuration and the option that displays service names.

Hyper-V virtualization in Windows Server and Windows
Microsoft describes separately managed virtual machines, virtual networking and the Windows editions that include Hyper-V.

This article was prepared with the assistance of artificial intelligence tools. The content underwent expert human review, and Webiano Digital & Marketing Agency assumes editorial responsibility for its final version and publication.