Wipe a device's signature with wipefs

A hard drive or a USB stick that has already had a previous life (a former operating system installed, a disk image in ISO format previously burned) can retain residual signatures invisible in GParted: leftover partition table, leftover filesystem. These signatures can cause undesirable behaviour: an installation refusing to boot, a device impossible to repartition, a partition detected as "unknown" even though it was properly created.

This page describes the diagnostic and cleanup method, using wipefs, applicable to any storage device, regardless of its origin. For a detailed case of a residual GPT signature on an internal hard drive, see the page Linux installation failing because of a GPT remnant

A concrete case with a USB stick

A 7.25 GB USB stick refused to be reformatted from GParted, with the intent of installing Ventoy on it. This stick had previously been prepared with Balena Etcher to boot a Live image of a Linux distribution. The same kind of blockage can occur with a stick prepared via dd or Gnome Disks, as these tools write the image bit by bit onto the device, thereby reproducing the ISO9660 format of the disk image.

Procedure, in order

1. Identify the device

The device is identified first, to make sure the operations that follow are carried out on the right target.

As a regular user:

2. Check the partition table type and the presence of signatures

With administrator privileges:

Where /dev/sdX should be adapted, based on what lsblk found.

The -p option forces a low-level probe, which reads the device directly instead of relying on the system's cache. This is decisive here: a stick prepared with dd can retain information cached by udev/blkid that no longer matches reality once the stick has been reused. This command typically reveals several overlapping or contradictory signatures (for example, an ISO9660 signature left over from the distribution's ISO image, in addition to a possible partition table).

3. Confirm with wipefs, in read-only mode

With administrator privileges:

Lists all signatures known to the kernel across the entire device (partition table, filesystems, RAID…), along with their position (offset - the position in bytes of a signature within the device, counted from sector 0). This step makes it possible to see precisely what needs to be erased, before doing so.

4. Erase all residual signatures

With administrator privileges:

As before, /dev/sdX should be adapted, based on what lsblk found.

The -a option erases all the signatures found in the previous step, across the entire device — not just those visible in an active partition table. This is the step that resolves the conflict behind the formatting failure in GParted.

Information

wipefs -a is preferable to a blind dd if=/dev/zero of=/dev/sdX: the latter overwrites the entire device (slower, riskier if count isn't carefully controlled), whereas wipefs targets precisely the identified signatures, wherever they are on the disk — including a signature at the end of the disk, as in the GPT remnant case mentioned earlier.

5. Verify that the cleanup was effective

With administrator privileges:

/dev/sdX should still be adapted.

Should return nothing (or only the device's generic information): a sign that the device is now on a clean footing.

6. Repartition

At this point, GParted can create a new partition table and a partition (ext4, exfat…) without ambiguity.

Information

If the end goal is to install Ventoy on the stick: it is recommended to create the partition table with GParted before launching the Ventoy installer, rather than letting it manage the entire disk on its own. This makes it possible to explicitly choose MS-DOS or GPT depending on the target machine, useful for instance when facing a hybrid BIOS/UEFI that will only boot from an MS-DOS table. Ventoy also offers its own option for this choice (-g for GPT, MBR by default); see the documentation on ventoy.net and in the program's README, for installation details.

Key takeaway

Whether it's an internal hard drive that previously ran under GPT/UEFI, or a USB stick prepared with dd, Balena Etcher, or Gnome Disks, the symptom looks the same: a device that refuses to cooperate even though GParted sees nothing wrong with it. The reflex is the same in every case: diagnose with blkid -p and wipefs, then clean up with wipefs -a across the entire device, before rebuilding a healthy partition table.