ShredOS: a bootable nwipe disk eraser for x86 machines

What ShredOS is for, and who should not use it

ShredOS solves one narrow problem: erasing entire disks on hardware that still has to be trusted afterwards. It is a bootable operating system built with Buildroot that starts nwipe automatically, so the machine under treatment never boots its own installed OS. The README describes the target hardware as x86 PCs, servers and Intel-based Macs, with BIOS or UEFI firmware, and both 64-bit and selected 32-bit builds are published.

The audience is correspondingly narrow. Refurbishers preparing machines for resale, IT staff decommissioning servers, and anyone who needs a documented wipe fits. The README carries a warning that ShredOS is built to irreversibly erase data and that every selected drive should be double-checked, especially on systems with multiple internal, external or USB-attached disks. That warning is not boilerplate: nwipe presents a drive list, and a misread entry destroys the wrong device.

If your goal is deleting files inside a running system, or wiping a single partition while keeping the rest, ShredOS is the wrong tool. It operates on disks, from outside the installed OS, and it does not offer a selective file-level mode.

How nwipe, the erasure methods and the PDF certificates fit together

The data flow is short. Boot media loads a Linux system; nwipe starts and enumerates attached drives; you select drives, a wipe method or pattern, rounds and verification, and whether a final blanking pass runs. The README lists multiple erasure methods and pseudo-random generators among the features, and the repository topics include the DoD reference and dwipe, nwipe's ancestor. The wipe itself happens in nwipe, not in ShredOS.

What ShredOS adds around nwipe is the environment. The image ships disk tools including smartmontools, hdparm, nvme-cli, sg3_utils, hexedit and parallel. Those matter after the fact: SMART data is pulled into the erasure certificates. Two certificate shapes are documented. A per-drive certificate produces one multi-page PDF per erased drive with erasure details and SMART data. A system-focused certificate produces one multi-page PDF for the whole machine, adding selected drive results, host identifiers, tags, SMBIOS data and SMART data for each processed HDD, SSD or NVMe drive.

The certificate branding is a file drop, not a build option. A square JPEG named logo.jpg placed in /etc/nwipe/ on the ShredOS USB drive replaces the default logo, with 256x256 to 1024x1024 pixels at a 1:1 aspect ratio recommended. PXE or remote-configuration setups place the same file beside nwipe.conf and nwipe_customers.csv. That is a clean separation: the audit artifact is configurable without rebuilding the image.

Installing ShredOS: writing the image and running a first wipe

There is nothing to install on the target machine. The README points to the release page as the source of truth for downloads, checksums, release notes and pre-release builds, and the workflow is download, verify the checksum, write the image, boot. On Linux the documented command writes the .img to a whole device:

sudo dd if=shredos.img of=/dev/sdX bs=4M status=progress conv=fsync

Replace /dev/sdX with the actual USB device, not a partition such as /dev/sdX1. Writing to a partition produces media that will not boot.

On macOS the README tells you to list and unmount the device first, then write to the raw disk device:

sudo dd if=shredos.img of=/dev/rdiskN bs=4m
sync

On Windows the documented tools are Rufus and Etcher. For Ventoy, copy the .img or .iso file to the Ventoy drive and select it from the Ventoy boot menu. Choose the image format by purpose: .img for USB flash drives and autonuke setups, .iso for CD/DVD, Ventoy, virtual machines and USB-writing tools that prefer ISO input. Modern .img releases support BIOS and UEFI booting and can save generated PDF reports back to the USB drive, which is the reason to prefer .img when you want the certificate written to the stick itself.

After booting, ShredOS starts nwipe automatically. Review the detected drives, choose the wipe options, and start only when the selection is correct. If you would rather build the image yourself, the README gives the Buildroot path:

git clone https://github.com/PartialVolume/shredos.x86_64.git
cd shredos.x86_64
make shredos_defconfig
make
ls output/images/shredos*

The other documented configurations are shredos_lite_defconfig, shredos_i686_lite_defconfig, shredos_iso_extra_defconfig and shredos_iso_extra_i686_lite_defconfig. The last two are described as experimental: hybrid ISOs with an appended writable partition, one 64-bit and one 32-bit lite.

Autonuke, PXE and headless operation: the parts with the least margin for error

The README states that ShredOS can be configured for unattended autonuke workflows, PXE booting, custom scripts, persistent options and headless operation on trusted networks. It also states that the .img format is the one used for autonuke setups and for persistent boot-media customization such as GRUB edits and kernel parameters. So the unattended path is real, and it depends on modifying the boot media rather than passing flags at the nwipe prompt.

This is where the documentation thins out. The README points to a documentation map for configuring nwipe, certificates, keyboard, display and headless use, but the autonuke configuration itself, the exact kernel parameters, and a rollback procedure for a media edit that goes wrong are not spelled out in the README text. That is a genuine constraint for anyone planning unattended wipes at scale: the failure mode is a machine that boots and wipes without a human confirming the drive list. The README's own warning about double-checking every selected drive reads differently in that context, because in autonuke there is no one to double-check.

Treat headless operation as a feature for trusted networks with known hardware, and treat the first run on any new hardware model as something to watch, not schedule.

ShredOS compared with DBAN

The comparison people actually make is with DBAN, and the difference is in the maintenance model rather than the interface. DBAN is the older, widely known bootable eraser; nwipe is a maintained reimplementation of dwipe, the wiping engine DBAN used, and ShredOS packages nwipe as the default interface of a current Buildroot image.

The practical differences visible here are the ones that matter for modern hardware. ShredOS publishes both BIOS and UEFI booting for modern .img and .iso releases, ships nvme-cli alongside hdparm and sg3_utils, and pulls SMART data into PDF certificates. Those are the needs of machines with NVMe drives and an audit trail. DBAN predates much of that hardware.

What DBAN still offers is familiarity: a single well-known workflow that many technicians already know. If your fleet is old BIOS hardware and nobody needs a certificate, that familiarity has value. If you are wiping NVMe drives and have to hand someone a PDF afterwards, ShredOS is the closer fit. Note also that ShredOS publishes 32-bit lite builds, so the 64-bit focus in the repository name does not exclude older 32-bit machines entirely.

Licence, maintenance and what an upgrade costs

The repository is not archived and the last push was on 2026-09-21, three days before this writing, so the project is being worked on. Releases are frequent: v2025.11_31_x86-64_0.42 on 2026-07-16, v2025.11_30_x86-64_0.41 on 2026-05-21 and v2025.11_29_x86-64_0.40 on 2026-04-02. The version string encodes the Buildroot base and the ShredOS revision, so a jump from 0.41 to 0.42 is a ShredOS-side change on the same 2025.11 base.

Licensing is not straightforward to read off the repository. The licence field reports NOASSERTION, meaning no standard licence identifier was detected. The Buildroot Makefile in the repository root carries the GNU General Public License version 2 text from the Buildroot developers, and the repository contains a COPYING file, while nwipe is a separate project with its own licensing. A distribution that bundles Buildroot, nwipe and other packages carries the obligations of each. If you redistribute ShredOS images inside a commercial service, have someone read COPYING and the package licences rather than assuming the top-level field settles it. This is a description of what the repository shows, not legal advice.

Upgrade cost is low by design. There is no installed base to patch: you write a new image to the boot media and the old one is gone. The cost is verification, not migration. Because each release lists checksums in its release notes and pre-releases may contain fewer image formats than stable releases, the sensible habit is to download from the release page, verify the checksum, and only then write the stick.

Editorial conclusion

ShredOS fits technicians, refurbishers and IT teams who wipe whole machines in person and need a record of the job: the .img and .iso images are written with dd, Rufus or Etcher, and certificates can be produced per drive or per system. Do not adopt it if you need per-file erasure on a running operating system, or if you cannot verify that the media you booted is the release you downloaded. Before your first real wipe, confirm the checksum listed in the release notes, check that nwipe lists only the disks you intend to erase, and decide whether you want the stable or a pre-release image, since pre-releases may contain fewer image formats.

Frequently asked questions

Official sources

1. Issues
2. PartialVolume/shredos.x86_64 on GitHub
3. README
4. Releases