Safely Inspect and Remove Device Signatures with wipefs

A stray filesystem signature confuses the kernel, and wipefs finds and removes it without touching your data. It identifies filesystem, RAID or partition-table signatures on a block device, previews a proposed wipe, and removes selected metadata while leaving the ordinary contents alone. The dangerous part is still dangerous: once a signature is gone, software may stop recognising whatever data remains on the device.

Allow about fifteen minutes for an inspection and a carefully backed-up wipe. You need a shell, the util-linux package, the correct device path, and enough privilege to read and modify that device. The examples use util-linux 2.42.4, the version of wipefs installed here. Output formatting can differ between releases.

Warning: Replace /dev/DEVICE only after checking it several times. A typo can put the operation on the wrong disk. Do not use these examples against a mounted or production device until you understand its partition and service dependencies.

1. Confirm the command and identify the device

Checking the binary and version is read-only and normally needs no elevated privileges:

$ command -v wipefs
/usr/sbin/wipefs
$ wipefs --version
wipefs from util-linux 2.42.4

Now identify the device using a command that shows model, size and mount information. This example is also read-only:

$ lsblk --fs
NAME   FSTYPE FSVER LABEL UUID                                 FSAVAIL FSUSE% MOUNTPOINTS
sda
|-sda1 ext4   1.0         01234567-89ab-cdef-0123-456789abcdef  120G     8% /
`-sdb

Your output will be different. Treat /dev/DEVICE below as a prompt to substitute an exact path, not as a literal command. If you are checking a whole disk, remember that its partitions are separate device nodes.

2. List visible signatures without changing anything

Run wipefs without an erase option. It lists signatures visible to libblkid and their byte offsets:

$ sudo wipefs --output DEVICE,OFFSET,TYPE /dev/DEVICE
DEVICE     OFFSET TYPE
/dev/DEVICE 0x438 ext4

The exact rows depend on the device. A disk can contain more than one magic string, and filesystems such as FAT or ZFS and partition tables such as GPT can expose signatures at multiple offsets. The default columns are allowed to change, so scripts should request an explicit --output list.

Checkpoint: Stop if the reported device, type or offset is not what you expected. This command has not written to the device. If it reports no signatures, there is nothing for the ordinary erase forms in this guide to remove.

3. Preview the exact write with no-act

Before an irreversible operation, select the signature by its offset and add --no-act. This performs the checks and normal work except the actual write(2) call:

$ sudo wipefs --no-act --offset 0x438 /dev/DEVICE
/dev/DEVICE: 2 bytes were erased at offset 0x00000438 (ext4): 53 ef

The byte count, signature name and final byte values depend on your device, so treat that line as the expected shape rather than a fixed result. Use the offset reported by your own inspection. An offset can be decimal, hexadecimal with a 0x prefix, or a size such as 1KiB. You can provide more than one --offset option. Previewing is useful, but it is not a substitute for checking the device path immediately before the real write.

4. Make a signature backup

There is no general undo operation for a wipe. For a recoverable workflow, ask wipefs to save each signature before erasing it. The backup is written in your home directory by default:

$ sudo wipefs --all --backup=/var/tmp /dev/DEVICE
/dev/DEVICE: 2 bytes were erased at offset 0x00000438 (ext4): 53 ef

The line reports the bytes removed; its values depend on the signature. Choose a backup directory that is on a different, trusted filesystem and is writable by the process running wipefs. With sudo, that is normally root's environment and permissions. The files use names like wipefs-DEVICE-0x00000438.bak. Check them before proceeding:

$ sudo ls -l /var/tmp/wipefs-DEVICE-*.bak
$ sudo wc -c /var/tmp/wipefs-DEVICE-*.bak

Keep the backup private. It contains the original signature bytes and may reveal storage layout information. Do not assume that a small signature backup can restore a damaged filesystem or partition table; it restores only the bytes that wipefs saved.

5. Erase only the chosen signature

If the preview and backup match your plan, perform a targeted wipe. This needs elevated privileges on most block devices and changes device metadata:

$ sudo wipefs --offset 0x438 /dev/DEVICE

To remove every signature visible to libblkid instead, use --all:

$ sudo wipefs --all --backup=/var/tmp /dev/DEVICE

Prefer the targeted form when you know the signature you mean. --all scans again after each erase and can remove several signatures. On a partitioned whole disk it removes partition-table signatures, not the contents of the partitions. It does not erase a filesystem's data blocks.

Use --types when you need to limit the operation to named signature types, for example:

$ sudo wipefs --all --types ext4 --backup=/var/tmp /dev/DEVICE

Do not add --force merely to make an error disappear. It permits erasure even when a filesystem is mounted, and it is required for nested partition-table signatures on non-whole-disk devices. Unmount filesystems and stop anything using the device first. Forcing a write under a live workload can cause corruption or confuse the kernel and udev.

6. Verify the result and understand partition-table updates

List the signatures again after the command finishes:

$ sudo wipefs --output DEVICE,OFFSET,TYPE /dev/DEVICE

The erased signature should no longer be listed. An empty result is expected when no visible signatures remain. If you erased a partition-table signature, wipefs asks the kernel to re-read the partition table as its last step, after all requested devices and signatures have been processed. A re-read can still be refused while partitions are busy, so check the result with:

$ lsblk --fs /dev/DEVICE

If the old layout remains visible, do not repeat destructive commands blindly. Check mounts, open users and udev activity, then arrange a maintenance window and investigate the kernel's messages. A signature wipe is not a partitioning operation and does not create a new filesystem.

7. Restore a saved signature only when you mean to

Restoration is also a privileged, destructive write. It puts bytes back at a precise offset; it does not validate the rest of the device. First confirm the backup file, target device and offset. Then use a block-sized write with conv=notrunc:

$ sudo dd if=/var/tmp/wipefs-DEVICE-0x00000438.bak \
    of=/dev/DEVICE seek=$((0x438)) bs=1 conv=notrunc status=none
$ sudo wipefs --output DEVICE,OFFSET,TYPE /dev/DEVICE

The final listing should show the restored signature if the saved bytes and offset belong to that device. Do not restore a backup to a different disk or to a changed partition layout. If the original device contained valuable data, use a full image and filesystem-specific recovery procedures rather than treating this byte backup as a complete recovery plan.

Common traps

Confusing metadata with data: wipefs hides signatures from libblkid. It is not a secure erase tool and does not overwrite the filesystem contents.
Using a whole-disk path by habit: /dev/sdb and /dev/sdb1 are different targets. Re-check the output of lsblk.
Trusting default output in scripts: request columns with --output and parse the result appropriate to your util-linux version.
Forgetting nested tables: non-whole-disk devices do not have nested partition tables erased by default; --force changes that safety boundary.
Expecting an undo button: no backup means no byte-level restoration path supplied by wipefs.

Done means

You confirmed the installed wipefs version and exact target device.
You inspected signatures and selected an offset or an explicitly limited type set.
You previewed the operation and created a protected backup before writing.
You avoided --force unless the mounted or nested-device boundary was understood.
A post-wipe wipefs --output DEVICE,OFFSET,TYPE check matches the intended result.