What is the best way to wipe a GPT partition table completely from an USB key?
(Background: My USB key contains a GPT partition table, probably from an OS installation (FreeNAS, openSUSE installation media ...). Parted, fdisk, gdisk have functions to create a new MSDOS partition table, but they do not wipe the GPT completely. As the result, Grub2 functions (grub2-install, YaST Bootloader) fail. Currently I do "dd if=/dev/zero of=/dev/disk/by-id/<my-usb-key-device> bs=64M", but this takes long.)
Greetings, Björn
Le 07/05/2017 à 16:57, Bjoern Voigt a écrit :
What is the best way to wipe a GPT partition table completely from an USB key?
yast?
did the job for me for a raid disk, may be can do the same for gpt (not tested)
jdd
Op zondag 7 mei 2017 16:57:53 CEST schreef Bjoern Voigt:
What is the best way to wipe a GPT partition table completely from an USB key?
(Background: My USB key contains a GPT partition table, probably from an OS installation (FreeNAS, openSUSE installation media ...). Parted, fdisk, gdisk have functions to create a new MSDOS partition table, but they do not wipe the GPT completely. As the result, Grub2 functions (grub2-install, YaST Bootloader) fail. Currently I do "dd if=/dev/zero of=/dev/disk/by-id/<my-usb-key-device> bs=64M", but this takes long.)
Greetings, Björn
You're zeroing the disk with 64MB sized blocks entirely
I use
dd if=/dev/zero of=/dev/sdX bs=1M count=64
See if that changes anything. It only writes the first 64MB, where the partition tables reside.
Knurpht - Gertjan Lettink wrote:
You're zeroing the disk with 64MB sized blocks entirely
I use
dd if=/dev/zero of=/dev/sdX bs=1M count=64
See if that changes anything. It only writes the first 64MB, where the partition tables reside.
GPT has a backup GPT, which does not reside in the first 64 MB and this backup partition table causes problems. The backup GPT should reside in the last block. So at least we need a "dd" command which also wipes the last block. Probably programs like parted, gdisk and YaST fail to wipe the backup GPT.
"The header contains the disk GUID. It records its own size and location (always LBA 1) and the size and location of the secondary GPT header and table (always the last sectors on the disk). Importantly, it also contains a CRC32 https://en.wikipedia.org/wiki/CRC32 checksum for itself and for the partition table, which may be verified by the firmware, bootloader, or operating system on boot. Because of this, hex editors should not be used to modify the contents of the GPT. Such modification would render the checksum invalid. In this case, the primary GPT may be overwritten with the secondary one by disk recovery software. If both GPTs contain invalid checksums, many bootloaders (those governed by an integrity model in particular) and operating systems will refuse to work with the disk until the corrupted partition tables are repaired or removed." Source: https://en.wikipedia.org/wiki/GUID_Partition_Table
Greetings, Björn
Knurpht - Gertjan Lettink wrote:
Op zondag 7 mei 2017 16:57:53 CEST schreef Bjoern Voigt:
What is the best way to wipe a GPT partition table completely from an USB key?
(Background: My USB key contains a GPT partition table, probably from an OS installation (FreeNAS, openSUSE installation media ...). Parted, fdisk, gdisk have functions to create a new MSDOS partition table, but they do not wipe the GPT completely. As the result, Grub2 functions (grub2-install, YaST Bootloader) fail. Currently I do "dd if=/dev/zero of=/dev/disk/by-id/<my-usb-key-device> bs=64M", but this takes long.)
Greetings, Björn
You're zeroing the disk with 64MB sized blocks entirely
I use
dd if=/dev/zero of=/dev/sdX bs=1M count=64
See if that changes anything. It only writes the first 64MB, where the partition tables reside.
That is where the primary GPT table resides, the secondary is at the end of the disk. 64M is overkill, 16K is likely more than enough.
On May 7, 2017 4:57:53 PM GMT+02:00, Bjoern Voigt bjoernv@arcor.de wrote:
What is the best way to wipe a GPT partition table completely from an USB key?
(Background: My USB key contains a GPT partition table, probably from an OS installation (FreeNAS, openSUSE installation media ...). Parted, fdisk, gdisk have functions to create a new MSDOS partition table, but they do not wipe the GPT completely. As the result, Grub2 functions (grub2-install, YaST Bootloader) fail. Currently I do "dd if=/dev/zero of=/dev/disk/by-id/<my-usb-key-device> bs=64M", but this takes long.)
Greetings, Björn
$ man wipefs
On 2017-05-07 18:00, Rüdiger Meier wrote:
On May 7, 2017 4:57:53 PM GMT+02:00, Bjoern Voigt bjoernv@arcor.de wrote:
What is the best way to wipe a GPT partition table completely from an USB key?
(Background: My USB key contains a GPT partition table, probably from an OS installation (FreeNAS, openSUSE installation media ...). Parted, fdisk, gdisk have functions to create a new MSDOS partition table, but they do not wipe the GPT completely. As the result, Grub2 functions (grub2-install, YaST Bootloader) fail. Currently I do "dd if=/dev/zero of=/dev/disk/by-id/<my-usb-key-device> bs=64M", but this takes long.)
$ man wipefs
cer@Telcontar:~> man wipefs | grep -i gpt cer@Telcontar:~>
On 05/07/2017 11:27 PM, Carlos E. R. wrote:
On 2017-05-07 18:00, Rüdiger Meier wrote:
On May 7, 2017 4:57:53 PM GMT+02:00, Bjoern Voigt bjoernv@arcor.de wrote:
What is the best way to wipe a GPT partition table completely from an USB key?
(Background: My USB key contains a GPT partition table, probably from an OS installation (FreeNAS, openSUSE installation media ...). Parted, fdisk, gdisk have functions to create a new MSDOS partition table, but they do not wipe the GPT completely. As the result, Grub2 functions (grub2-install, YaST Bootloader) fail. Currently I do "dd if=/dev/zero of=/dev/disk/by-id/<my-usb-key-device> bs=64M", but this takes long.)
$ man wipefs
cer@Telcontar:~> man wipefs | grep -i gpt cer@Telcontar:~>
Maybe just read it ...
cu, Rudi
On 2017-05-08 08:17, Rüdiger Meier wrote:
On 05/07/2017 11:27 PM, Carlos E. R. wrote:
$ man wipefs
cer@Telcontar:~> man wipefs | grep -i gpt cer@Telcontar:~>
Maybe just read it ...
What for? If it doesn't mention GPT specifically, it is no good. No, don't tell us to erase the entire disk: that will work but is terribly slow on an USB stick.
We need tools specific to erasing GPT tables.
If you know how to do that, tell us instead of telling us to peruse man pages without knowing what exactly to seek for.
On Monday 08 May 2017, Carlos E. R. wrote:
On 2017-05-08 08:17, Rüdiger Meier wrote:
On 05/07/2017 11:27 PM, Carlos E. R. wrote:
$ man wipefs
cer@Telcontar:~> man wipefs | grep -i gpt cer@Telcontar:~>
Maybe just read it ...
What for? If it doesn't mention GPT specifically, it is no good.
Does dd mention gpt specifically?
No, don't tell us to erase the entire disk: that will work but is terribly slow on an USB stick.
You have still not read the man page ...:
wipefs can erase filesystem, raid or *partition-table signatures* (magic strings) from the specified device to make the signatures invisible for libblkid.
wipefs *does not erase* the filesystem itself nor *any other data* from the device. When used without any options, wipefs lists all visible filesystems and the offsets of their basic signatures.
We need tools specific to erasing GPT tables.
wipefs can handle gpt and many other partition tables (GPT, MBR, Sun, SGI and BSD ) and even more. wipefs is exaclty the right tool to be used here. It's made for nothing else than such use cases like the OP posted. If it does not work then it would be a bug.
If you know how to do that, tell us instead of telling us to peruse man pages without knowing what exactly to seek for.
$ wipefs -fa /dev/sdX
Or just test it on a file:
$ truncate -s 100M /tmp/test.img $ echo -e "w\nY" | gdisk /tmp/test.img $ gdisk -l /tmp/test.img | grep -A4 "Partition table scan:" Partition table scan: MBR: protective BSD: not present APM: not present GPT: present
$ time wipefs -fa /tmp/test.img /tmp/test.img: 8 bytes were erased at offset 0x00000200 (gpt): 45 46 49. /tmp/test.img: 8 bytes were erased at offset 0x063ffe00 (gpt): 45 46 49. /tmp/test.img: 2 bytes were erased at offset 0x000001fe (PMBR): 55 aa ..
real 0m0.021s user 0m0.000s sys 0m0.002s
$ gdisk -l /tmp/test.img | grep -A4 "Partition table scan:" Partition table scan: MBR: not present BSD: not present APM: not present GPT: not present
As you see in wipefs output (offsets), it invalidates the GPT table, the backup GPT table and the (protective) MBR by writing 20 NULL bytes to the disk.
cu, Rudi
On Mon, May 8, 2017 at 7:42 AM, Ruediger Meier sweet_f_a@gmx.de wrote:
On Monday 08 May 2017, Carlos E. R. wrote:
On 2017-05-08 08:17, Rüdiger Meier wrote:
On 05/07/2017 11:27 PM, Carlos E. R. wrote:
$ man wipefs
cer@Telcontar:~> man wipefs | grep -i gpt cer@Telcontar:~>
Maybe just read it ...
What for? If it doesn't mention GPT specifically, it is no good.
Does dd mention gpt specifically?
No, don't tell us to erase the entire disk: that will work but is terribly slow on an USB stick.
You have still not read the man page ...:
wipefs can erase filesystem, raid or *partition-table signatures* (magic strings) from the specified device to make the signatures invisible for libblkid.
wipefs *does not erase* the filesystem itself nor *any other data* from the device. When used without any options, wipefs lists all visible filesystems and the offsets of their basic signatures.
We need tools specific to erasing GPT tables.
wipefs can handle gpt and many other partition tables (GPT, MBR, Sun, SGI and BSD ) and even more. wipefs is exaclty the right tool to be used here. It's made for nothing else than such use cases like the OP posted. If it does not work then it would be a bug.
If you know how to do that, tell us instead of telling us to peruse man pages without knowing what exactly to seek for.
$ wipefs -fa /dev/sdX
Or just test it on a file:
$ truncate -s 100M /tmp/test.img $ echo -e "w\nY" | gdisk /tmp/test.img $ gdisk -l /tmp/test.img | grep -A4 "Partition table scan:" Partition table scan: MBR: protective BSD: not present APM: not present GPT: present
$ time wipefs -fa /tmp/test.img /tmp/test.img: 8 bytes were erased at offset 0x00000200 (gpt): 45 46 49. /tmp/test.img: 8 bytes were erased at offset 0x063ffe00 (gpt): 45 46 49. /tmp/test.img: 2 bytes were erased at offset 0x000001fe (PMBR): 55 aa ..
real 0m0.021s user 0m0.000s sys 0m0.002s
$ gdisk -l /tmp/test.img | grep -A4 "Partition table scan:" Partition table scan: MBR: not present BSD: not present APM: not present GPT: not present
As you see in wipefs output (offsets), it invalidates the GPT table, the backup GPT table and the (protective) MBR by writing 20 NULL bytes to the disk.
Seeing that result, it is clear wipefs does the job.
Reading the man page, I had no certainty at all. It doesn't mention partition tables of any kind.
Greg
On 2017-05-08 15:45, Greg Freemyer wrote:
On Mon, May 8, 2017 at 7:42 AM, Ruediger Meier sweet_f_a@gmx.de wrote:
On Monday 08 May 2017, Carlos E. R. wrote:
On 2017-05-08 08:17, Rüdiger Meier wrote:
On 05/07/2017 11:27 PM, Carlos E. R. wrote:
$ man wipefs
cer@Telcontar:~> man wipefs | grep -i gpt cer@Telcontar:~>
Maybe just read it ...
What for? If it doesn't mention GPT specifically, it is no good.
Does dd mention gpt specifically?
No, don't tell us to erase the entire disk: that will work but is terribly slow on an USB stick.
You have still not read the man page ...:
wipefs can erase filesystem, raid or *partition-table signatures* (magic strings) from the specified device to make the signatures invisible for libblkid.
wipefs *does not erase* the filesystem itself nor *any other data* from the device. When used without any options, wipefs lists all visible filesystems and the offsets of their basic signatures.
We need tools specific to erasing GPT tables.
wipefs can handle gpt and many other partition tables (GPT, MBR, Sun, SGI and BSD ) and even more. wipefs is exaclty the right tool to be used here. It's made for nothing else than such use cases like the OP posted. If it does not work then it would be a bug.
If you know how to do that, tell us instead of telling us to peruse man pages without knowing what exactly to seek for.
$ wipefs -fa /dev/sdX
Or just test it on a file:
$ truncate -s 100M /tmp/test.img $ echo -e "w\nY" | gdisk /tmp/test.img $ gdisk -l /tmp/test.img | grep -A4 "Partition table scan:" Partition table scan: MBR: protective BSD: not present APM: not present GPT: present
$ time wipefs -fa /tmp/test.img /tmp/test.img: 8 bytes were erased at offset 0x00000200 (gpt): 45 46 49. /tmp/test.img: 8 bytes were erased at offset 0x063ffe00 (gpt): 45 46 49. /tmp/test.img: 2 bytes were erased at offset 0x000001fe (PMBR): 55 aa ..
real 0m0.021s user 0m0.000s sys 0m0.002s
$ gdisk -l /tmp/test.img | grep -A4 "Partition table scan:" Partition table scan: MBR: not present BSD: not present APM: not present GPT: not present
As you see in wipefs output (offsets), it invalidates the GPT table, the backup GPT table and the (protective) MBR by writing 20 NULL bytes to the disk.
Seeing that result, it is clear wipefs does the job.
Reading the man page, I had no certainty at all. It doesn't mention partition tables of any kind.
I did peruse the man page, but I didn't notice these things. Saving this email for future reference, thanks :-)
Carlos E. R. wrote:
On 2017-05-08 08:17, Rüdiger Meier wrote:
On 05/07/2017 11:27 PM, Carlos E. R. wrote:
$ man wipefs
cer@Telcontar:~> man wipefs | grep -i gpt cer@Telcontar:~>
Maybe just read it ...
What for? If it doesn't mention GPT specifically, it is no good.
That man page does not mention GPT nor DOS partition tables specifically, but it will erase both.
We need tools specific to erasing GPT tables.
Not really.
On 07/05/17 15:57, Bjoern Voigt wrote:
What is the best way to wipe a GPT partition table completely from an USB key?
(Background: My USB key contains a GPT partition table, probably from an OS installation (FreeNAS, openSUSE installation media ...). Parted, fdisk, gdisk have functions to create a new MSDOS partition table, but they do not wipe the GPT completely.
gdisk
*X*pert menu
*Z*ap gpt.
Cheers, Wol
Wols Lists wrote:
On 07/05/17 15:57, Bjoern Voigt wrote:
What is the best way to wipe a GPT partition table completely from an USB key?
(Background: My USB key contains a GPT partition table, probably from an OS installation (FreeNAS, openSUSE installation media ...). Parted, fdisk, gdisk have functions to create a new MSDOS partition table, but they do not wipe the GPT completely.
gdisk
*X*pert menu
*Z*ap gpt.
Thanks. But it probably does not work. I called "z zap (destroy) GPT data structures and exit", re-created a MSDOS partition table and re-inserted the USB key (so that Linux scans the new partition table). But gdisk still complains about an invalid GPT:
mybox:~ # gdisk /dev/disk/by-id/usb-General_UDisk_1502050001210883950005-0:0 GPT fdisk (gdisk) version 1.0.1
Partition table scan: MBR: MBR only BSD: not present APM: not present GPT: not present
*************************************************************** Found invalid GPT and valid MBR; converting MBR to GPT format in memory. THIS OPERATION IS POTENTIALLY DESTRUCTIVE! Exit by typing 'q' if you don't want to convert your MBR partitions to GPT format! ***************************************************************
Warning! Secondary partition table overlaps the last partition by 33 blocks! You will need to delete this partition or resize it in another utility.
Command (? for help): x
Expert command (? for help): z About to wipe out GPT on /dev/disk/by-id/usb-General_UDisk_1502050001210883950005-0:0. Proceed? (Y/N): y GPT data structures destroyed! You may now partition the disk using fdisk or other utilities. Blank out MBR? (Y/N): y mybox:~ # parted /dev/disk/by-id/usb-General_UDisk_1502050001210883950005-0:0 GNU Parted 3.2 Using /dev/sdc Welcome to GNU Parted! Type 'help' to view a list of commands. (parted) mklabel msdos (parted) quit Information: You may need to update /etc/fstab.
mybox:~ # sync [... manually re-inserted the USB key ...] mybox:~ # gdisk /dev/disk/by-id/usb-General_UDisk_1502050001210883950005-0:0 GPT fdisk (gdisk) version 1.0.1
Partition table scan: MBR: MBR only BSD: not present APM: not present GPT: not present
*************************************************************** Found invalid GPT and valid MBR; converting MBR to GPT format in memory. THIS OPERATION IS POTENTIALLY DESTRUCTIVE! Exit by typing 'q' if you don't want to convert your MBR partitions to GPT format! ***************************************************************
Command (? for help):
Greetings, Björn
On 07/05/17 20:00, Bjoern Voigt wrote:
Thanks. But it probably does not work. I called "z zap (destroy) GPT data structures and exit", re-created a MSDOS partition table and re-inserted the USB key (so that Linux scans the new partition table). But gdisk still complains about an invalid GPT:
mybox:~ # gdisk /dev/disk/by-id/usb-General_UDisk_1502050001210883950005-0:0 GPT fdisk (gdisk) version 1.0.1 Partition table scan: MBR: MBR only BSD: not present APM: not present GPT: not present
Where is it complaining about an *INVALID* GPT?
It's telling you there is no GPT present. (And, because its primary purpose is to edit GPT disks, not MBR disks, it tells you it is doing an "in memory" conversion to create a GPT)
So zap IS working as designed and documented.
Cheers, Wol
On 2017-05-07 22:38, Wols Lists wrote:
On 07/05/17 20:00, Bjoern Voigt wrote:
Thanks. But it probably does not work. I called "z zap (destroy) GPT data structures and exit", re-created a MSDOS partition table and re-inserted the USB key (so that Linux scans the new partition table). But gdisk still complains about an invalid GPT:
mybox:~ # gdisk /dev/disk/by-id/usb-General_UDisk_1502050001210883950005-0:0 GPT fdisk (gdisk) version 1.0.1 Partition table scan: MBR: MBR only BSD: not present APM: not present GPT: not presentWhere is it complaining about an *INVALID* GPT?
Just in the part you deleted from the post:
*************************************************************** Found invalid GPT and valid MBR; converting MBR to GPT format in memory. THIS OPERATION IS POTENTIALLY DESTRUCTIVE! Exit by typing 'q' if you don't want to convert your MBR partitions to GPT format! ***************************************************************
"Found invalid GPT", it says.
Carlos E. R. wrote:
On 2017-05-07 22:38, Wols Lists wrote:
On 07/05/17 20:00, Bjoern Voigt wrote:
Thanks. But it probably does not work. I called "z zap (destroy) GPT data structures and exit", re-created a MSDOS partition table and re-inserted the USB key (so that Linux scans the new partition table). But gdisk still complains about an invalid GPT:
mybox:~ # gdisk /dev/disk/by-id/usb-General_UDisk_1502050001210883950005-0:0 GPT fdisk (gdisk) version 1.0.1 Partition table scan: MBR: MBR only BSD: not present APM: not present GPT: not presentWhere is it complaining about an *INVALID* GPT?
Just in the part you deleted from the post:
*************************************************************** Found invalid GPT and valid MBR; converting MBR to GPT format in memory. THIS OPERATION IS POTENTIALLY DESTRUCTIVE! Exit by typing 'q' if you don't want to convert your MBR partitions to GPT format! ***************************************************************"Found invalid GPT", it says.
I tried the test case from Ruediger Meier both with "wipefs" and with "gdisk". Both commands clean the GPT headers completely. The "Found invalid GPT" message does not appear later. So at least for the test case (no real USB key is used, but an big empty file) both commands work correctly. But "gdisk" (wipefs not tested) did not clean my GPT header on the real 8 GB big USB key. I do not know the reason. On reason could be, that the GPT in the USB key is not created by "parted" or "gdisk", but created with imagewriter and the installation media openSUSE-Leap-42.2-DVD-x86_64.iso (and other installation media files).
Greetings, Björn
On Tuesday 09 May 2017, Bjoern Voigt wrote:
Carlos E. R. wrote:
On 2017-05-07 22:38, Wols Lists wrote:
On 07/05/17 20:00, Bjoern Voigt wrote:
Thanks. But it probably does not work. I called "z zap (destroy) GPT data structures and exit", re-created a MSDOS partition table and re-inserted the USB key (so that Linux scans the new partition table). But gdisk still complains about an invalid GPT:
mybox:~ # gdisk /dev/disk/by-id/usb-General_UDisk_1502050001210883950005-0:0 GPT fdisk (gdisk) version 1.0.1 Partition table scan: MBR: MBR only BSD: not present APM: not present GPT: not presentWhere is it complaining about an *INVALID* GPT?
Just in the part you deleted from the post:
*************************************************************** Found invalid GPT and valid MBR;
I would say you have both MBR and GPT partition table. In this case MBR wins I would say, by means the operating system uses the MBR.
converting MBR to GPT format
in memory. THIS OPERATION IS POTENTIALLY DESTRUCTIVE! Exit by typing 'q' if you don't want to convert your MBR partitions to GPT format! ***************************************************************"Found invalid GPT", it says.
I tried the test case from Ruediger Meier both with "wipefs" and with "gdisk". Both commands clean the GPT headers completely. The "Found invalid GPT" message does not appear later. So at least for the test case (no real USB key is used, but an big empty file) both commands work correctly. But "gdisk" (wipefs not tested) did not clean my GPT header on the real 8 GB big USB key.
Why not try wipefs?
I do not know the reason. On reason could be, that the GPT in the USB key is not created by "parted" or "gdisk", but created with imagewriter and the installation media
I guess originally there was a valid GPT table on that device. Then you used a tool which does *not* support GPT. Thus it created a conflicting MBR. Now gdisk and any other tools with GPT support will complain.
Using gdisk you would have to repair the GPT table first and then remove it.
But again, I think wipefs would clear both MBR and GPT regardless whether they are valid or not.
cu, Rudi
On 05/07/2017 02:00 PM, Bjoern Voigt wrote:
*************************************************************** Found invalid GPT and valid MBR; converting MBR to GPT format in memory. THIS OPERATION IS POTENTIALLY DESTRUCTIVE! Exit by typing 'q' if you don't want to convert your MBR partitions to GPT format! ***************************************************************
I have often seen that message. But never after the "zap" in "gdisk".
There's also a "fixparts" command (package "gptfdisk-fixparts") but I suppose that is by the authors of "gdisk".
On 07/05/17 22:53, Neil Rickert wrote:
On 05/07/2017 02:00 PM, Bjoern Voigt wrote:
*************************************************************** Found invalid GPT and valid MBR; converting MBR to GPT format in memory. THIS OPERATION IS POTENTIALLY DESTRUCTIVE! Exit by typing 'q' if you don't want to convert your MBR partitions to GPT format! ***************************************************************I have often seen that message. But never after the "zap" in "gdisk".
There's also a "fixparts" command (package "gptfdisk-fixparts") but I suppose that is by the authors of "gdisk".
Thing is (and what I presume they mean here) "invalid" can also mean "non-existent". If you're not a native English speaker - and even if you are - this can be confusing.
To me, it's clear. There is no GPT, and it's warning you that if you save to disk it will create one.
The first bit tells you that there is no gpt. The second bit tells you that because it can't find a valid gpt (because it doesn't exist) it is creating one for you.
Cheers, Wol
Le 08/05/2017 à 07:45, Wols Lists a écrit :
To me, it's clear. There is no GPT, and it's warning you that if you save to disk it will create one.
and to go ahead, use fdisk, not gdisk...
jdd :-)
On 2017-05-08 07:45, Wols Lists wrote:
On 07/05/17 22:53, Neil Rickert wrote:
Thing is (and what I presume they mean here) "invalid" can also mean "non-existent". If you're not a native English speaker - and even if you are - this can be confusing.
Huh.
To me, it's clear. There is no GPT, and it's warning you that if you save to disk it will create one.
The first bit tells you that there is no gpt. The second bit tells you that because it can't find a valid gpt (because it doesn't exist) it is creating one for you.
If there is no GPT main table but there is a backup table at the end of the disk, it could also say that there is no GPT table, and that it is invalid.
Very confusing wording.
On 08/05/17 06:49 AM, Carlos E. R. wrote:
Very confusing wording.
Often brevity *IS* confusing. We once had a manager like that. We never did break him of that dereliction.
Hello,
On Sun, 07 May 2017, Bjoern Voigt wrote:
Wols Lists wrote:
On 07/05/17 15:57, Bjoern Voigt wrote:
What is the best way to wipe a GPT partition table completely from an USB key?
(Background: My USB key contains a GPT partition table, probably from an OS installation (FreeNAS, openSUSE installation media ...). Parted, fdisk, gdisk have functions to create a new MSDOS partition table, but they do not wipe the GPT completely.
gdisk
*X*pert menu
*Z*ap gpt.
Thanks. But it probably does not work. I called "z zap (destroy) GPT data structures and exit", re-created a MSDOS partition table and re-inserted the USB key (so that Linux scans the new partition table). But gdisk still complains about an invalid GPT:
Wrong.
$ dd if=/dev/zero of=./t.img bs=1M count=200 $ gdisk ./t.img [..] Command (? for help): n Partition number (1-128, default 1): First sector (34-409566, default = 2048) or {+-}size{KMGTP}: Last sector (2048-409566, default = 409566) or {+-}size{KMGTP}: Current type is 'Linux filesystem' Hex code or GUID (L to show codes, Enter = 8300): Changed type of partition to 'Linux filesystem'
Command (? for help): v
No problems found. 2014 free sectors (1007.0 KiB) available in 1 segments, the largest of which is 2014 (1007.0 KiB) in size.
Command (? for help): w Final checks complete. About to write GPT data. THIS WILL OVERWRITE EXISTING PARTITIONS!!
Do you want to proceed? (Y/N): y OK; writing new GUID partition table (GPT) to ./t.img. Warning: The kernel is still using the old partition table. The new table will be used at the next reboot. The operation has completed successfully. $ od -tx1z ./t.img 0000000 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 >................< * 0000700 02 00 ee 7e 25 19 01 00 00 00 ff 3f 06 00 00 00 >..î~%.....ÿ?....< 0000720 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 >................< * 0000760 00 00 00 00 00 00 00 00 00 00 00 00 00 00 55 aa >..............Uª< 0001000 45 46 49 20 50 41 52 54 00 00 01 00 5c 00 00 00 >EFI PART.......< [..] 1437777000 45 46 49 20 50 41 52 54 00 00 01 00 5c 00 00 00 >EFI PART.......< 1437777020 ec be a7 c4 00 00 00 00 ff 3f 06 00 00 00 00 00 >쟧Ä....ÿ?......< 1437777040 01 00 00 00 00 00 00 00 22 00 00 00 00 00 00 00 >........".......< 1437777060 de 3f 06 00 00 00 00 00 75 f6 ca 04 f9 25 d7 4c >Þ?......uöÊ.ù%×L< 1437777100 80 52 5f fe a2 0c 8b 6b df 3f 06 00 00 00 00 00 >.R_þ¢..kß?......< 1437777120 80 00 00 00 80 00 00 00 83 f4 bb dd 00 00 00 00 >.........ô»Ý....< 1437777140 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 >................< * 1440000000 $ gdisk ./t.img GPT fdisk (gdisk) version 0.8.10
Partition table scan: MBR: protective BSD: not present APM: not present GPT: present
Found valid GPT with protective MBR; using GPT.
Command (? for help): x Expert command (? for help): z About to wipe out GPT on ./t.img. Proceed? (Y/N): y Warning: The kernel is still using the old partition table. The new table will be used at the next reboot. GPT data structures destroyed! You may now partition the disk using fdisk or other utilities. Blank out MBR? (Y/N): y $ od -tx1z ./t.img 0000000 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 >................< * 1440000000
So there's NOTHING but zeroes left.
$ gdisk ./t.img GPT fdisk (gdisk) version 0.8.10
Partition table scan: MBR: not present BSD: not present APM: not present GPT: not present
Creating new GPT entries.
Command (? for help): q $
HTH, -dnh
The most simple way to do it is use gparted and write a new partition table, the type of table you want.
Op 07-05-17 16:57, Bjoern Voigt schreef:
What is the best way to wipe a GPT partition table completely from an USB key?
(Background: My USB key contains a GPT partition table, probably from an OS installation (FreeNAS, openSUSE installation media ...). Parted, fdisk, gdisk have functions to create a new MSDOS partition table, but they do not wipe the GPT completely. As the result, Grub2 functions (grub2-install, YaST Bootloader) fail. Currently I do "dd if=/dev/zero of=/dev/disk/by-id/<my-usb-key-device> bs=64M", but this takes long.)
Greetings, Björn
-
Anton Aylward -
Bjoern Voigt -
Carlos E. R. -
David Haller -
Greg Freemyer -
Hans de Faber -
jdd＠dodin.org -
Knurpht - Gertjan Lettink -
Neil Rickert -
Per Jessen -
Ruediger Meier -
Rüdiger Meier
-
Wols Lists