Parted Magic Secure Erase

ATA, NVMe, SCSI, and eMMC/SD Drive Secure Erase Utility

Parted Magic Secure Erase is a hardware-driven secure erase and data sanitization utility that irreversibly destroys all data on ATA, NVMe, SAS/SCSI, and eMMC/SD storage. As a result, IT asset disposal shops, data-center operators, and security teams can retire drives with full NIST SP 800-88r2 Purge-level assurance and a signed PDF certificate for every drive. In addition, the included PM Report Server streams live status and evidence off the machine while the erase runs, and you can export every session as a cryptographically signed evidence pack that anyone can verify offline — see Network Reporting and Signed Evidence Packs below. To get started, download Parted Magic and boot from a USB stick.

Independently examined. A senior digital forensics expert at a European national laboratory has tested Parted Magic’s Secure Erase over years of use, examining erased media with X-Ways Forensics — the forensic community’s standard for hexadecimal analysis — and at the hardware level with an Atola Insight DiskSense 2 imager, which reads below the user-addressable area, including service tracks and the firmware registry. He confirmed the validity of the erasure. The instruments are named so that anyone equipped to do so can reproduce the verification.

Secure Erase Overview

The Erase utility permanently destroys all data on ATA (SATA), NVMe, SCSI (SAS), and eMMC/SD drives using the drive’s built-in hardware erase command. In contrast to software-based wiping tools, hardware erase instructs the drive’s own controller to wipe every storage cell — including remapped sectors and areas the operating system cannot see — so recovery becomes impossible even with forensic equipment.

Sanitization levels follow NIST SP 800-88r2 (September 2025). In addition, technology-specific sanitization techniques conform to IEEE 2883.

Supported Secure Erase Paths

The utility supports eight erase paths, and it selects one automatically based on each drive’s capabilities:

Erase Path	Description
ATA Sanitize	Drives supporting `hdparm --sanitize-block-erase` — most modern SATA SSDs and HDDs. Therefore, it is the preferred method. Block Erase is the default; in addition, Overwrite and Crypto Scramble are selectable per drive where advertised (see Per-Drive Sanitize Method Selection).
ATA Secure Erase	Fallback for drives without Sanitize support. Specifically, it uses `hdparm --security-erase` (standard) or `--security-erase-enhanced` (Enhanced Secure Erase) where supported.
NVMe Sanitize	NVMe drives with Sanitize capability (sanicap bit 1). It uses `nvme sanitize --sanact=2` (Block Erase) by default; moreover, Overwrite and Crypto Erase are selectable per drive where advertised.
NVMe Format	Fallback for NVMe drives without Sanitize support. It uses `nvme format --ses=1` (User Data Erase) by default; however, Crypto Erase (`--ses=2`) is an opt-in with automatic fallback to `--ses=1` if the firmware rejects it.
SCSI Sanitize	SAS/SCSI drives supporting the SCSI Sanitize command. Likewise, it uses `sg_sanitize --block` (Block Erase) by default; Overwrite and Crypto Erase are selectable per drive where advertised.
SCSI Format	Fallback for SAS/SCSI drives without Sanitize support. Instead, it uses `sg_format --format` (Format Unit).
eMMC / SD Erase	eMMC and SD cards detected as `/dev/mmcblkN`. In this case, the utility uses `mmc erase` for hardware secure erase. If a card does not support hardware erase, then the utility falls back to Block Wipe automatically.
Block Wipe	Software fallback for drives with no hardware erase command — including USB flash drives, legacy drives, and SD cards without erase support. It uses `dd`, and therefore it meets NIST SP 800-88r2 Clear (standard write interface). However, note that this method may take many hours on large drives.

Hidden Area Coverage (HPA / DCO)

ATA drives can reserve sectors that the operating system cannot see using two mechanisms: Host Protected Area (HPA) and Device Configuration Overlay (DCO). As a result, these hidden areas may still contain data that persists through a normal format or partition delete.

Fortunately, the ATA Sanitize and ATA Secure Erase commands — both defined in the ACS specification — operate on the entire media at the firmware level, which includes HPA, DCO, remapped sectors, and overprovisioned flash. Therefore, the utility requires no userspace reset; the drive controller handles full-media coverage internally.

However, Block Wipe writes through the standard block device (/dev/sdX) and can only reach sectors the operating system can see. Consequently, when a drive has HPA or DCO configured, those hidden sectors remain untouched. For this reason, NIST SP 800-88r2 classifies Block Wipe as Clear rather than Purge.

If you still need to handle HPA manually, Parted Magic ships hdparm, which can detect and reset HPA from the command line:

# Check for HPA (compare "native max" vs "accessible" sectors):
hdparm -N /dev/sdX

# Reset HPA to expose all sectors (replace MAX with the native max value):
hdparm -N pMAX /dev/sdX

For most users, however, ATA Sanitize or ATA Secure Erase is the recommended approach — the drive firmware covers HPA and DCO automatically, so no manual steps are required.

⚠ Warning — Data Loss

THIS OPERATION IS PERMANENT AND CANNOT BE UNDONE.

In other words, once the erase process has started, nothing can stop or reverse it. The utility will completely and unrecoverably destroy all data on the selected drives. Therefore, make sure you have selected the correct drives before confirming.

Moreover, do not power off, reboot, or put the computer to sleep while an erase operation is in progress.

Step 1 — Secure Erase Drive Selection

First, the utility detects drives automatically at launch and groups them by erase type. However, by default, the utility selects no drives — you must explicitly check each drive you want to erase. In TUI mode, for example, press a to select all eligible drives, or alternatively use --select on the command line to pre-select specific drives.

Secure Erase Drive Groups

Group	Contents
ATA Drives	ATA Sanitize drives and ATA Secure Erase drives. In addition, FROZEN drives appear here but remain unselectable until you unfreeze them (see Sleep below).
NVMe Drives	NVMe Sanitize and NVMe Format drives.
eMMC / SD Drives	eMMC and SD cards (`/dev/mmcblkN`) that support hardware secure erase via the `mmc` tool. If a card lacks hardware erase support, it appears in Block Wipe instead.
Block Wipe	Hidden by default. To reveal drives with no hardware erase support, click “Show Block Wipe” in the Options bar. However, this section only appears when the utility detects such drives. Afterward, click “Hide Block Wipe” to collapse it again.

Each drive card shows the device path, model name, capacity, and erase-method badge. For more detail, hover over any card to see the full serial number, NIST level, and exact erase command the utility will use.

Secure Erase Badge Colors

Badge	Color	Meaning
ATA SANITIZE	Blue	ATA Sanitize Block Erase
SECURE ERASE	Green	ATA Security Erase
ENHANCED SECURE ERASE	Green	ATA Enhanced Security Erase
NVME SANITIZE	Purple	NVMe Sanitize Block Erase
NVME FORMAT	Orange	NVMe Format (fallback)
MMC ERASE	Cyan	eMMC/SD hardware secure erase
SCSI SANITIZE	Green	SAS/SCSI Sanitize Block Erase
SCSI FORMAT	Light Green	SAS/SCSI Format Unit fallback
PSID REVERT	Magenta	Locked SED — PSID revert
BLOCK WIPE	Violet	Software wipe (dd)
BOOT DRIVE	Red	System drive, cannot be erased
MOUNTED	Yellow	Drive has mounted partitions
FROZEN	Red	Drive is frozen; must unfreeze
HDD / SSD	Grey	Drive media type

Per-Drive Sanitize Method Selection

Drives in the Sanitize classes can advertise more than one sanitize sub-command. When a drive does, its card then shows a method dropdown so you can choose per drive; in TUI mode, highlight the drive and press m. The defaults preserve long-standing behavior — the utility prefers Block Erase everywhere, and cryptographic methods run only when you explicitly select them on a drive that advertises them:

Drive Class	Selectable Methods	Default
ATA Sanitize	Block Erase, Overwrite (1-pass zeros), Crypto Scramble	Block Erase
NVMe Sanitize	Block Erase, Overwrite, Crypto Erase	Block Erase
SCSI Sanitize	Block Erase, Overwrite, Crypto Erase	Block Erase
NVMe Format	User Data Erase (`-s 1`), Crypto Erase (`-s 2`, opt-in)	User Data Erase. However, a rejected `-s 2` falls back to `-s 1` automatically.
ATA Secure Erase	Enhanced, Standard (per-drive combo where both are supported)	Enhanced where the drive supports it

As a result, the chosen method appears on the drive card, in the logs, and on the certificate. In addition, post-erase verification adapts automatically: cryptographic methods leave indeterminate ciphertext, so the verifier switches those drives to a readability check instead of a zeros check. Similarly, on the command line, --sanitize-method and --se-method apply a choice to all eligible drives at once (see Secure Erase Command-Line Options).

Block Wipe Methods

In normal mode, Block Wipe cards include a method dropdown so you can select how the utility wipes the drive. However, NIST Purge mode locks the method to 3-pass dd (zeros/random/zeros), so the dropdown does not appear.

Method	Passes	Description
Zero Fill	1	All zeros (fast, default)
Random Fill	1	Pseudorandom data
RCMP TSSIT OPS-II	8	Alternating passes — RCMP standard
DoD Short (3-pass)	3	Zeros, random, zeros
DoD 5220.22-M	7	DoD 5220.22-M standard
Gutmann	35	Gutmann method (very slow)
PRNG Stream	1	Isaac PRNG stream

Note: Notably, NIST SP 800-88r2 §3.1.1 confirms that a single-pass overwrite suffices for Clear. Multi-pass schemes such as DoD 5220.22-M and Gutmann provide no additional assurance on modern media — in fact, DoD removed overwriting specs from NISPOM in 2006. Furthermore, Gutmann originally targeted 1990s magnetic media. Consequently, if you select Gutmann for an SSD or eMMC drive, the utility triggers a caution notice because the method offers no security benefit over a single-pass wipe on flash storage.

Asset Tags

Each drive card shows a small “Asset Tag” field below it. Specifically, you enter the IT asset tag, barcode, or inventory number for each individual drive. As a result, the utility prints asset tags in each drive’s record block on its certificate. However, the utility stores them in state for the session only (not persisted across launches).

Secure Erase Options

Option	Description
Verify after erase	Runs the built-in post-erase read-back verifier on all erased drives. Moreover, it is always enabled in NIST Purge mode. See Post-Erase Verification below for details.
Sample	Percentage of each drive to verify (10%–100%). For example, at 100%, the utility reads every sector. Default: 100%.
Show / Hide Block Wipe	Toggles the Block Wipe drive section. However, it only appears in the Options bar when block-wipe drives are present.
Email log to	If you enter an email address, then the utility emails all log files and certificates on completion via `mailx`. It also saves the address to `~/.config/email` and pre-fills it on relaunch.
Report server	If you enter a server address, then live status, logs, and certificates stream to a PM Report Server on the network while the erase runs (see Network Reporting below). In addition, the utility saves the address to `~/.config/report_server` and pre-fills it on relaunch. However, the utility uses whatever is in this field when the erase starts; clearing it turns reporting off. Moreover, in the TUI, the same field is on the Cert Info screen (`c`).

Secure Erase Action Bar — Row 1: Compliance and Workflow

Button	Description
NIST SP 800-88r2 (Purge)	Toggles NIST SP 800-88r2 Purge compliance mode. When active, verification is forced on, block wipe uses fixed 3-pass dd, and all certificates record “Purge” as the standard. In addition, enabling NIST mode automatically disables DoD mode. Finally, it persists via `/tmp/nist_purge_mode`.
DoD 5220.22-M	Toggles DoD 5220.22-M certificate compliance mode. Certificates then record “DoD 5220.22-M” as the sanitization standard. However, this is a certificate annotation only — it does not change which erase commands run. In addition, enabling DoD mode automatically disables NIST mode. Likewise, it persists via `/tmp/dod_mode`.
Certificate Info…	Opens a popover where you enter organization name, location, phone, work order, media destination, data backup status, and chain-of-custody names/titles (technician, validator, witness). Afterward, the utility saves all values to `~/.config/cert_info.json`.
Destroy…	Opens the Physical Destruction workflow (see Physical Destruction Logging below).
Continue	Advances to the Confirmation screen. Also saves all preferences to `~/.config/cert_info.json`.

Action Bar — Row 2: Utility and Notifications

Button	Description
Sleep	Suspends the computer to RAM for ~5 seconds and restarts the app. Use this to unfreeze ATA drives, because most drives unfreeze automatically on power cycle.
Re-detect Drives	Re-runs drive detection without restarting the app. In addition, the utility automatically deselects previously selected drives that are no longer present.
Help	Opens the built-in manual.
[Light] / [Dark]	Toggles between dark and light theme.
Sound	Plays a completion chime when all drives finish erasing.
Summary Popup	Shows a pass/fail summary dialog on completion.
Test	Previews the success chime.
Quit	Saves all preferences and exits the application.

Step 2 — Secure Erase Confirmation

This screen lists every drive scheduled for erase along with its serial number, capacity, erase method, and compliance level. Therefore, review the list carefully before proceeding.

SMART Health Gate

As soon as the confirmation screen opens, a SMART health check runs in the background on all selected drives (smartctl -H and -A). Specifically, the check covers two independent conditions:

Health Failures

However, if any drive reports SMART FAILED, a red danger box lists the affected drives. In addition, a second override checkbox appears: “I understand these drives are failing — proceed anyway and attempt erase.” As a result, the Start Erase button remains locked until you check both the consent checkbox and the SMART override checkbox.

Drive Temperature

Specifically, the utility reads temperature from SMART attribute 190/194 (ATA/SCSI) or the NVMe Temperature field:

Threshold	Severity	Behavior
≥ 50 °C	Amber advisory	Shown but does not block erase. Nevertheless, improving airflow is recommended.
≥ 60 °C	Red danger — CRITICAL	You must check a second override checkbox before Start Erase becomes active, because erasing at extreme temperatures risks firmware damage and incomplete data destruction.

In addition, the utility records the temperature at time of erase in the log (TEMP: field) and prints it on each drive’s certificate.

Before Start Erase becomes active, you must check the consent checkbox: “I understand that all data on the selected drives will be permanently and irreversibly destroyed.”

Finally, the confirmation screen has three buttons: Back (returns to drive selection without erasing), Quit (exits the application), and Start Erase (begins the erase operation on all selected drives in parallel).

Step 3 — Secure Erase Progress

As soon as the erase starts, a per-drive status card appears for every drive the utility is erasing. Notably, all drives erase in parallel regardless of erase type — ATA, NVMe, SCSI, eMMC, and Block Wipe drives all start simultaneously. In addition, the progress bar and status message update in real time.

Status	Meaning
Spinning / Erasing…	Drive erase is in progress
✓ Done	Drive erased successfully
✗ Failed	Erase command returned an error

Throughout the wipe, block wipe cards show live progress: current completion percentage, estimated time remaining, and current pass description (for example, “pass 2/3 — random”). Meanwhile, the utility calculates ETA from the current write rate and suppresses it for the first second of each pass while the rate stabilizes.

Additionally, if you configured a Report server, the utility announces the session to it the moment the erase begins — machine identity plus the full drive manifest — then sends a heartbeat every 30 seconds and reports each drive the instant it finishes, pass or fail. See Network Reporting below.

If you enabled verification, then the window switches to the verification phase once all erases complete. See the next section for how that works.

Post-Erase Verification

When Verify after erase is enabled (or NIST Purge mode forces it on), the verifier runs automatically on every erased drive once all erase commands complete. Moreover, verification is built directly into the Erase utility — nothing additional to install or configure.

Secure Erase Verification Modes

The verifier automatically chooses the correct check mode for each drive based on the erase method used. Specifically, it checks drives erased with a cryptographic method — ATA Enhanced Secure Erase, or any Crypto sanitize/format method selected per drive — for sector readability, because the encryption key no longer exists and byte values are indeterminate after erase. In contrast, for all other erase methods, it checks for all-zero bytes.

Check Modes by Secure Erase Method

Erase Method	Check Mode	What It Verifies
ATA Sanitize (Block Erase / Overwrite)	Zeros check	Every sampled sector contains all-zero bytes.
ATA Sanitize (Crypto Scramble)	Readability check	Every sampled sector returns data without I/O error.
ATA Secure Erase (standard)	Zeros check	Every sampled sector contains all-zero bytes.
ATA Enhanced Secure Erase	Readability check	Every sampled sector returns data without I/O error. (Enhanced Secure Erase is a cryptographic erase — the encryption key is destroyed, so post-erase byte values are indeterminate and a zeros check would always fail. Therefore, confirming that all sectors remain readable is the correct verification for crypto-erase, in line with NIST SP 800-88r2.)
NVMe Sanitize (Block Erase / Overwrite)	Zeros check	Every sampled sector contains all-zero bytes.
NVMe Sanitize (Crypto Erase)	Readability check	Every sampled sector returns data without I/O error.
NVMe Format (`-s 1`)	Zeros check	Every sampled sector contains all-zero bytes.
NVMe Format (`-s 2`, Crypto Erase)	Readability check	Every sampled sector returns data without I/O error. Moreover, it keys off the SES value actually executed; as a result, a rejected `-s 2` that fell back to `-s 1` is correctly verified as zeros.
SCSI Sanitize (Block Erase / Overwrite)	Zeros check	Every sampled sector contains all-zero bytes.
SCSI Sanitize (Crypto Erase)	Readability check	Every sampled sector returns data without I/O error.
SCSI Format Unit	Zeros check	Every sampled sector contains all-zero bytes.
eMMC / SD Erase	Zeros check	Every sampled sector contains all-zero bytes.
Block Wipe	Zeros check	Every sampled sector contains all-zero bytes (after the final zero pass).
PSID Revert + re-erase	Inherits the mode of the post-unlock erase method.	—

Sampling

Set the Sample percentage on the drive selection screen to control how much of each drive the verifier reads:

100% (default) — Every sector is read. It is the slowest yet also the most thorough.
50%, 25%, 10% — The verifier reads evenly-distributed sample ranges spanning the full LBA range of the drive; as a result, sampling covers the beginning, middle, and end of the media rather than only the first portion.

For NIST SP 800-88r2 Purge certification, 100% sampling is recommended.

Secure Erase Verification Progress

When verification starts, the window switches to a per-drive progress view. Specifically, each drive card shows its check mode badge (ZEROS CHECK or READABLE CHECK), a live progress bar, and the result once the scan finishes:

Result	Meaning
✓ Pass	Every sampled sector matched the expected check mode.
✗ Mismatch	(Zeros check) The verifier found at least one non-zero byte. Consequently, the drive’s final result on the certificate is set to Erase Failed.
✗ Error	(Readable check) The verifier encountered an I/O error during the read. The drive’s final result on the certificate is therefore set to Erase Failed.

All drives verify in parallel, just like during the erase phase. Moreover, the verifier runs in a background thread per drive and updates the GTK UI without blocking; as a result, large drives at 100% sampling do not freeze the interface.

TUI Verification

The same verifier runs under --tui mode as well, using a curses-based progress display instead of GTK. Likewise, pass/fail results, sampling, and check-mode selection all behave identically.

Step 4 — Secure Erase Results

Afterward, this screen shows the final erase result (Successfully Erased or Erase Failed) for every drive, followed by log file paths and certificate paths.

Secure Erase Log Files

The utility always generates three log files:

Log File	Contents
Advanced Log (`*-Advanced.txt`)	Full erase session log with drive identity data (`hdparm -I` / `nvme id-ctrl` / `mmc extcsd read`), erase results, smartctl output, and an MD5 checksum at the end. In addition, block wipe and eMMC drives include their full tool output.
Basic Log (`*-Basic.txt`)	Summary log with erase results and the MD5 checksum of the Advanced Log.
CSV Log (`*-Basic.csv`)	Spreadsheet-compatible summary with one row per drive: model, serial, capacity, OS, software, finish time, MD5, result, verification, method.

Secure Erase Certificates

The utility generates one PDF certificate per erased drive, named <dev>-Erase-Certificate-<timestamp>.pdf. Specifically, each certificate contains:

Organization name, location, and phone
Host system information (from dmidecode)
Sanitization session timestamps and compliance standard
Drive record: serial, capacity, media type, operational status, sanitization method (Clear/Purge/Destroy), sanitization technique, NIST/DoD level, verification result
Media destination and data backup status
Log file paths and MD5 integrity checksum
Attestation statement referencing the active standard (NIST SP 800-88r2 or DoD 5220.22-M)

Chain-of-Custody Signature Block

The certificate also includes two signature rows:

Row	Fields
Row 1	Technician \| Validator
Row 2	Witness \| Date

If you entered names and titles in Certificate Info, then they pre-print on the signature lines. Otherwise, blank entries leave underscore lines for handwritten signatures. In addition, the witness row supports formal chain-of-custody requirements where a third party observes and countersigns the sanitization.

Secure Erase Save Options

By default, the utility saves all files to /home/partedmagic/. However, to copy files to an external location, expand “Save Options”:

Format	Description
Uncompressed	Copies all files as-is
Gzip (.gz)	Compresses each file with gzip before copying
Zip (.zip)	Wraps each file in a zip archive before copying

Next, use Browse… to select the destination directory, or alternatively click Mount to launch Parted Magic Mount and mount an external drive first. The results screen also provides View Log (opens logs in leafpad), View Certificate (opens PDFs in LibreOffice), and Save & Close (copies selected files to the save directory and exits). If you also need full-disk imaging, see Parted Magic Clonezilla.

Finally, if you entered an email address on the selection screen, the utility automatically emails all logs and certificates on completion. Similarly, if you configured a Report server, all logs and certificates upload to it automatically as well — see Network Reporting below.

Secure Erase Compliance and Standards

Sanitization levels follow NIST SP 800-88r2 (September 2025). In addition, technology-specific sanitization techniques conform to IEEE 2883.

Erase Method	NIST SP 800-88r2 Level
ATA Sanitize (SSD)	Purge
ATA Sanitize (HDD)	Purge
ATA Secure Erase (SSD)	Purge
ATA Secure Erase (HDD)	Purge
ATA Enhanced Secure Erase	Purge (crypto-erase)
NVMe Sanitize	Purge
NVMe Format -s2	Purge (fallback)
eMMC Secure Erase	Purge
SCSI Sanitize (SSD)	Purge
SCSI Sanitize (HDD)	Purge
SCSI Format Unit (SSD)	Purge
SCSI Format Unit (HDD)	Purge
PSID Revert + re-erase	Inherits level of the post-unlock erase method
Block Wipe (any method)	Clear

Under r2, all dedicated device sanitize commands (ATA Sanitize, ATA Secure Erase, NVMe Sanitize/Format, SCSI Sanitize/Format, eMMC Secure Erase) qualify as Purge regardless of media type, because they bypass the standard read/write interface and address all storage areas including overprovisioning and remapped sectors. In contrast, only software block wipe via standard write commands (dd) falls under Clear.

When DoD 5220.22-M mode is active, all certificate fields reference DoD 5220.22-M regardless of erase method used. However, the erase commands themselves do not change — DoD mode affects certificate output only. In addition, certificate fields conform to the NIST SP 800-88r2 Appendix C sample Certificate of Sanitization form.

Network Reporting — PM Report Server

Because Parted Magic runs from RAM, logs and certificates written locally are lost if the machine loses power before you save them. Network Reporting solves this: while the erase runs, the utility streams the evidence off the machine — live — to a PM Report Server on your local network. As a result, even a mid-erase power outage cannot destroy the record of exactly what was in flight.

The Server

The server ships in the root of the Parted Magic ISO — on a USB install, for example, it sits in the root of the flash drive, next to GPL. Moreover, it is a single file with no dependencies. Next, copy pmagic_report_server to any always-on machine on your network that has Python 3 (Linux, Windows, or Mac) and start it:

# Linux / Mac:
./pmagic_report_server

# If the copy lost its execute bit:
python3 pmagic_report_server

# Windows:
py pmagic_report_server

On a Linux desktop, a window opens the moment the server starts. The address to give the Erase utility appears at the top in large type with a Copy button — no more hunting through terminal scrollback — and below it sits a live library of everything the server has ever recorded (see The Server Window below). Meanwhile, on Windows, on a Mac, or on a machine with no display, the server prints the same address in the terminal and runs headless, exactly as before. In other words, the window is a convenience, not a requirement.

Then open http://that-machine:8341 in any browser — including a phone on the shop Wi-Fi — to watch every erase session live. In addition, the server stores everything under ~/pm-reports/, and it writes each event to disk before acknowledging it — as a result, the record survives on the server no matter what happens to the client.

The Server Window

The window puts everything an operator needs in one place. First, the header shows the exact pmreport= line to type into the Erase utility — selectable, and one click to copy — and the server’s public key sits right under it with Copy key and Save key… buttons, ready to hand to anyone who must verify your evidence. Below that, the library lists every drive across every session the server has recorded: date, customer, work order, machine, device, model, drive serial, method, result, and status. The search box filters all of it as you type — by drive serial, model, machine, work order, technician, or date — and clicking any column header sorts by that column. Moreover, live sessions update in place every few seconds without disturbing your scroll position, your sort, or the row you have selected, and a status line counts the drives shown, the sessions on record, and any running right now.

The buttons act on the selected row:

Button	What It Does
Export evidence pack…	Builds the signed evidence pack for the selected session and saves it where you choose. In addition, every file dialog remembers the last folder you used.
Save certificate…	Saves the selected drive’s PDF certificate of destruction.
Verify	Checks the selected session’s evidence — see below for exactly what gets checked.
Open in browser	Opens the selected session’s page in your browser, or the dashboard when nothing is selected.

Verify is file-first. If you exported the selected session’s pack during this run, Verify checks that file on disk — alter a single character inside the zip, click Verify, and it prints TAMPERED and names the altered file. Furthermore, it then tells you where the fault lives: whether the exported file was changed after export, or the session history on the server itself was altered. Only when no exported copy is on hand does it fall back to building a fresh pack and checking that — and the verdict says so plainly, because a self-check is not a check of any file on disk.

You can also drop an evidence pack — or several at once — anywhere on the window to verify files directly. Each verdict names its file, and multiple packs get one summary. Notably, verification is built into the server itself — the same four checks pmagic_verify performs (see Signed Evidence Packs below) — so this works even where the standalone verifier is absent; however, when pmagic_verify sits beside the server, the server runs that instead, because that is the exact tool your customers run. Finally, --no-gui starts the server headless on a desktop machine if you prefer the plain terminal banner.

Configuring the Client

To begin with, enter the server’s address any one of four ways. The GUI field always shows exactly what the utility will use; furthermore, whatever is in it when the erase starts is authoritative, and clearing it turns reporting off. Of course, if you configure no server, reporting stays off and the utility sends nothing.

Method	Description
Selection screen	The “Report server” field — saved to `~/.config/report_server` and pre-filled on relaunch, like the email address. Meanwhile, in the TUI, the same field is on the Cert Info screen (`c`).
Kernel command line	`pmreport=HOST[:PORT]` and optionally `pmreport_token=SECRET` — ideal for PXE fleets, because every netbooted machine reports automatically with zero per-machine setup.
Environment	`PMREPORT` / `PMREPORT_TOKEN`
CLI flag	`--report-server HOST[:PORT]` — overrides the saved field value for that run.

What Gets Sent

Event	When and What
session_start	The moment the erase begins: machine identity (manufacturer, product, serial) plus the full drive manifest — device, model, serial, size, and erase method for every drive — along with the compliance standard and verification setting.
heartbeat	Every 30 seconds while erasing.
drive_done	The instant each drive finishes, pass or fail.
logs_written	Afterward, the utility sends final per-drive results.
files	Finally, all logs, the CSV summary, and every PDF certificate upload on completion. Additionally, Physical Destruction certificates upload too.

The Dashboard

The dashboard is simply the web page the server serves — open http://that-machine:8341 in any browser, and this is what you see; there is nothing to install. First, the dashboard shows one row per machine — session, machine identity, drives done vs. total, and a live status that updates every five seconds. Next, click any row for the per-drive detail view with downloadable files. In addition, /export.csv downloads one spreadsheet row per drive across every session the server has ever recorded.

Status	Meaning
ERASING	Session is live and sending heartbeats.
COMPLETE	Session finished with every drive passing.
FAILURES	Session finished; however, one or more drives failed.
STALLED	No traffic for 90 seconds and no session end — in other words, the power-outage tell. Nevertheless, everything received up to that point is safe on the server: the manifest, every heartbeat, and every drive that had completed.

Phone and Email Alerts

The server can also send an alert the moment something needs attention — a drive fails, a session stalls, or a job finishes. Alerts are optional and off by default; each channel is a single flag when you start the server. The simplest is email:

./pmagic_report_server --alert-email tech@example.com --smtp mailhost

Every alert then lands in the shop inbox — the same inbox phones already buzz for — through your own mail server, with nothing new to install. In addition, two more channels exist for shops that want them; however, none of this is required, and the dashboard works with no alerts configured at all. Like reporting itself, alert delivery runs on a background thread with short timeouts, so it can never slow or block an erase.

Flag	What It Does
`--alert-email ADDR --smtp HOST[:PORT]`	Emails every alert through your own mail server. Repeatable for multiple recipients.
`--alert-webhook URL`	POSTs each alert as JSON — for scripts, ticket systems, or chat integrations.
`--alert-ntfy URL`	Sends push notifications through an ntfy relay (self-hosted or ntfy.sh) to the free ntfy app on any phone, iPhone included.
`--alert-on LIST`	Chooses which alerts fire: any of `drive_failed`, `stalled`, `complete`. Default: all three.

Watch the Bench From Your Phone

On Android, install Parted Magic Erase Monitor from Google Play. It is free and published by Parted Magic LLC, and its Play data-safety entry reads no data collected and no data shared — it talks to your report server on your own network and to nothing else. Give it the same server address you gave the Erase utility, and every session on the bench appears on your phone as it runs, including drives that fail.

On an iPhone, or on Android if you would rather install nothing, the dashboard also pins to the home screen as a web app. Open the dashboard in Safari and choose Share → Add to Home Screen, or in Chrome choose menu → Add to Home screen. A Parted Magic icon then appears on the home screen and opens the dashboard fullscreen, with nothing to install and nothing to update.

Reliability and Security

Above all, reporting can never block, slow, or fail an erase: all sending happens on a background thread with short timeouts. After the erase completes, however, the utility waits briefly for the final uploads to land before showing results — but only while uploads are actually succeeding (at most two minutes; an unreachable server skips the wait). In addition, every stored event carries a SHA-256 hash chain, so records altered on the server after receipt are detectable, and an optional shared token (--token on the server, pmreport_token= on the client) restricts who can submit reports.

Unattended Mode — PXE Auto Nuke

Boot, wipe per policy, report live, power down — a rack that decommissions itself with nobody at a keyboard. Unattended mode is armed by pmerase=auto on the kernel command line and by nothing else, which makes it a natural fit for a PXE netboot setup: one boot entry erases every machine that boots it, identically, while the evidence streams to your PM Report Server as it happens. Afterward, every unattended session exports as a signed evidence pack like any other — see Signed Evidence Packs below.

Example PXE Append Line

append initrd=initrd.img pmerase=auto pmerase_confirm=ERASE-ALL-DATA \
  pmerase_targets=all pmerase_method=zero pmerase_verify=100 \
  pmerase_on_done=poweroff pmreport=10.0.0.5:8341

Kernel Keys and CLI Equivalents

Every kernel key has a CLI mirror for bench testing, and a CLI flag beats the kernel command line. The full rules, refusal reasons, and exit codes are in the built-in manual (Help in the app, or erase --help, section UNATTENDED MODE).

Kernel command line	CLI equivalent	Purpose
`pmerase=auto`	`--auto`	Arms unattended mode — nothing else does
`pmerase_confirm=TOKEN`	`--auto-confirm TOKEN`	Must be exactly `ERASE-ALL-DATA`
`pmerase_targets=all\|sda,sdb`	`--auto-targets all\|sda,sdb`	Explicit target policy — there is no default
`pmerase_exclude=sdc,sdd`	`--auto-exclude sdc,sdd`	Drives to leave alone
`pmerase_verify=off\|10\|25\|50\|100`	`--auto-verify LEVEL`	Post-erase verification (full verify unless told otherwise)
`pmerase_delay=SECONDS`	`--auto-delay SECONDS`	Abort window at the console before the first write
`pmerase_on_done=poweroff\|reboot\|halt\|stay`	`--auto-on-done ACTION`	What happens when the run completes
`pmerase_method=KEY`	`--method KEY`	Block-wipe method — required whenever a target needs one
`pmerase_sanitize=MODE`	`--sanitize-method MODE`	Hardware sanitize sub-method
`pmerase_se=MODE`	`--se-method MODE`	ATA Secure Erase method
`pmerase_nist=1 / pmerase_dod=1`	`--nist / --dod`	Compliance standard on every certificate
`pmerase_work_order=TOKEN`	`--work-order TOKEN`	Work order embedded in every certificate
`pmreport=HOST[:PORT]`	`--report-server HOST[:PORT]`	Required — no server, no run

The Safety Contract

Above all, this feature is designed to be incapable of erasing anything by accident. The run refuses, erases nothing, and leaves the machine powered on with the reason on the console unless all of the following hold:

pmerase=auto, exactly — not a bare pmerase=, not a truthy value.
The confirmation token ERASE-ALL-DATA, verbatim. A DHCP entry someone forgot to retire cannot satisfy this by accident, and the boot config carrying it is itself the record of who intended what.
An explicit target policy — there is no default set of drives.
A report server that passes its health check. Before the first write, the client calls the server’s /api/health endpoint, which must prove that the listener really is a PM Report Server, that this machine’s token (if any) will be accepted, and that the server’s disk can actually store evidence right now. A machine that netboots onto the wrong network finds no server, refuses, and destroys nothing — evidence must exist before destruction does.
An explicit block-wipe method whenever a target needs one — “zero” is a policy decision with compliance consequences, not a default to inherit silently.
An abort window at the console before the first write, cancelled by any keypress.

In addition, and with no override: the running system’s own drive is never a target, PSID-locked drives are never auto-selected, drives with a mounted filesystem are never auto-erased, ATA-frozen drives are never silently attempted, and NIST Purge is refused outright on RAID LUNs and hypervisor virtual disks.

The Evidence Trail

An unattended run leaves a record of everything it did — and everything it deliberately did not do. The session on the report server records the resolved policy, every target, and every skipped drive with its reason; the Advanced Log header carries an Unattended Mode: line naming the arming source and on-completion action, plus an Unattended Skipped: line for anything auto-selection left alone; and the dashboard, CSV export, and signed evidence pack all mark the session as unattended. Even a refusal becomes evidence: a machine that declines to erase checks in with its reasons, so the dashboard shows a machine that refused rather than a machine that never appeared.

Exit codes: 0 all drives erased, 1 a drive failed or the evidence record could not be produced, 2 policy refused, 3 aborted at the console or nothing eligible.

Signed Evidence Packs

You can export every session on the report server as a signed evidence pack — one zip containing everything the server holds for that session, sealed with a cryptographic signature. Consequently, you can hand the pack to a customer with the invoice, and their auditor can verify every drive’s fate on any machine, offline, with no account, no network, and no vendor. Cloud-portal certificates stop working when the vendor relationship ends; a signed pack verifies forever, because the math does not expire.

What Is in a Pack

File	Contents
`files/`	All logs, the CSV summary, and every PDF certificate
`events.jsonl`	The live event record, hash-chained
`session.json`	Session summary: machine, drives, results
`MANIFEST.json`	SHA-256 of every file above
`MANIFEST.sig`	Ed25519 signature over the manifest
`PUBKEY.txt`, `README.txt`	The signer’s public key and verification instructions

The server generates its Ed25519 signing key automatically on first run; afterward, it keeps it in keys/signing.key inside its data directory. Meanwhile, the matching public key prints in the startup banner, appears in the dashboard footer, and the server also serves it at /pubkey — hand it to your customers once, out-of-band.

Back up keys/signing.key and treat the server’s data directory like a credential. Indeed, the key is your organization’s signing identity: anyone who can read it can sign packs as you. Furthermore, if you lose it, previously issued public keys will not match packs from a replacement key.

Verifying a Pack — pmagic_verify

In addition, the pmagic_verify program ships next to pmagic_report_server in the root of the Parted Magic ISO. It is likewise a single file that runs on any machine with Python 3:

./pmagic_verify pack.zip --pubkey <64-hex-char public key>

The verifier performs four checks in order. First, it confirms that the signature over the manifest is valid for the given public key. Next, it recomputes the SHA-256 of every listed file and requires an exact match. Then, it rejects any file in the pack that the manifest does not list. Finally, it re-walks the internal event chain. Afterward, it prints VALID with the machine and per-drive results, or TAMPERED with the specific findings. Exit code 0 means valid, 1 means tampered, and 2 means the pack could not be read at all — a missing or unreadable file, or a usage error. As a result, the check also scripts cleanly; treat only exit 0 as success.

Run without --pubkey and the verifier uses the key embedded in the pack. However, that proves internal consistency only — not who made the pack — and the output says so explicitly. Therefore, for real assurance, always verify against a public key that you obtained from the organization directly.

The report server performs the same four checks itself — select a session in the server window and click Verify, or drop a pack file onto the window. Nevertheless, pmagic_verify remains the tool to hand to customers and auditors, and it is separate on purpose: the party checking the evidence should never have to run the software that produced it.

Check It Yourself

Rather than take any of the above on trust, the files from a real erase are published so that anyone can run the check without buying anything. The session came from a Samsung SSD 980 250GB, serial S64CNJ0R809052L, in a Dell OptiPlex 7010 on 18 August 2026 — NVMe Sanitize Block Erase, verified at 100%, recorded as NIST SP 800-88r2 Purge.

bd059f962cd4.zip — the signed evidence pack
pmagic_verify — the verifier itself
signing.pub — the public key of the server that signed it
The certificate of destruction — also inside the pack, offered separately so it can be read first

Put all four in one directory, disconnect from the network if you like, and run:

./pmagic_verify bd059f962cd4.zip --pubkey-file signing.pub

VALID
  signer public key : 325d6289c6eb61bc03d8341ece708de4c6e73a0ad319f46e8f6a7b9bd3acae31
  session           : bd059f962cd4
  exported          : 2026-08-18T11:30:40-05:00
  files verified    : 8  ·  13 chained events
  machine           : Dell Inc. OptiPlex 7010  (serial F501GX1)
  mode              : attended
    /dev/nvme0n1     Successfully Erased

Then break it on purpose, because a checker that only ever says yes proves nothing. Copy the pack, extract the drive’s Basic log, change Verification Level 100% to Verification Level 10% — precisely the lie a dishonest operator would want to tell — put the file back into the zip, and run the same command again:

TAMPERED
  - hash mismatch (file altered): files/Samsung-SSD-980-250GB_S64CNJ0R809052L-Erase-Log-2026-08-18-1125-Basic.txt

The altered file is named. The same happens with the certificate, the CSV, the event log, or the manifest itself, because the signature covers a hash of every file in the pack.

Physical Destruction Logging

To open the Physical Destruction workflow, click Destroy… on the drive selection screen. However, no erase runs here — this workflow only logs that the drives underwent physical destruction and generates a signed certificate for your records.

When to Use This

Use physical destruction logging when someone will shred, degauss, incinerate, or otherwise destroy the drives rather than erase them. Specifically, NIST SP 800-88r2 classifies physical destruction as the “Destroy” sanitization method (Section 3.1.3), which applies when no one will reuse the media.

Destruction Methods

Shredding — Industrial cross-cut or granular shredder
Degaussing — Electromagnetic field erasure (tape / HDD)
Disintegration — Granulator / disintegrator
Incineration — High-temperature combustion
Crushing / Bending — Hydraulic press or manual bending
Drilling / Punching — Physical perforation of platters/chips
Degaussing + Shredding — Combined (highest assurance for HDDs)
Other — Free-text notes field available

Session Fields

Field	Description
Date of Destruction	Date the destruction was carried out
Contractor / Facility	Name of the destruction facility or vendor
Contractor Ref #	Manifest or job reference from contractor
Authorized By	Name of person authorizing destruction
Witness	Independent witness to the destruction
Work Order	Links the certificate to a broader asset disposal job

Drive Fields (per drive)

Each drive row includes: device node (pre-filled from detected drives, editable), model, serial number, capacity, asset tag (pre-filled from selection screen if set), and notes. Moreover, the utility pre-populates detected drives automatically. In addition, click + Add Drive Manually to add drives that are not currently attached — for example, already-destroyed drives you are documenting retroactively.

Physical Destruction Certificate

The generated PDF uses a distinct deep-red header to distinguish it from sanitization certificates. It includes organization and contractor information, per-drive record with serial number and destruction method, NIST SP 800-88r2 Destroy disposition attestation, authorized-by and witness signature lines, and also a QR code encoding key certificate fields for verification. Afterward, the utility saves the certificate as Physical-Destruction-Certificate-YYYY-MM-DD-HHMM.pdf. In addition, if you configured a Report server, the utility uploads the destruction certificate to it automatically as well.

Dark / Light Theme

To toggle between themes at any time, click [Light] or [Dark] in the action bar of the drive selection screen. The change then takes effect immediately across all open windows without restarting. In addition, the utility saves the selected theme to ~/.config/cert_info.json and restores it automatically on the next launch.

Both themes are fully self-contained — the utility uses no system GTK theme, Adwaita, or external stylesheet. Instead, the app defines every color internally, so the appearance stays consistent regardless of the desktop environment or GTK settings.

Dark (default)

Deep navy/charcoal backgrounds with blue accent (#2a7fff). Optimized for low-light environments and data-center work.

Light

Clean white/light-grey backgrounds with the same blue accent. In contrast, it offers better legibility under bright fluorescent lighting or when capturing screenshots for reports.

Sound and Notification on Secure Erase Completion

Two optional alerts fire automatically when all drives finish erasing. Specifically, you will find the checkboxes in the bottom action bar of the drive selection screen.

Sound on Completion

The utility plays a synthesized two-note chime via ffplay. No audio files are required because the utility generates tones in real time.

Outcome	Sound
Success (all drives passed)	Rising chime — 880 Hz → 1320 Hz
Failure (any drive failed)	Falling tone — 440 Hz → 220 Hz

To preview the success chime before erasing, click Test next to the checkbox. However, if ffplay is not installed, the utility silently skips this option. In addition, sound also plays in --tui mode.

A small non-blocking dialog appears over the results window, listing the pass/fail status of every erased drive. The popup appears about 350 ms after the results window opens; moreover, you can dismiss it independently without closing the main window. Finally, both options default to off and persist across sessions via ~/.config/cert_info.json.

Secure Erase Command-Line Options

Secure Erase Modes

Flag	Description
`(default)`	GUI mode — full GTK3 windowed interface.
`--tui`	Terminal UI (curses) — no X11 or GTK required. Instead, it provides an interactive Select → Confirm → Erase → Results flow entirely in the terminal. Exit code 0 = all drives succeeded; exit code 1 = one or more drives failed.

Drive Selection

Flag	Description
`--select sda,sdb`	Pre-selects the named drives for erase. Names can include or omit the `/dev/` prefix. Afterward, you can still toggle other drives interactively.
`--list`	Prints all detected drives and their erase methods, then exits (no erase performed).
`--check-deps`	Verifies that all required external programs and Python packages are installed, then exits. Prints OK or MISSING for each dependency. Exit code 0 = all required deps present; 1 = one or more missing.

Erase Options

Flag	Description
`--nist`	NIST SP 800-88r2 Purge mode (same as the NIST toggle).
`--dod`	DoD 5220.22-M certificate annotation.
`--verify PCT`	Post-erase verification: 10, 25, 50, or 100 percent.
`--method KEY`	Block wipe method for all block-wipe drives. Keys: `zero`, `random`, `ops2`, `dod_short`, `dod`, `gutmann`, `prng`. Default: `zero`.
`--se-method MODE`	ATA Secure Erase method for all Secure Erase drives: `enhanced` (default where the drive supports it) or `standard`. However, it is ignored for drives that support only one.
`--sanitize-method MODE`	Hardware sanitize sub-method for all Sanitize-class drives (ATA/NVMe/SCSI): `block` (default), `overwrite` (1-pass zeros), or `crypto`. `crypto` also switches NVMe Format drives to `-s 2` where advertised. However, it is applied only where the drive advertises the method; all other drives keep their default.
`--work-order WO`	Work order number embedded in every certificate.
`--log-dir DIR`	Writes logs and certificates to DIR instead of `~/`.
`--report-server HOST[:PORT]`	Streams live status, logs, and certificates to a PM Report Server on the network (default port 8341). In addition, it overrides the saved Report server field value for that run. See Network Reporting.

Certificate Options

Flag	Description
`--org-name NAME`	Organization name for certificates.
`--org-location LOC`	Organization location (city / facility).
`--org-phone PHONE`	Organization phone number.
`--technician NAME`	Technician name for signature block.
`--technician-title T`	Technician title for signature block.
`--email ADDR`	Email address the utility records on the certificate and also uses to send log files via `mailx` on completion.

PSID Unlock

To supply PSID codes for locked SED drives, use --psid-code DEV:CODE[,DEV:CODE…]. You will find the 32-character code printed on the drive label. Then, the utility pre-selects and unlocks drives listed here for erase. However, without --psid-code, PSID-locked drives appear as frozen and remain unselectable.

Secure Erase Examples

# List all detected drives without erasing:
erase --list

# TUI — interactive terminal drive selection and erase:
erase --tui

# TUI — pre-select drives, NIST Purge, verify 100%, log to USB:
erase --tui --nist --verify 100 \
    --select sda,sdb --log-dir /mnt/usb/logs --work-order WO-2024-0042

# TUI — DoD mode, full cert info, email results:
erase --tui --dod \
    --work-order WO-2024-0042 \
    --org-name "Acme Corp" --org-location "New York, NY" \
    --technician "Jane Doe" --technician-title "IT Specialist" \
    --email reports@acme.com --log-dir /mnt/usb/logs

# TUI — NIST Purge with live network reporting:
erase --tui --nist --verify 100 \
    --select sda,sdb --report-server 192.168.1.50

# TUI — block wipe with Gutmann method:
erase --tui --select sda --method gutmann

# TUI — unlock and erase a PSID-locked SED:
erase --tui \
    --psid-code sda:12345678901234567890123456789012

Secure Erase Notes

Above all, the utility always excludes boot/system drives regardless of --select.
The utility never auto-selects PSID-locked drives; instead, use --psid-code to include them.
Finally, CLI options (--org-name, --technician, and so on) override values saved in ~/.config/cert_info.json for the current run only.

Saved Files and Configuration

Path	Purpose
`~/.config/email`	Last-used email address
`~/.config/report_server`	Last-used Report server address (cleared when the field is emptied)
`~/.config/cert_info.json`	Organization and chain-of-custody info, theme, sound/popup preferences, and block wipe method selections
`/tmp/nist_purge_mode`	Presence enables NIST Purge mode
`/tmp/dod_mode`	Presence enables DoD 5220.22-M mode
`/tmp/pmagic_gtk3_erase.lock`	Single-instance lock (PID)

By default, the utility writes log and certificate files to /home/partedmagic/. However, you can override this with --log-dir. Meanwhile, on the server side, the PM Report Server keeps everything under ~/pm-reports/ on the machine where it runs — including its signing key in keys/signing.key.

Recovering a Drive After an Interrupted ATA Secure Erase

ATA Secure Erase is a two-step firmware operation: the utility first sets an ATA security user password on the drive, then issues the erase command, and finally disables security once the erase finishes. The password Parted Magic uses is pmagic. Under normal operation this all happens automatically and the password is removed before the drive leaves the Results screen — you never see it.

If an ATA Secure Erase is interrupted — by power loss, reboot, sleep, a cable disconnect, or an app crash — the drive can be left with the security password still set.

As a result, the drive is now locked. For example, it may show a tiny capacity, refuse to mount, report “security frozen,” or vanish from the OS entirely. Nevertheless, the drive is not dead. The password Parted Magic set is pmagic, and removing it restores the drive to normal use.

However, this only applies to the ATA Secure Erase path. ATA Sanitize, NVMe, SCSI, and eMMC erases do not set a security password; therefore, they cannot leave a drive locked this way.

The Password Is `pmagic`

Before every ATA Secure Erase, the utility runs hdparm --security-set-pass pmagic /dev/sdX to set the drive’s user password, then runs hdparm --security-disable pmagic /dev/sdX after the erase completes to clear it. However, if the process stops between those two steps, the password pmagic remains active on the drive’s firmware. Therefore, knowing this value is the key to recovery — you do not need the manufacturer master password or any special equipment.

Recovery — ATA Security Disable

Parted Magic ships a dedicated tool for exactly this situation: ATA Security Disable (pmagic_ata_security_disable). It unlocks the drive with the supplied password, then fully disables security so the drive returns to normal read/write operation. However, it does not erase any data — it only removes the ATA password.

If the drive shows as frozen, power-cycle the machine first (or use the Sleep button in the Erase app), because security commands cannot run on a frozen drive.
Next, launch ATA Security Disable and select the locked drive.
Then, leave the password field at its pre-filled default of pmagic — this is the password Parted Magic set. Only change it if you know the password was set to something else.
Likewise, leave Use master password unchecked. The user password (pmagic) is the correct one for a Parted Magic erase.
Finally, confirm. The tool then unlocks the drive, disables security, and writes a log recording the exact hdparm commands issued and the drive’s security state before and after.

After Unlocking

Once security is disabled, the drive returns to its full capacity and can be partitioned, re-erased, or used normally. Therefore, if you intended to sanitize the drive, simply run the Erase utility again — an interrupted erase leaves data in an indeterminate state and should never be treated as complete.

Warning — retry counter: Entering the wrong password increments the drive’s internal security counter. In fact, most drives lock permanently after about 5 consecutive wrong attempts and require a full power cycle before further attempts are accepted. Therefore, do not guess passwords repeatedly. For a Parted Magic erase the password is always pmagic — enter it exactly once.

If neither the user password (pmagic) nor the manufacturer master password is known — for example, on a drive locked by some other tool — a PSID Revert may be the only remaining option. However, PSID Revert is destructive: it cryptographically erases the drive. Use the PSID Revert path in the Erase utility (badge PSID REVERT) with the 32-character PSID code printed on the drive label.

ATA Security Disable — Command Line

Command	Description
`pmagic_ata_security_disable`	Launch the GUI.
`pmagic_ata_security_disable --list`	List eligible drives and exit.
`pmagic_ata_security_disable --check-deps`	Verify required programs are installed.
`pmagic_ata_security_disable --manual`	Print the full manual to stdout.

Secure Erase Troubleshooting

If you hit a problem not covered below, also see the Parted Magic support page.

Drive Detection Issues

Problem	Solution
Drive not listed	The drive may be in RAID mode in BIOS/UEFI (change to AHCI), or fully encrypted (use PSID Revert — the drive will then appear in the “Locked Drives” section). In addition, click Re-detect Drives after connecting a drive without rebooting.
Drive shows BOOT DRIVE	The drive contains the running OS; as a result, the utility protects it from selection automatically. Therefore, boot from a different device (for example, a Parted Magic USB) if you need to erase it.
Drive shows MOUNTED	One or more partitions on this drive are currently mounted. You can still select the drive; however, the confirmation screen will show a warning. Therefore, unmount partitions before erasing where possible.
USB drive not listed	USB drives appear in the Block Wipe section. Therefore, to reveal them, click “Show Block Wipe” in the Options bar.
eMMC not listed	The card may not advertise SEC_ERASE_SUPPORT in its extended CSD register, and as a result it appears in Block Wipe instead. In addition, the `mmc` tool must be installed for hardware erase.
Drive shows FROZEN	The BIOS has frozen the drive’s ATA security. Therefore, click Sleep — the utility suspends briefly and restarts. In fact, most drives unfreeze on power cycle.

Erase Operation Issues

Problem	Solution
SMART gate blocking Start Erase	One or more selected drives failed the SMART health check. First, check the red warning box on the confirmation screen. Then either tick the override checkbox to proceed, or go Back and deselect the failing drive.
Erase Failed	The drive firmware rejected the erase command. For details, check smartctl output in the Advanced Log. For example, the drive may be locked, failing, or unsupported.
ATA erase interrupted — drive now locked	An interrupted ATA Secure Erase can leave the drive locked with the password `pmagic` still set (small capacity, won’t mount, or “security frozen”). However, the drive is not dead. Instead, run ATA Security Disable (`pmagic_ata_security_disable`), leave the password at the default `pmagic`, and disable security to restore the drive. See Recovering a Drive After an Interrupted ATA Secure Erase above.
Verification reports Mismatch	The verifier found non-zero bytes on a drive after a zeros-mode erase. In other words, this usually means the drive firmware reported success but did not fully zero the media. Check the Advanced Log for the erase command output, and try the alternate erase path if one is available (for example, ATA Secure Erase on a drive that failed ATA Sanitize verification).
Certificate not generated	ReportLab is required. Therefore, install it with: `pip install reportlab --break-system-packages`
Email not sent	You must configure `mailx` with a working MTA. Therefore, check `/etc/mailx.rc` or sendmail.

Network Reporting Issues

Problem	Solution
Nothing appears on the dashboard	First, confirm that the address in the Report server field matches the machine running `pmagic_report_server`; then check that both machines are on the same network and that a firewall is not blocking port 8341. In addition, remember that an emptied field means reporting is off, and that a server started with `--token` requires the matching `pmreport_token=` on the client.
No window appears when the server starts	The window needs a Linux desktop with GTK 3 available to Python. On Windows, on a Mac, or over SSH with no display, the server runs headless and prints its address in the terminal instead; likewise, `--no-gui` forces headless mode anywhere. Meanwhile, everything remains available in the browser dashboard.
Session shows STALLED	In short, the client stopped sending — power loss, network drop, or a hard hang. Nevertheless, everything received up to that point remains safe on the server: the drive manifest, every heartbeat, and every drive that had completed. Afterward, re-run the erase, because an interrupted erase should never count as complete.
Evidence pack fails verification	Either someone modified the pack after export, or the public key does not match the server that signed it. Therefore, re-download the pack and confirm the key against the server’s `/pubkey`. Similarly, a pack that passes without `--pubkey` but fails with it carries a signature from a different key than the one you supplied.

Get Parted Magic Secure Erase

Every option below is the complete product: Secure Erase with NIST SP 800-88r2 Purge certificates, the PM Report Server, signed evidence packs, and the offline verifier. No device limits, no per-drive fees, no per-seat math.

Buy & Download at the Parted Magic Store

Your purchase covers unlimited machines and unlimited drives. The PM Report Server and the pmagic_verify offline verifier ship in the root of the ISO — nothing extra to buy or install.