Choose a safe Linux lab, create it with WSL 2 or an Ubuntu virtual machine, verify its identity, and preserve a recovery path before experimenting.
What you will be able to do
- Choose a Linux lab method from host compatibility, isolation, and recovery needs.
- Create and start a Linux environment with WSL 2 or an Ubuntu virtual machine.
- Verify the active user, working directory, kernel, and operating-system identity.
- Refresh package information and preserve a repeatable recovery baseline before experiments.
01
Define the Lab Boundary
A Linux lab is a place where you can run commands, inspect results, and recover from mistakes. Your first goal is not maximum performance; it is a clear boundary between practice work and valuable personal data.
Choose a supported Ubuntu LTS release so the documentation and security-maintenance window remain predictable. Keep personal files outside the lab, and record which method, distribution, and user account you created.
A useful first lab must start reliably, reach a terminal, and be replaceable without risking the host computer. Those conditions matter more than whether Linux owns the physical machine.
02
Choose a Lab Route
On a compatible Windows computer, WSL 2 is the quickest route to a Linux terminal integrated with Windows. It uses a real Linux kernel in a managed environment and avoids repartitioning the computer.
A Multipass virtual machine is a better fit when you want a separate Ubuntu instance that can be created again. It works across Windows, macOS, and Linux, while keeping the guest system distinct from the host.
Use a direct Ubuntu installation for a spare or dedicated device. Before changing disks, back up important data and test hardware with Try Ubuntu; do not make direct installation the first choice on a valuable daily computer.
03
Check Before You Create
Match the route to the host before downloading or installing anything. For the simplified WSL setup, Windows must meet Microsoft's supported version requirement; a virtual-machine route also needs enough memory, storage, and virtualization support.
For a full Ubuntu Desktop installation, compare the device with the current release requirements. Ubuntu 26.04 LTS recommends a dual-core processor, 6 GB of memory, and 25 GB of storage.
Confirm the target as carefully as the capacity. Installation-media creation erases the selected USB drive, so copy needed files elsewhere and verify the drive identity before writing the image.
04
Create the WSL Lab
Open an administrator terminal on a supported Windows host and run `wsl --install`. The normal workflow enables the required features, installs Ubuntu by default, and may ask you to restart Windows.
After restart, open the installed distribution and let its first-run setup finish. Create the Linux user name and password you will use inside the lab; these credentials are separate from the visible Windows sign-in flow.
If you need a different distribution, inspect the available choices with `wsl --list --online`, then install one with `wsl --install -d <Distro>`. Keep the selected name in your lab notes.
05
Create an Ubuntu VM
Install Multipass from its official package for the host, then confirm the command is available with `multipass version`. This separates a missing application from a problem inside a future instance.
Use `multipass find` to inspect available Ubuntu images. Create and start an instance with `multipass launch`, then enter it with `multipass shell <name>` when the launch output identifies its name.
Treat the instance as disposable infrastructure. Record the image and command choices instead of filling the guest with irreplaceable data; repeatable creation is the recovery advantage of this route.
06
Verify the Running System
Do not stop at a terminal prompt. Run `whoami` to confirm the active Linux user and `pwd` to see the current directory; together they show whose session you opened and where commands begin.
Run `uname -r` to display the running kernel release. Then inspect `/etc/os-release` with `cat /etc/os-release` and confirm the distribution identity expected for the lab.
Read outputs before copying them into notes. A convincing baseline contains the method, distribution, release, user, working directory, and kernel result, not merely a screenshot of an unlabeled prompt.
07
Refresh Package Information
Package tools use a local index to know which versions are available from configured repositories. Run `sudo apt update` to refresh that information; this step does not mean that every installed package has already changed.
Review the command result for repository or network errors. When you are ready to change installed packages, `sudo apt upgrade` presents the upgrade set and asks for confirmation.
Keep discovery and modification separate in your mental model. Refresh information first, inspect the proposal, and then approve an upgrade when the lab has a recovery path and enough time to finish.
08
Preserve a Recovery Baseline
A recovery baseline is the known state you can recreate before the next experiment. For WSL, keep the distribution name and setup notes; for Multipass, keep the image choice and launch command.
If your chosen virtualization tool supports snapshots, a snapshot can shorten recovery, but it is not a replacement for separate copies of valuable data. The safest lab contains no unique personal material.
Finish with one deliberate test: close the terminal, start the environment again, and repeat the identity checks. Successful restart plus recorded creation steps proves more than a terminal that happened to work once.
09
Recap Before Practice and Prove
A safe Linux lab separates experiments from valuable host data. Choose a supported Ubuntu LTS baseline and write down the route, distribution, and account you create.
WSL 2 is a fast Windows route to a Linux terminal. Multipass provides a separate Ubuntu virtual machine, while direct installation belongs on a prepared spare device with a verified backup.
Check compatibility and storage before creation. When writing installation media, confirm the USB target because the selected drive is erased.
Verify more than the prompt: identify the current user and directory, then inspect the kernel release and operating-system identity. Save those outputs as the lab's initial state.
Refresh package information before approving upgrades. Preserve repeatable creation notes, restart the lab, and rerun the checks so recovery is part of the lab from its first day.