Steam Machine SSD Upgrade: The Spec Valve Doesn’t Publish

Valve publishes the Steam Machine’s dimensions, its power draw at the wall, and a teardown philosophy generous enough to include screw-mounted rubber feet so that nothing is ruined when you open it. It does not publish the one number that decides whether a storage upgrade will survive: how much sustained power the M.2 slot can deliver. That gap cost me an afternoon. I fitted a drive I own, trust, and had been running in another machine for months, then watched it vanish from the PCIe bus a gigabyte into every attempt to install SteamOS. The kernel’s own advice was wrong, and the answer turned out to be sitting in a crash counter inside the drive.

Why this Steam Machine SSD upgrade should have been routine

The base Steam Machine ships with a 512GB Kingston drive, and 512GB is not a serious allocation in the era of 150GB installs. Valve’s answer is built into the hardware: the SSD daughterboard carries a full-length M.2 2280 slot, the fan panel lifts away without drama, and the company’s own positioning says this is a PC that happens to live under a television. I had the obvious candidate to hand. A Sabrent Rocket 5 2TB had spent months in my Windows gaming laptop running sustained workloads without complaint: a PCIe Gen5 drive on Phison’s E26 controller, exactly the class of part a PC builder is likely to have spare. The machine invites this upgrade, and the audience Valve courts is the audience most likely to own a drive similar to this one.

If you want the version of this upgrade where the drives behave themselves, Rebecca’s Steam Deck SSD upgrade group test covers three that do.

Opening the machine

Access is the best serviceability Valve has shipped: the fan panel lifts away and the M.2 bay sits in plain view on its own board. Then the story wobbles at a single component. The stock 2230 drive is retained by a bare hex nut standoff rather than a captive thumbscrew, and fitting a 2280 drive means unthreading that nut and re-seating it at the far end of the board.

The failure

The SteamOS recovery image (steamdeck-oobe-repair-20260707.10, SteamOS 3.8.14, kernel 6.16.12-valve) boots from USB and reimages the internal drive. It partitioned the disk and created the filesystem without complaint, then died roughly a gigabyte into writing the OS image itself:

dd: error writing '/dev/nvme0n1p4': Input/output error

The kernel log carried the line that would frame the whole investigation:

nvme nvme0: controller is down; will reset: CSTS=0xffffffff, PCI_STATUS=0x10
nvme nvme0: Does your device have a faulty power saving mode enabled?
nvme nvme0: Try "nvme_core.default_ps_max_latency_us=0 pcie_aspm=off pcie_port_pm=off"
nvme nvme0: Disabling device after reset failure: -19

CSTS=0xffffffff means the kernel is reading all-ones from the controller’s registers, which is what a register read returns when the device is electrically absent from the PCIe bus. The -19 is ENODEV: even a controller reset could not bring the drive back. After each failure the drive reported a capacity of zero bytes until a full power cycle restored it.

Ruling out the failure everyone knows

The kernel message names its own suspect. Misbehaving NVMe power-state transitions are one of the best-documented failure modes in Linux storage, and the log line ships with the recommended fix attached. I applied it properly rather than approximately, confirmed at the controller that it had taken effect, and watched the installer die at the same place with the identical signature. The prescribed fix for the famous failure mode did nothing, because this was not the famous failure mode.

The other usual suspects went the same way, each ruled out on evidence:

• Firmware. The drive was already on Sabrent’s latest.
• Thermal shutdown. This drive warns at 87°C and shuts down at 89°C. It had spent one second of its entire life above the warning threshold, and it was failing at a composed 45°C. It runs hot in this chassis, as it turned out, but heat was not what was killing it.
• Signal integrity. A marginal PCIe link leaves a record in the error counters. Every counter read zero.
• The drive itself. Back in the laptop it ran sustained workloads without incident. Healthy SMART, no media errors, full spare capacity.

One observation deserved more weight than I first gave it. The drive also died during an internal erase operation, which barely touches the PCIe bus at all. Whatever was killing it did not care about the data link. It cared about what the drive was doing internally: drawing power to write NAND.

The counter that settled it

If the machine could not survive writing to the drive, the workaround was to do the writing somewhere else. The Kingston 512GB drive the machine ships with went into a USB enclosure, and I used Etcher to clone it onto the Rocket 5 via another enclosure. The clone booted to the Steam splash screen and hung there, every time, at the same point.

A boot hang on a cloned drive has plenty of boring explanations, and I worked through them from the recovery environment: the bootloader, the kernel, the partition labels SteamOS looks for. Structurally the clone was perfect. It still hung.

What settled it was a counter the drive keeps for itself. NVMe drives record every time they lose power without a clean shutdown, and that number is not something a bootloader problem can touch. Before the boot it read 40. After one hang it read 44. The machine had browned the drive out four times in a row while SteamOS attempted its first writes. Every software explanation died there. This was power delivery.

Finding the ceiling

NVMe drives expose host-selectable power states, and the Rocket 5 offers three operational ones. Testing each under sustained writes inside the Steam Machine produced the most useful table in this article:

State	Max power	Result under sustained write in the Steam Machine
PS0 (default)	11.5W	Drops off the bus within about a gigabyte
PS1	8.0W	Throughput collapses to 46 MB/s, then drops off the bus at 1.4GB
PS2	6.0W	Rock solid. 24GB written at a steady 2.1 GB/s, zero incidents

One command applies the cap:

nvme set-feature /dev/nvme0 -f 0x02 --value=0x2

The PS1 row is the one worth reading twice. At 8 watts the drive was not merely unstable; it ran forty-five times slower than at 6 watts, because the rail was sagging and the controller was starving before it finally fell off the bus. Capping the drive to 6 watts costs nothing, because 6 watts is the fastest stable operating point this slot can deliver. The Steam Machine’s M.2 power budget is published nowhere, and on this evidence it sits somewhere between 6 and 8 watts of sustained draw. That number is the difference between a half-hour upgrade and the afternoon this one took.

With the cap applied, the cloned SteamOS booted straight through the old hang point and into first-time setup. Wi-Fi connected, and Steam updated itself.

What an immutable OS does to a hardware workaround

The fix held, and then it did not. A day later I came back to a black screen and a machine that would not boot from anything.

SteamOS never edits itself. An update writes a complete fresh copy of the operating system alongside the running one and switches to it at the next boot. My power cap was a small service file living in the old copy. The update installed a pristine new one that had never heard of it, booted into it, and hit the first heavy write unprotected. The counter told the story again: 44 before the update, 55 after. Eleven brownouts before the machine gave up into an unbootable state.

This is the structural finding of the whole piece, and it reaches well beyond one drive. On an immutable operating system, a host-side hardware workaround is part of the mutable state the platform is designed to throw away. The design that makes SteamOS resilient for Valve is the same design that discards the owner’s repairs.

Why the fix cannot live below the OS

The tempting escalation is to push the cap below the operating system, where updates cannot reach it. Every route is closed, and the reasons dictate the shape of the real fix. The drive will not remember the setting: the NVMe standard allows a drive to save it, but this firmware refuses, and that refusal is Sabrent’s and Phison’s to change, not mine. Modifying the BIOS is signature-verified and bricks the board. Applying the cap before boot is pointless, because the kernel resets the drive when it starts up and the reset wipes any setting the drive was not willing to save. Anything applied before the kernel is erased the moment the kernel arrives, and the same reset fires every time the machine wakes from sleep.

That last constraint dictates the architecture. The cap can only live inside the OS, and it has to be reapplied on every boot and every wake.

The fix that survives updates

SteamOS holds its own files immutable, but it has to keep the owner’s settings somewhere, and those areas survive an update. Anything installed there outlives an image swap. The fix is three layers, all in places updates do not touch:

1. A service that applies the cap early in every boot, before anything heavy can write to the drive.
2. A sleep hook that reapplies it after every wake, because the reset on resume silently removes it, and a brownout mid-session weeks later would be a miserable fault to rediscover.
3. A self-healing timer. Master copies of everything live on the partition holding personal files, which no update touches. Every boot, and every six hours after, the machine checks both copies of the OS against those masters, reinstalls whatever an update removed, and logs what it found.

I did not assume the healer worked. I wiped the fix from the dormant copy of the OS deliberately and watched the log confirm the repair:

2026-07-15T13:51:05 ok self
2026-07-15T13:51:05 HEALED other(/dev/nvme0n1p6) (artefacts reinstalled)

The machine has been stable since: the cap enforced under load, the drive idling at a fraction of a watt, and the brownout counter frozen where it stopped. The units, the heal script and an installer that runs from the booted OS or the recovery USB are all in the repo: github.com/ryanlipton/steam-machine-nvme-fix.

The last problem was heat

Capping the drive fixed the brownouts and left one number I did not like. This drive warns at 87°C, and bare in the chassis under sustained Steam load it settled at 85°C, two degrees short of that line. The brownout had never been a heat problem, so this was a second fault rather than a symptom of the first, and it deserved its own fix rather than a shrug.

There is very little vertical room above the M.2 board, which rules out most of the aftermarket. A thin copper heatsink fits: 4mm of finned copper and a thermal pad, low enough that the fan panel closes over it, at a price that rounds to nothing against the drive it protects.

It is worth about twenty degrees. Under sustained load the drive now peaks at 62°C and plateaus there, the fins reaching equilibrium with the case airflow and simply holding. That is the difference between a drive living two degrees from its warning threshold and one that never goes near it.

It is the cheapest part of this entire upgrade, and the only part of it Valve’s design left obvious room for.

Advice for your own Steam Machine SSD upgrade

• Check the drive’s power rating before buying. The Steam Machine publishes no M.2 power budget; my testing puts the sustained ceiling in the six-to-eight-watt band. Most Gen4 drives sit under it. Flagship Gen5 drives in the 8 to 12 watt class do not. A Gen4 2280 remains the zero-effort answer.
• Read the drive’s unsafe-shutdown counter before and after a stress test. Kernel logs describe symptoms; that counter records events. It is the single most honest diagnostic in this article, and the command is in the repo README.
• Clone with Etcher, and find the drive’s stable power state before trusting it with a library. The method is in the repo README.
• Fit a thin heatsink. A 4mm copper one closes under the fan panel and took my drive from 85°C to a sustained peak of 62°C. It costs a few pounds and buys about twenty degrees.
• Learn the signature. A drive that is healthy in another machine, fine at idle and under reads, and vanishing under sustained writes with CSTS=0xffffffff is describing a power-delivery mismatch. No kernel parameter fixes it.

The wider point

A 512GB console is now a 2TB one, running a drive I already owned, behind a fix that maintains itself and a few pounds of copper. Getting there took a crash counter and a power-state bisection, and it should have taken a line in a spec sheet. The Steam Machine’s openness is genuine in the hardware: the feet unscrew, the panel lifts away, and the slot takes a standard drive. What is missing is the part of openness that lives on paper. A published power figure for that slot would have reduced this entire investigation to a compatibility check, and a drive firmware willing to remember one setting would have reduced the repo to a single command run once. I sent the full evidence to Valve and to Sabrent on 16 July 2026, and I will update this article with whatever either of them says. Until then the number stands as measured: above six watts and below eight, sustained. A platform that invites the upgrade owns the specification that makes the upgrade safe. That specification is the one thing this machine still keeps to itself.

Useful Links

• Steam-machine-nvme-fix on GitHub
• Steam Machine official page
• Sabrent Rocket 5 2TB on Amazon
• M.2 2280 copper heatsink kit on Amazon

Updates

• 18 July 2026: Sabrent replied. They confirm the drive is operating as designed and that the throttling stems from the Steam Machine’s lower M.2 power budget, not the SSD. They also confirmed there is no firmware that makes the Power Management setting survive a controller reset, and no update planned. So the fix in this article stays the fix: cap the drive’s power state yourself. Valve has not yet responded.

Hardware: Valve Steam Machine (2026), BIOS F7F0105. Drive: Sabrent Rocket 5 2TB (SB-RKT5-2TB), Phison PS5026-E26-52, firmware RT5B58.1. OS: SteamOS 3.8.14 (build 20260703.1). Original drive: Kingston OM3SGP4512K2-A00 512GB.