Wiping drives
This page covers the erasure workflow end to end: configuring a wipe on the Drives screen, how the engine chooses an erasure technique for each drive, the licence check-in that gates every wipe, and what you see while the wipe runs.
Erasure is irreversible. The engine puts multiple safety gates between you and a wipe — eligible-drives-only selection, a two-step confirmation, a server check-in, and a pre-write identity re-check — but once writing starts there is no undo.
The Drives screen
Select Erase in the sidebar to open the Drives screen (the header band reads Drives). A danger banner sits at the top:
⚠ Selected devices will be irreversibly erased. There is no undo.
Below it, every eligible drive gets its own row with a checkbox on the subtitle row, showing:
- Model — the drive's model string.
- Size — capacity in binary units.
- Method — a combo box with exactly two choices:
NIST 800-88 R2 ClearandNIST 800-88 R2 Purge. Purge is the default.
When the method is Purge, the row also shows a PSID (Opal only) field with the hint 32-char code on drive label, if locked. Fill it in only for a TCG Opal self-encrypting drive that is locked — the PSID is printed on the drive's physical label and cannot be read from software.
If you switch a solid-state drive to Clear, the row shows this warning:
Solid-state media: Clear cannot reach over-provisioned cells (NIST 800-88 recommends Purge). Result will be held for review, not certified.
That is not a bluff — a verified Clear on flash media is capped at review and never certified. See Verification & results for the exact outcome mapping.
Excluded drives
Drives that are not safe to wipe are listed separately with their Model, Size, and Wipe target excluded plus the reason. The engine excludes (verbatim reasons):
| Reason | When |
|---|---|
hosts the running OS / boot or live boot medium | The drive is mounted at /, /boot*, /media*, /run/media/*, /.modloop, or /live* |
removable device | The kernel flags it removable (RM=1) |
removable transport (usb|mmc) | Attached over USB or MMC — this protects the boot USB stick itself |
network/SAN transport (iscsi|fc|fcoe) | Network-attached storage |
Excluded drives can never be selected. A secondary internal data drive that merely has a filesystem mounted somewhere else remains a valid target.
Starting the wipe
The commit button is red and reads ⌫ ERASE {n} device(s). It is disabled with No devices selected. until at least one drive is checked. Clicking it opens the Confirm erase popup:
⚠ Are you sure? This will irreversibly erase {n} device(s). There is no undo.
with two buttons: Yes, erase and No, cancel. Only Yes, erase proceeds — and even then, the wipe still has to pass the check-in gate and a per-drive identity re-check before a single byte is written.
Methods vs. techniques
You pick a method; the engine picks a technique. The two methods map directly to NIST SP 800-88:
| Method | Wire id | What it means |
|---|---|---|
NIST 800-88 R2 Clear | nist_800_88_r2_clear | A single logical overwrite of all user-addressable blocks. Protects against non-invasive recovery; appropriate for media staying inside your organization's control. |
NIST 800-88 R2 Purge | nist_800_88_r2_purge | Firmware sanitize / cryptographic erase that reaches over-provisioned and remapped areas. Required for media leaving organizational control — the ITAD case. This is the default; an ITAD operator opts down to Clear deliberately. |
Destroy is an outcome, not a method. If you ask for Purge and the drive cannot satisfy it, the job fails and the drive is routed to physical destruction — the engine never silently downgrades a Purge to a Clear-grade erase.
The 14 techniques
The engine probes each drive non-destructively and auto-selects from these techniques. The operator never picks one directly.
| Label | Wire id | Satisfies | Verified by |
|---|---|---|---|
| Single-pass zero overwrite | zero_overwrite | Clear | Zeros (1 pass) |
| NVMe Sanitize — crypto erase | nvme_sanitize_crypto | Purge | Changed |
| NVMe Sanitize — block erase | nvme_sanitize_block | Purge | Changed |
| NVMe Format — crypto erase | nvme_format_crypto | Purge | Changed |
| NVMe Format — user-data erase | nvme_format_user | Purge | Changed |
| ATA Sanitize — crypto scramble | ata_sanitize_crypto | Purge | Changed |
| ATA Sanitize — block erase | ata_sanitize_block | Purge | Changed |
| ATA Sanitize — overwrite | ata_sanitize_overwrite | Purge | Zeros (1) |
| ATA Security Erase (Enhanced) | ata_security_erase_enhanced | Purge | Changed |
| ATA Security Erase | ata_security_erase | Clear-grade, deliberately unreachable | Zeros |
| SCSI Sanitize — crypto erase | scsi_sanitize_crypto | Purge | Changed |
| SCSI Sanitize — block erase | scsi_sanitize_block | Purge | Changed |
| SCSI Sanitize — overwrite | scsi_sanitize_overwrite | Purge | Zeros (1) |
| TCG Opal PSID Revert | tcg_psid_revert | Purge | Changed |
"Verified by" is the post-wipe expectation: Zeros techniques must read back all zeros; Changed techniques (crypto/block/format/revert) must show the pre-wipe fingerprint markers gone. See Verification & results.
What each family actually does
Single-pass zero overwrite (the Clear workhorse). The engine opens the device exclusively (O_EXCL) and works through three tiers, fastest first:
BLKDISCARD— but only when the drive guarantees deallocated blocks read back as zero (SCSILBPRZ=1, or NVMeDLFEAT & 7 == 1). Otherwise a discard could leave data recoverable.BLKZEROOUT— controller-offloaded zeroing (WRITE SAME / write-zeroes).- Host-side sequential 4 MiB zero writes,
fsync'd.
Work proceeds in 1 GiB chunks with live progress.
NVMe sanitize and format. Sanitize issues nvme sanitize --sanact=4 (crypto erase) or --sanact=2 (block erase) — a controller-wide operation — then polls the sanitize log every second for progress (SPROG). Three consecutive failed log reads fail the technique closed; a 24-hour cap bounds runaway operations. Format uses nvme format --ses=1 (user-data erase) or --ses=2 (crypto erase) with --force. Format only counts as Purge when the erase provably covers all namespaces (single-namespace controller, or the FNA capability bit says the format is global). Every firmware erase is followed by a 10-second settle before verification.
ATA sanitize and security erase (via hdparm). Two protections run first:
- Frozen-drive handling. If the drive reports security-frozen, the technique fails with
drive security is frozen — the boot-time unfreeze (suspend/resume) must run first. In practice you should never see this on a booted ISO: the boot sequence detects frozen disks and performs an automatic suspend/resume (rtcwake) to unfreeze them. - HPA/DCO restore. Before every ATA technique (and before an ATA Clear), the engine restores any Host Protected Area / Device Configuration Overlay (
--dco-restore, then-Nto the native size, then a kernel rescan) so hidden areas are exposed to the erase. If a hidden area survives the restore, the technique FAILS — the engine will not erase around a hidden region and call the drive sanitized.
Security Erase sets a throwaway password, runs --security-erase-enhanced (or plain --security-erase), and disables the password again if the erase fails. Note the deliberate asymmetry: Enhanced Security Erase qualifies as Purge; normal Security Erase is only Clear-grade under NIST 800-88 / IEEE 2883, so the engine never selects it — a drive whose only firmware erase is normal Security Erase has no Purge path and a Purge job on it routes to Destroy. ATA Sanitize variants (--sanitize-block-erase, --sanitize-crypto-scramble, --sanitize-overwrite with pattern 0x00000000) poll every second under the same 24-hour cap.
SCSI sanitize. sg_sanitize --crypto, --block, or --overwrite --zero --count=1, run with --wait.
TCG Opal PSID Revert. sedutil-cli --yesIreallywanttoERASEallmydatausingthePSID <psid> performs a cryptographic erase and reverts the drive to factory state. The PSID is the 32-character code printed on the drive's label — it cannot be read from software, which is exactly why it works as an ownership proof. Verbatim errors you may see: PSID required — enter the 32-character code printed on the drive label and PSID authentication failure — check the PSID on the drive label.
sedutil-cli is not in the Alpine package repositories and is not shipped
in the standard ISO, so Opal PSID Revert fails its preflight tool check
unless a custom build supplies the binary. On stock media, Purge on an Opal
drive relies on the drive's NVMe/ATA/SCSI sanitize paths instead.
All erase tools are invoked as argument arrays (never shell strings), and their live output is captured into a 200-line ring buffer shown on the progress screen.
How the engine selects a technique
The capability probe is non-destructive: nvme id-ctrl (JSON) for NVMe, hdparm -I for ATA, sg_opcodes for SCSI, and sedutil-cli --query when a PSID has been entered (which adds Opal to the candidate set).
- Clear always resolves to the single-pass zero overwrite.
- Purge builds a candidate chain ordered by preference: crypto erase → block erase → overwrite/format → Opal PSID revert. Capability gating is per-standard — e.g. NVMe SANICAP bit 0 enables sanitize-crypto and bit 1 sanitize-block; ATA advertises CRYPTO SCRAMBLE EXT / BLOCK ERASE EXT / OVERWRITE EXT; Enhanced Security Erase only when the identify data affirms enhanced-erase support.
- The whole chain is tried best-first: a technique that fails preflight is skipped, a technique that errors moves on to the next. Only when every candidate has failed does the job fail.
- No Purge technique available → the job fails and the drive's disposition is Destroy. Never a silent downgrade.
You can inspect the selection without touching a drive: erase --probe [/dev/X] prints each drive's Clear and Purge technique plus the full fallback chain, then exits. A drive with no Purge path prints Purge → NOT SUPPORTED → job FAILS and routes to physical DESTROY.
Preflight and identity checks
Before any technique runs, the engine verifies its tools exist and meet version minimums (nvme ≥ 1.0.0, hdparm ≥ 9.0.0, sg_sanitize ≥ 1.0.0, sedutil-cli ≥ 1.0.0), per R2v3.1 Appendix B. The recorded versions become the result's tool_components string (e.g. averase-engine 1.0.0; nvme version 2.4; …). Verbatim failures: required tool `X` not found or not runnable and `X` version … below the supported minimum ….
Immediately before writing, the engine re-enumerates the device path and compares size, then WWN, then serial against what you selected. Any mismatch aborts before a single write: device identity changed for {path} — … refusing to wipe (possible hot-swap or re-probe), or {path} is no longer present at wipe time — refusing to wipe.
The pre-wipe check-in gate
Every wipe run is gated by a licence check-in (POST /api/checkin to the engine Worker, which defers to the AVERASE cloud for the allow/deny, the quota increment, and a job_id). The gate fails closed: a denial, an unprovisioned stick, or any network failure blocks the wipe. If the check-in cannot succeed, a modal titled Wipe blocked appears with one of:
Device not provisioned: no backend token configured. Wipe blocked.Wipe denied: {reason}.Check-in allowed but returned no job id. Wipe blocked.Check-in failed — offline or unreachable. Wipe blocked. ({e})
The engine performs one check-in per run — one job_id covers all drives selected in that run, and each drive's result carries a suffixed id ({job_id}-0, {job_id}-1, …) so the cloud keeps one wipe result and one certificate per drive. Booting and verifying never consume quota; only check-in does. See license tokens for how quota, revocation, and suspension work.
There is no offline mode. A stick that cannot reach the licence server is inert by design — this is what makes remote revocation and quota enforcement trustworthy.
The wipe progress screen
Once check-in succeeds, the engine switches to the Wipe progress screen (band title Wipe progress) and locks navigation: the sidebar is disabled and the header band shows ● wipe in progress — navigation locked in amber.
Each job renders three columns:
- Method — the chosen method plus a note naming the auto-selected technique.
- Progress — a bar with a percentage, or
working…with a spinner for firmware operations that report no granular progress. - Status — while running, a
⊗ Cancelbutton (thencancelling…); a live message; and on completion a status word colored green (completed), red (failed), or muted (cancelled).
Live messages you will see include (verbatim):
Starting {method} on {path}Restoring any hidden HPA/DCO areas…Fast clear (unmap|zero|host zero) — {n}%NVMe Sanitize (crypto|block) — starting…/NVMe Sanitize — {n}%NVMe Format (crypto|user-data erase) — running…ATA Sanitize … — starting…/— {n}%ATA Security Erase (Enhanced) — running…SCSI Sanitize (…) — running…TCG Opal PSID Revert — running…Firmware erase finished — settling…Verifying (read-back)…/— {n}%Cancelling…
Cancelling a wipe
Clicking ⊗ Cancel opens the Confirm cancel popup:
⚠ Cancel the wipe on {path}? The drive will be left PARTIALLY erased and is not safe to reuse until re-wiped.
with Yes, cancel wipe and No, keep erasing. A cancelled job ends with Cancelled by operator — drive left partially erased — the drive is neither sanitized nor certifiable until it is wiped again.
Finishing
The footer reads Wiping… navigation is locked until all jobs finish. while any job is active, then All jobs finished. with a View summary button. Each job ends on one of the terminal messages documented in Verification & results, which also covers the Summary screen, the outcome model, and the wipe result sent to the cloud.