The most common question after "Debian Testing" is: how do I actually get there? Do I install Stable and upgrade, or jump straight in? Short answer: jump straight in. This page walks you through it.
The First Question
/etc/apt/sources.list to point at Testing (forky),
then run apt full-upgrade. Technically valid —
and the Debian wiki does recommend upgrading from current Stable
rather than skipping a release.
In practice, the step upgrade can cause dependency conflicts,
held-back packages, and config file prompts that trip up new users.
The smoother path if you're starting fresh is a clean Testing install.
From the Debian Wiki
"Testing" sounds alarming to anyone who wants a computer that works. The name is misleading. Here's what it actually means — sourced directly from wiki.debian.org/DebianTesting.
Why It Matters
Beyond stability, Testing's rolling nature has practical benefits that matter immediately — especially if you're gaming or running newer hardware.
On Debian Stable, you do a major upgrade every two years or so —
from Bookworm to Trixie, from Trixie to Forky. Each of these is
a significant event requiring planning and occasionally causing breakage.
On Testing, there is no version upgrade. You run
apt update && apt upgrade and your system is current.
Today's packages flow in. Your configuration never needs to be
migrated between releases because there are no releases.
sudo apt update && sudo apt upgrade
# That's it. Do it weekly.
# You will never reinstall to "upgrade".
Mesa is the open-source OpenGL and Vulkan driver stack for AMD (RADV, RadeonSI) and Intel (ANV, Iris) GPUs. It is one of the most actively developed pieces of graphics software on Linux. New Mesa versions regularly unlock better game compatibility, higher frame rates, and support for newer Vulkan extensions — including ray tracing on RDNA2+ cards. On Debian Stable, Mesa lags significantly behind. On Testing, you get current Mesa within weeks of upstream release.
glxinfo | grep "OpenGL version"
# or
vulkaninfo | grep driverVersion
The Linux kernel adds hardware support continuously. If you bought a GPU, Wi-Fi card, or NVMe controller in the last year or two, Debian Stable's older kernel may lack the driver. Testing ships a recent kernel — typically within a few months of upstream LTS releases — which means better out-of-the-box support for newer hardware without backport hunting. This matters especially for AMD RDNA3/4 GPUs and recent Intel Arc cards, both of which have received substantial kernel improvements.
uname -r
# Testing will typically show a 6.x kernel
# Stable ships with an older LTS kernel by default
The Linux gaming stack depends on current userspace. Proton (Valve's
compatibility layer for Windows games on Steam) gets better with
every Mesa update, every Vulkan extension that lands, every kernel
improvement to memory management. On Stable, you're gaming
on an older snapshot of all of these. On Testing, they move
together. Install gamemode to let games request CPU and
GPU performance mode on demand, and mangohud to overlay
frame timing and GPU stats.
sudo apt install gamemode mangohud
# Enable Steam Play (Proton) in Steam settings
# → Steam → Settings → Compatibility → Enable Steam Play for all titles
Wayland support in GNOME and KDE Plasma has improved dramatically with each release. Running Testing means you get these improvements as they land — better multi-monitor handling, fractional scaling, HDR support (where hardware allows), and smoother frame timing. Wayland on Testing with a current Mesa + kernel is a substantially different experience from Wayland on Stable. If Wayland gave you trouble on an older system, it's worth trying again on Testing.
echo $XDG_SESSION_TYPE
# wayland ← you're good
# x11 ← may need to select Wayland at login screen
The Process
Before you start — plan your partition layout
The installer will ask you about partitioning before it installs anything. Decide now so you're not guessing at a blue screen. The three decisions that matter:
Guided vs Manual
Guided — use entire disk is the right choice for a new machine or a wipe-and-reinstall. The installer handles everything. Choose Manual only if you're dual-booting or want custom partition sizes.
Separate /home?
Recommended for dedicated machines.
A separate /home partition lets you reinstall the OS without
touching your personal files. In Guided mode, pick
"Separate /home partition" when prompted.
Swap: file or partition?
Either works. A swap file is easier to resize later and is fine for Debian Testing. A swap partition is required if you plan to hibernate. Size: 2× RAM for machines with ≤8GB; equal to RAM if you have more.
For size guidelines, every mount point explained, and a disk diagram for common layouts, see Appendix C: Partitioning Your Disk →
debian-testing-amd64-netinst.iso (currently Forky).
This image is rebuilt daily — it installs whatever Testing currently is.
Unlike a point-release ISO, there is no version to go stale.
On Windows, the official Debian documentation points to the Debian CD FAQ §5 for USB writing on non-Linux systems. The recommended tool is Rufus — free, no install required, and critically: it writes the ISO in DD image mode, which preserves the hybrid image exactly as Debian built it.
Do not use: UNetbootin, Windows USB/DVD Download Tool, or the "ISO Image mode" in Rufus. The official Debian documentation explicitly warns that tools which modify the image will produce a broken installer. The Debian ISO is already bootable as-is — it needs to be copied, not rebuilt.
Verify the download first. Before writing, confirm your ISO matches the SHA256 checksum published on the same download page. In PowerShell:
Compare the output against the SHA256SUMS file on the download page.
They must match exactly.
Official methods from Debian Installation Guide §4.3 and Debian Wiki: CreateUSBMedia.
Identify your USB device first
cp method (official wiki)
dd method (alternative)
Write to the disk, not a partition.
/dev/sdb is correct. /dev/sdb1 is wrong.
Verify with lsblk before running either command.
Do not use unetbootin — it modifies the image.
If you have Windows Subsystem for Linux (WSL2) installed, you can run
the exact same dd command used on Linux — directly from
a Windows terminal. No GUI tools, no modified images, byte-for-byte identical
to what the Linux tab does.
Check if you have WSL
Identify the USB device from WSL
Write the image with dd
WSL2 mounts the physical disk directly.
The same rules apply as on Linux: write to /dev/sdb,
never /dev/sdb1. Verify the device with lsblk
before running dd. Getting the wrong device letter
will silently overwrite whatever is on that disk.
Don't have WSL?
Use Rufus in DD mode (Windows tab). The result is identical —
Rufus DD mode is a GUI wrapper around the same byte-for-byte copy
that dd performs.
The installer asks you to set a root password. What you choose here
determines whether your user account can use sudo.
sudo group. This is the simpler setup.
You run privileged commands with sudo from day one.
sudo commands
will fail with "not in sudoers." You must add yourself manually — see below.
If you set a root password: add yourself to sudo after first login
You must log out and back in after running usermod.
Group membership changes do not apply to your current session — even though the
command succeeds immediately, sudo will be denied until you start a fresh login.
"Guided — use entire disk" is fine for a dedicated Linux machine and will create
a sensible layout automatically. For dual-boot with Windows, choose "manual"
and leave your Windows partition alone. For a dedicated machine where you
want to separate /home from / (recommended — lets you
reinstall without losing your data), choose "Guided — use entire disk and set
up LVM" or "manual."
Appendix C: Partitioning — full breakdown of schemes, swap, and size guidelines →
The installer offers a software selection menu. You'll see checkboxes for "Debian desktop environment," "GNOME," "KDE," "XFCE," etc. Select the desktop you want here, or deselect everything and install manually after boot. Always keep "standard system utilities" checked.
Install GRUB to the primary disk (the one you're installing Debian on). For UEFI systems this goes to the EFI partition. For dual-boot, GRUB will usually detect Windows automatically — confirm after first boot.
If You're Already on Stable
If you already installed Debian Stable and want Testing, you can migrate — but be aware this is the "step upgrade" that can cause friction, especially if you have a lot installed. A clean install of Testing is cleaner. That said, here's how to do it if you need to:
Recommendation: If you're early enough in your install that you haven't configured much yet — just reinstall with the Testing netinst. You'll save yourself potential dependency headaches. The step upgrade is worth doing only if you have significant customization you don't want to redo.
If you do want to proceed with the upgrade, the process is editing
/etc/apt/sources.list to replace references to your Stable
codename with testing:
Why full-upgrade instead of upgrade?
Regular apt upgrade won't install or remove packages to satisfy
dependencies — it just skips them. full-upgrade (formerly
dist-upgrade) is allowed to add and remove packages to complete
the upgrade. You need this when moving between Debian releases.
After You're In
Unlike Stable, Testing gets package updates continuously as they
migrate from Unstable. Run apt update && apt upgrade
at least weekly. Letting updates pile up for months is where problems
accumulate — the more you skip, the more there is to reconcile at once.
sudo apt update && sudo apt upgrade
# run this at least once a week
Testing earns its name. Packages from Unstable migrate to Testing after 10 days without reported critical bugs — most of the time. You may occasionally update and find something behaves differently, a dependency fails, or a config changes. These are almost always easily resolved — the Debian bug tracker and forums will have your answer. This is part of what makes Testing a good learning environment: real problems with documented solutions.
apt list --upgradable # see what just updated
sudo apt install -f # fix broken deps
sudo dpkg --configure -a # configure half-installed pkgs
Debian Testing doesn't get the same level of timely security patching
as Stable — fixes come through as normal migration, not a dedicated
security channel. For a desktop machine this is an acceptable trade-off;
for anything internet-facing or production, use Stable. Your
sources.list should include testing-security
which helps, but be aware of this difference.
grep security /etc/apt/sources.list
# should see: testing-security main
You can install multiple desktop environments and window managers simultaneously and choose at the login screen. This is one of the easiest experiments to run — it costs only disk space and a few minutes. The display manager (SDDM, LightDM, GDM) gives you a session menu at login where you pick which one to use.
sudo apt install fluxbox xfce4 i3
# log out → choose a session at login screen
# your dotfiles and configs stay separate per WM
Debian Reference
Every Debian release has a version number, a codename, and several permanent aliases. Understanding the difference determines whether your system silently drifts when a new Stable ships — or stays exactly where you left it.
They're all Toy Story characters. The naming tradition was started by Bruce Perens during his time as Debian Project Leader. Buzz (Lightyear), Rex (the dinosaur), Bo (Peep), Hamm (the piggy bank), Slink (the Slinky dog), Potato (Mr. Potato Head), Woody, Sarge, Etch (Etch A Sketch), Lenny (the binoculars), Squeeze (the Little Green Men), Wheezy (the penguin squeeze toy), Jessie, Stretch (the octopus), Buster (Andy's dog), Bullseye (Woody's horse), Bookworm, Trixie (the triceratops), Forky (Toy Story 4). And Sid — the toy-destroying kid next door — is permanently Unstable. Intentionally.
These names always point to the same role regardless of which release
currently holds it. Use them in /etc/apt/sources.list when you
want that behavior — but know the trade-off.
| Alias in sources.list | Currently points to | What happens when next Stable releases |
|---|---|---|
| stable | Trixie (Debian 13)Current release | Silently shifts to Forky. Your next apt upgrade becomes a full version jump. Surprising if unintentional. |
| oldstable | Bookworm (Debian 12)Previous release | Shifts to Trixie. Bookworm becomes oldoldstable. |
| oldoldstable | Bullseye (Debian 11)Two releases back | Shifts to Bookworm. Bullseye may stop receiving LTS updates. |
| testing | Forky (Debian 14)Current Testing — recommended for sources.list | When Forky becomes Stable, testing shifts to the next codename (Debian 15). You stay rolling automatically — this is the right alias for a Testing system. |
| unstable also: sid |
Sid (never released)Direct developer uploads | Sid never becomes Stable. Packages migrate from here into Testing. Always at the bleeding edge; no gate-keeping. |
| experimental | Pre-Unstable stagingNot a real suite | Packages too risky for Unstable. Developers use it to solicit early testing. Never use as a full source — add specific packages only. |
The recommendation: in your /etc/apt/sources.list,
use testing — not forky. If you pin the codename,
your system will freeze on Forky when it eventually releases as Stable and stop
receiving new packages. Using testing keeps you rolling
through every future release automatically.
Every version, every name, back to the beginning. The connection to Toy Story has held for 30 years of releases.
| Version | Codename | Released | Status | Toy Story character |
|---|---|---|---|---|
| — | Sid | Never | Always Unstable | The kid next door who destroys toys. |
| 14 | Forky | In development | Current Testing | The spork from Toy Story 4. |
| 13 | Trixie | 2025 | Current Stable | The triceratops who loves computers. |
| 12 | Bookworm | June 2023 | Old Stable | The bookworm from Andy's room. |
| 11 | Bullseye | August 2021 | Old Old Stable | Woody's horse. |
| 10 | Buster | July 2019 | Archived | Andy's dog. |
| 9 | Stretch | June 2017 | Archived | The purple octopus from Toy Story 3. |
| 8 | Jessie | April 2015 | Archived | The cowgirl. |
| 7 | Wheezy | May 2013 | Archived | The rubber penguin squeeze toy. |
| 6.0 | Squeeze | February 2011 | Archived | The Little Green Men (aliens). |
| 5.0 | Lenny | February 2009 | Archived | The binoculars. |
| 4.0 | Etch | April 2007 | Archived | The Etch A Sketch. |
| 3.1 | Sarge | June 2005 | Archived | The sergeant of the green army men. |
| 3.0 | Woody | July 2002 | Archived | The cowboy. The protagonist. |
| 2.2 | Potato | August 2000 | Archived | Mr. Potato Head. |
| 2.1 | Slink | March 1999 | Archived | Slinky Dog. |
| 2.0 | Hamm | July 1998 | Archived | The piggy bank. |
| 1.3 | Bo | June 1997 | Archived | Bo Peep. |
| 1.2 | Rex | December 1996 | Archived | The anxious T-Rex. |
| 1.1 | Buzz | June 1996 | First release | Buzz Lightyear. The beginning of the tradition. |
Releases prior to 1.1 (0.93, 0.91, etc.) predate the Toy Story naming convention and used internal version numbers only. The first official release with a codename was 1.1 Buzz in June 1996 — the same year the first Toy Story film released.