Installing SteamOS on a desktop PC from the Steam Deck recovery image, the very first step of the installer dies:
(A)(USB SanDisk 3.2Gen1)(root@steamdeck deck)# /home/deck/tools/repair_device.sh all
Warning!
This action irrevocably clears *all* user data from /dev/nvme0n1
Pausing five seconds in case you didn't mean to do this...
Ok, let's go. Sanitizing /dev/nvme0n1:
NVMe status: Access Denied: Access to the namespace and/or LBA range is denied due to lack of access rights(0x4286)
(1)(A)(USB SanDisk 3.2Gen1)(root@steamdeck deck)# id
uid=0(root) gid=0(root) groups=0(root)
You are already uid=0. Adding more privilege will not help.
0x4286 is not a Linux permission error. It is a status code returned by the
SSD controller itself, in reply to the NVMe Sanitize command that
repair_device.sh issues as its first action:
nvme sanitize -a 2 "${DISK}"The drive is refusing the command. There are two distinct reasons a drive does that, and they need different responses:
-
The drive does not implement Sanitize at all. This is the common case, and it affects a lot of retail and OEM NVMe drives (the WD Blue SN550 is the one in the upstream bug report). The installer never checks whether the command is supported before issuing it.
-
The namespace is locked or write-protected. TCG OPAL / BitLocker eDrive hardware encryption from a previous Windows install, a vendor namespace write-protect bit, or a self-encrypting drive that was never unlocked. Here the drive has Sanitize, but will not let you touch the media.
The controller capability field SANICAP tells you which one you have:
nvme id-ctrl /dev/nvme0 | grep -i sanicapAll-zero means case 1. Non-zero means case 2.
Sanitize is a secure-erase operation. It exists so that old data is
cryptographically unrecoverable, which matters when you are disposing of a
drive. It is not what makes the install work: repair_device.sh repartitions
and reformats the disk immediately afterwards regardless.
So for a fresh install on a drive you are keeping, sanitize can be replaced with a plain wipe that destroys the things the installer actually cares about:
wipefs -aremoves filesystem, RAID and partition-table signatures- zeroing the first 100 MiB kills the protective MBR and the primary GPT
- zeroing the last 100 MiB kills the backup GPT, which is what causes "the partition table was restored" surprises if you skip it
That is what steamos-sanitize-fix.sh does.
If SANICAP is non-zero, or if the plain wipe also fails with I/O errors, the
drive is locked and no wipe of any kind will succeed. You have to clear the lock
before installing anything:
- PSID revert using the PSID printed on the drive's physical label
(
sedutil-cli --yesIreallywanttoERASEALLmydatausingthePSID <PSID> /dev/nvme0n1). This erases the drive and resets it to factory state. - or clear the hardware-encryption / "secure erase" state from your BIOS setup, if the board exposes it.
Then re-run.
chmod +x steamos-sanitize-fix.sh
./steamos-sanitize-fix.sh diagnose # read-only. Do this first.
./steamos-sanitize-fix.sh patch # write the patched installer only
./steamos-sanitize-fix.sh run # patch, wipe, run the installerThe target device defaults to /dev/nvme0n1; pass another as an argument.
Everything must run as root, from the recovery image's terminal.
diagnose changes nothing. It reports SANICAP, the sanitize log, namespace
write-protect flags, and the SED lock state, so you know which of the two cases
above you are in before you erase anything.
run irreversibly destroys everything on the target device. It asks you to
type ERASE to confirm, unless you pass --yes.
Options:
| Flag | Effect |
|---|---|
--yes |
skip the interactive confirmation |
--try-format |
attempt nvme format -n 1 -s 1 -r before falling back to the plain wipe. Off by default: on some drives format hangs or runs for many minutes, and the install does not need it |
--script PATH |
path to repair_device.sh (auto-detected, default /home/deck/tools/repair_device.sh) |
The script does not edit sanitize_all() in place, and it does not touch
the original file at all. It writes a patched copy to
/tmp/repair_device_fixed.sh with a second definition of sanitize_all()
appended immediately after the original one closes.
In bash, a later function definition replaces an earlier one. So the patcher
only has to find where the original body ends, never to parse or rewrite it.
That is considerably harder to get wrong than a sed expression editing braces,
and it survives cosmetic changes to the original function.
Two checks run before the patched script is allowed near a disk:
- the injected marker must be present in the output, so a patch that silently failed to apply cannot fall through to the original sanitize
bash -nmust pass on the result
There is also a guard that refuses to target the disk holding the running root filesystem or the live installer medium, since pointing this at your USB stick mid-install would be unrecoverable.
The patcher was tested against a mock repair_device.sh carrying the real
sanitize_all() function (same DISK variable, same brace style), with the
disk tools stubbed out. Verified: the override lands after the original, the
original is left intact, the override is what executes at runtime, the tail
offset computes correctly, and the installer proceeds past the sanitize step.
Not verified: a real install on real hardware. If the repair_device.sh on your
recovery image differs enough that sanitize_all() cannot be found, the script
aborts with a clear message rather than producing a broken installer.
- ValveSoftware/SteamOS issue #2515 - SteamOS installation and boot issues on WD Blue SN550 (NVMe Sanitize unsupported)
- axelx86/steamos_installer_fix - the same workaround, as a manual edit
- linux-nvme/nvme-cli issue #412 - 4286 on
nvme format - libnvme
nvme_status_field- status code reference