Wiki source code of Effacer la signature d'un périphérique avec wipefs
Last modified by Mélodie on 2026/07/11 13:38
Hide last authors
| author | version | line-number | content |
|---|---|---|---|
| |
11.1 | 1 | = Wipe a device's signature with wipefs = |
| |
5.1 | 2 | |
| |
11.1 | 3 | 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. |
| |
1.1 | 4 | |
| |
11.1 | 5 | 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 [[Failed Linux Installation Due to a Residual GPT Signature>>Trucs et astuces.Installation Linux en échec causé par une scorie GPT]]. |
| |
1.1 | 6 | |
| 7 | |||
| |
11.1 | 8 | == A concrete case with a USB stick == |
| |
1.1 | 9 | |
| |
11.1 | 10 | 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. |
| |
1.1 | 11 | |
| 12 | |||
| |
11.1 | 13 | == Procedure, in order == |
| |
1.1 | 14 | |
| |
11.1 | 15 | === 1. Identify the device === |
| |
1.1 | 16 | |
| |
11.1 | 17 | The device is identified first, to make sure the operations that follow are carried out on the right target. |
| 18 | |||
| 19 | |||
| 20 | As a regular user: | ||
| 21 | |||
| |
1.4 | 22 | {{code language="bash"}} |
| 23 | lsblk | ||
| 24 | {{/code}} | ||
| |
1.1 | 25 | |
| |
1.2 | 26 | |
| |
11.1 | 27 | === 2. Unmount all partitions of the device === |
| |
5.1 | 28 | |
| |
11.1 | 29 | Before any manipulation, make sure no partition of the device is still mounted. |
| |
6.2 | 30 | |
| |
1.2 | 31 | |
| |
11.1 | 32 | With administrator privileges: |
| 33 | |||
| |
5.1 | 34 | {{code language="bash"}} |
| 35 | umount /dev/sdX* | ||
| 36 | {{/code}} | ||
| |
1.2 | 37 | |
| |
11.1 | 38 | Where ##/dev/sdX## should be adapted, based on what ##lsblk## found. |
| |
6.1 | 39 | |
| |
6.2 | 40 | |
| |
11.1 | 41 | Check that nothing remains mounted: |
| |
5.1 | 42 | |
| |
1.4 | 43 | {{code language="bash"}} |
| |
5.1 | 44 | mount | grep sdX |
| 45 | {{/code}} | ||
| 46 | |||
| |
6.2 | 47 | |
| |
11.1 | 48 | If a partition still appears mounted, unmount it explicitly (replacing the number with the one concerned): |
| |
5.1 | 49 | |
| 50 | {{code language="bash"}} | ||
| 51 | umount /dev/sdX1 | ||
| 52 | {{/code}} | ||
| 53 | |||
| |
11.1 | 54 | |
| |
5.1 | 55 | {{info}} |
| |
11.1 | 56 | If the device is reported as "busy" during unmounting or a later step, a process is still using it. To identify it: |
| |
5.1 | 57 | |
| 58 | {{code language="bash"}} | ||
| 59 | lsof /dev/sdX* | ||
| 60 | fuser -v /dev/sdX* | ||
| 61 | {{/code}} | ||
| 62 | {{/info}} | ||
| 63 | |||
| 64 | |||
| |
6.2 | 65 | |
| |
11.1 | 66 | === 3. Check the partition table type and the presence of signatures === |
| |
6.2 | 67 | |
| |
11.1 | 68 | With administrator privileges: |
| |
5.1 | 69 | |
| 70 | {{code language="bash"}} | ||
| |
4.1 | 71 | blkid -p /dev/sdX |
| |
3.1 | 72 | {{/code}} |
| 73 | |||
| |
11.1 | 74 | Where ##/dev/sdX## should be adapted, based on what ##lsblk## found. |
| |
1.2 | 75 | |
| |
11.1 | 76 | 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). |
| |
6.2 | 77 | |
| |
1.1 | 78 | |
| |
11.1 | 79 | === 4. Confirm with wipefs, in read-only mode === |
| |
6.2 | 80 | |
| |
1.1 | 81 | |
| |
1.3 | 82 | |
| |
11.1 | 83 | With administrator privileges: |
| 84 | |||
| |
1.1 | 85 | {{code language="bash"}} |
| |
1.3 | 86 | wipefs /dev/sdX |
| |
1.1 | 87 | {{/code}} |
| 88 | |||
| |
11.1 | 89 | 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. |
| |
1.1 | 90 | |
| |
6.2 | 91 | |
| |
11.1 | 92 | === 5. Erase all residual signatures === |
| |
1.1 | 93 | |
| |
6.2 | 94 | |
| |
1.2 | 95 | |
| |
11.1 | 96 | With administrator privileges: |
| 97 | |||
| |
1.1 | 98 | {{code language="bash"}} |
| |
1.2 | 99 | wipefs -a /dev/sdX |
| |
1.1 | 100 | {{/code}} |
| 101 | |||
| |
11.1 | 102 | As before, ##/dev/sdX## should be adapted, based on what ##lsblk## found. |
| |
1.2 | 103 | |
| |
11.1 | 104 | 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. |
| |
1.1 | 105 | |
| 106 | {{info}} | ||
| |
11.1 | 107 | ##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. |
| |
1.1 | 108 | {{/info}} |
| 109 | |||
| |
6.2 | 110 | |
| |
1.1 | 111 | |
| |
11.1 | 112 | === 6. Force the kernel to reread the partition table === |
| |
1.2 | 113 | |
| |
11.1 | 114 | |
| 115 | |||
| 116 | With administrator privileges: | ||
| 117 | |||
| |
1.1 | 118 | {{code language="bash"}} |
| |
5.1 | 119 | partprobe /dev/sdX |
| 120 | {{/code}} | ||
| 121 | |||
| |
11.1 | 122 | Without this step, the system may still display a cached state during the next verification, rather than the device's actual state after cleanup. |
| |
5.1 | 123 | |
| |
6.2 | 124 | |
| |
11.1 | 125 | === 7. Check effectiveness of the cleanup === |
| |
5.1 | 126 | |
| |
11.1 | 127 | With administrator privileges: |
| |
5.1 | 128 | |
| 129 | {{code language="bash"}} | ||
| |
1.2 | 130 | blkid -p /dev/sdX |
| |
1.1 | 131 | {{/code}} |
| 132 | |||
| |
11.1 | 133 | Shouldn't return anything (or only the device's generic information), which means the device has been properly cleaned. (##/dev/sdX## should still be adapted.) |
| |
1.2 | 134 | |
| |
11.1 | 135 | Additionally, it's possible to inspect the raw bytes of the first sector directly: |
| |
1.1 | 136 | |
| |
10.1 | 137 | {{code language="bash"}} |
| 138 | hexdump -C -n 512 /dev/sdX | tail -n 2 | ||
| 139 | {{/code}} | ||
| 140 | |||
| |
11.1 | 141 | or, equivalently: |
| |
10.1 | 142 | |
| 143 | {{code language="bash"}} | ||
| 144 | xxd -l 512 /dev/sdX | tail -n 2 | ||
| 145 | {{/code}} | ||
| 146 | |||
| |
11.1 | 147 | Once the new partition table has been created, the boot sector's end-of-sector signature (##55 aa##, at bytes 510-511) should be present. This signature is universal: it appears on both a ##dos## table and a ##gpt## table, the latter always starting with a "protective MBR" in the first sector, itself ending with the ##55 aa## signature as well. Its presence is simply an indicator of consistency in the first sector, regardless of the partition table type in use. |
| |
10.1 | 148 | |
| |
10.2 | 149 | |
| |
11.1 | 150 | === 8. Repartition === |
| |
1.1 | 151 | |
| |
7.1 | 152 | |
| 153 | |||
| |
11.1 | 154 | At this point, GParted can create a new partition table and a partition (ext4, exfat…) without ambiguity. |
| |
1.1 | 155 | |
| 156 | {{info}} | ||
| |
11.1 | 157 | 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>>https://ventoy.net]] and in the program's README, for installation details. |
| |
1.1 | 158 | {{/info}} |
| 159 | |||
| |
7.1 | 160 | |
| 161 | |||
| |
11.1 | 162 | == Key takeaway == |
| |
1.1 | 163 | |
| |
11.1 | 164 | It can be a hard drive which previously ran under GPT/UEFI, or a USB thumbdrive prepared with dd, Balena Etcher, or Gnome Disks: the symptom looks the same : a device not behaving as expected, whether it means a silent failure to boot, or a partition GParted flags as "unknown". The reflex is the same in every case: unmount, diagnose with ##blkid -p## and ##wipefs##, then clean up with ##wipefs -a## across the entire device, before rebuilding a healthy partition table. |