Changes for page Effacer la signature d'un périphérique avec wipefs

Summary

• Page properties (1 modified, 0 added, 0 removed)

Details

Page properties

Content

...	...	@@ -1,11 +1,15 @@
	1	+= Wipe a device's signature with wipefs =
	2	+
1	1	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.
2	2
3		-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>>Trucs et astuces.Installation Linux en échec causé par une scorie GPT]] //(adjust the link to point to the English version of that page, if one exists)//.
	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]].
4	4
	7	+
5	5	== A concrete case with a USB stick ==
6	6
7	7	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.
8	8
	12	+
9	9	== Procedure, in order ==
10	10
11	11	=== 1. Identify the device ===
...	...	@@ -12,6 +12,7 @@
12	12
13	13	The device is identified first, to make sure the operations that follow are carried out on the right target.
14	14
	19	+
15	15	As a regular user:
16	16
17	17	{{code language="bash"}}
...	...	@@ -18,11 +18,52 @@
18	18	lsblk
19	19	{{/code}}
20	20
21		-=== 2. Check the partition table type and the presence of signatures ===
22	22
	27	+=== 2. Unmount all partitions of the device ===
	28	+
	29	+Before any manipulation, make sure no partition of the device is still mounted.
	30	+
	31	+
23	23	With administrator privileges:
24	24
25	25	{{code language="bash"}}
	35	+umount /dev/sdX*
	36	+{{/code}}
	37	+
	38	+Where ##/dev/sdX## should be adapted, based on what ##lsblk## found.
	39	+
	40	+
	41	+Check that nothing remains mounted:
	42	+
	43	+{{code language="bash"}}
	44	+mount | grep sdX
	45	+{{/code}}
	46	+
	47	+
	48	+If a partition still appears mounted, unmount it explicitly (replacing the number with the one concerned):
	49	+
	50	+{{code language="bash"}}
	51	+umount /dev/sdX1
	52	+{{/code}}
	53	+
	54	+
	55	+{{info}}
	56	+If the device is reported as "busy" during unmounting or a later step, a process is still using it. To identify it:
	57	+
	58	+{{code language="bash"}}
	59	+lsof /dev/sdX*
	60	+fuser -v /dev/sdX*
	61	+{{/code}}
	62	+{{/info}}
	63	+
	64	+(% class="wikigeneratedid" %)
	65	+
	66	+
	67	+=== 3. Check the partition table type and the presence of signatures ===
	68	+
	69	+With administrator privileges:
	70	+
	71	+{{code language="bash"}}
26	26	blkid -p /dev/sdX
27	27	{{/code}}
28	28
...	...	@@ -30,8 +30,11 @@
30	30
31	31	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).
32	32
33		-=== 3. Confirm with wipefs, in read-only mode ===
34	34
	80	+=== 4. Confirm with wipefs, in read-only mode ===
	81	+
	82	+
	83	+
35	35	With administrator privileges:
36	36
37	37	{{code language="bash"}}
...	...	@@ -40,8 +40,11 @@
40	40
41	41	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.
42	42
43		-=== 4. Erase all residual signatures ===
44	44
	93	+=== 5. Erase all residual signatures ===
	94	+
	95	+
	96	+
45	45	With administrator privileges:
46	46
47	47	{{code language="bash"}}
...	...	@@ -56,20 +56,37 @@
56	56	##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.
57	57	{{/info}}
58	58
59		-=== 5. Verify that the cleanup was effective ===
	111	+(% class="wikigeneratedid" %)
60	60
	113	+
	114	+=== 6. Force the kernel to reread the partition table ===
	115	+
	116	+
	117	+
61	61	With administrator privileges:
62	62
63	63	{{code language="bash"}}
	121	+partprobe /dev/sdX
	122	+{{/code}}
	123	+
	124	+Without this step, the system may still display a cached state during the next verification, rather than the device's actual state after cleanup.
	125	+
	126	+
	127	+=== 7. Verify that the cleanup was effective ===
	128	+
	129	+With administrator privileges:
	130	+
	131	+{{code language="bash"}}
64	64	blkid -p /dev/sdX
65	65	{{/code}}
66	66
67		-##/dev/sdX## should still be adapted.
	135	+Shouldn't return anything (or only the device's generic information): a sign that the device is now on a clean footing (##/dev/sdX## should still be adapted).
68	68
69		-Should return nothing (or only the device's generic information): a sign that the device is now on a clean footing.
70	70
71		-=== 6. Repartition ===
	138	+=== 8. Repartition ===
72	72
	140	+
	141	+
73	73	At this point, GParted can create a new partition table and a partition (ext4, exfat…) without ambiguity.
74	74
75	75	{{info}}
...	...	@@ -76,6 +76,9 @@
76	76	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.
77	77	{{/info}}
78	78
	148	+(% class="wikigeneratedid" %)
	149	+
	150	+
79	79	== Key takeaway ==
80	80
81		-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.
	153	+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.