7 May
2017
7 May
'17
4:57 p.m.
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
--
To unsubscribe, e-mail: opensuse+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse+owner(a)opensuse.org
7 May
7 May
5:05 p.m.
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
--
To unsubscribe, e-mail: opensuse+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse+owner(a)opensuse.org
5:27 p.m.
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.
--
To unsubscribe, e-mail: opensuse+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse+owner(a)opensuse.org
5:33 p.m.
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
--
To unsubscribe, e-mail: opensuse+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse+owner(a)opensuse.org
5:49 p.m.
Knurpht - Gertjan Lettink wrote:
Op zondag 7 mei 2017 16:57:53 CEST schreef Bjoern
Voigt:
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.
--
Per Jessen, Zürich (12.9°C)
http://www.dns24.ch/ - your free DNS host, made in Switzerland.
--
To unsubscribe, e-mail: opensuse+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse+owner(a)opensuse.org
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. 
6 p.m.
On May 7, 2017 4:57:53 PM GMT+02:00, Bjoern Voigt <bjoernv(a)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
--
Sent from my Android device with K-9 Mail. Please excuse my brevity.
--
To unsubscribe, e-mail: opensuse+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse+owner(a)opensuse.org
11:27 p.m.
On 2017-05-07 18:00, Rüdiger Meier wrote:
On May 7, 2017 4:57:53 PM GMT+02:00, Bjoern Voigt <bjoernv(a)arcor.de> wrote:
cer@Telcontar:~> man wipefs | grep -i gpt
cer@Telcontar:~>
--
Cheers / Saludos,
Carlos E. R.
(from 42.2 x86_64 "Malachite" at Telcontar)
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
8 May
8 May
8:17 a.m.
On 05/07/2017 11:27 PM, Carlos E. R. wrote:
On 2017-05-07 18:00, Rüdiger Meier wrote:
Maybe just read it ...
cu,
Rudi
--
To unsubscribe, e-mail: opensuse+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse+owner(a)opensuse.org
On May 7, 2017 4:57:53 PM GMT+02:00, Bjoern Voigt <bjoernv(a)arcor.de> wrote:
cer@Telcontar:~> man wipefs | grep -i gpt
cer@Telcontar:~> 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
12:42 p.m.
On 2017-05-08 08:17, Rüdiger Meier wrote:
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.
--
Cheers / Saludos,
Carlos E. R.
(from 42.2 x86_64 "Malachite" at Telcontar)
On 05/07/2017 11:27 PM, Carlos E. R. wrote:
$ man wipefs
cer@Telcontar:~> man wipefs | grep -i gpt
cer@Telcontar:~>
1:42 p.m.
On Monday 08 May 2017, Carlos E. R. wrote:
On 2017-05-08 08:17, Rüdiger Meier wrote:
Does dd mention gpt specifically?
On 05/07/2017 11:27 PM, Carlos E. R. wrote:
Maybe just read it ...
What for? If it doesn't mention GPT specifically, it is no good. $ man
wipefs
cer@Telcontar:~> man wipefs | grep -i gpt
cer@Telcontar:~> 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
--
To unsubscribe, e-mail: opensuse+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse+owner(a)opensuse.org
3:45 p.m.
On Mon, May 8, 2017 at 7:42 AM, Ruediger Meier <sweet_f_a(a)gmx.de> wrote:
On Monday 08 May 2017, Carlos E. R. wrote:
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
--
To unsubscribe, e-mail: opensuse+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse+owner(a)opensuse.org
On 2017-05-08 08:17, Rüdiger Meier wrote:
Does dd mention gpt specifically?
On 05/07/2017 11:27 PM, Carlos E. R. wrote:
What for? If it doesn't mention GPT specifically, it is no good. > $ man wipefs
cer@Telcontar:~> man wipefs | grep -i gpt
cer@Telcontar:~>
Maybe just read it ... 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.
2 Jun
2 Jun
7:35 p.m.
On 2017-05-08 15:45, Greg Freemyer wrote:
On Mon, May 8, 2017 at 7:42 AM, Ruediger Meier
<sweet_f_a(a)gmx.de> wrote:
I did peruse the man page, but I didn't notice these things. Saving this
email for future reference, thanks :-)
--
Cheers / Saludos,
Carlos E. R.
(from 42.2 x86_64 "Malachite" (Minas Tirith))
On Monday 08 May 2017, Carlos E. R. wrote:
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. On 2017-05-08 08:17, Rüdiger Meier wrote:
Does dd mention gpt specifically?
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.
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.
8 May
8 May
2:06 p.m.
Carlos E. R. wrote:
On 2017-05-08 08:17, Rüdiger Meier wrote:
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.
On 05/07/2017 11:27 PM, Carlos E. R. wrote:
$ man wipefs
cer@Telcontar:~> man wipefs | grep -i gpt
cer@Telcontar:~> We need tools specific to erasing GPT tables.
Not really.
--
Per Jessen, Zürich (11.2°C)
http://www.hostsuisse.com/ - virtual servers, made in Switzerland.
--
To unsubscribe, e-mail: opensuse+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse+owner(a)opensuse.org
7 May
7 May
6:53 p.m.
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
--
To unsubscribe, e-mail: opensuse+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse+owner(a)opensuse.org
9 p.m.
Wols Lists wrote:
On 07/05/17 15:57, 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
***************************************************************
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
--
To unsubscribe, e-mail: opensuse+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse+owner(a)opensuse.org
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.
10:38 p.m.
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
--
To unsubscribe, e-mail: opensuse+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse+owner(a)opensuse.org
11:31 p.m.
On 2017-05-07 22:38, Wols Lists wrote:
On 07/05/17 20:00, Bjoern Voigt wrote:
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.
--
Cheers / Saludos,
Carlos E. R.
(from 42.2 x86_64 "Malachite" at Telcontar)
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?
9 May
9 May
9:11 p.m.
Carlos E. R. wrote:
On 2017-05-07 22:38, Wols Lists wrote:
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
--
To unsubscribe, e-mail: opensuse+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse+owner(a)opensuse.org
On 07/05/17 20:00, Bjoern Voigt wrote:
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. 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?
10 May
10 May
noon
On Tuesday 09 May 2017, Bjoern Voigt wrote:
Why not try wipefs?
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 present
>>
>> Where 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. 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
--
To unsubscribe, e-mail: opensuse+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse+owner(a)opensuse.org
7 May
7 May
11:53 p.m.
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".
--
To unsubscribe, e-mail: opensuse+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse+owner(a)opensuse.org
8 May
8 May
7:45 a.m.
On 07/05/17 22:53, Neil Rickert wrote:
On 05/07/2017 02:00 PM, Bjoern Voigt 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.
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
--
To unsubscribe, e-mail: opensuse+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse+owner(a)opensuse.org
***************************************************************
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".
7:47 a.m.
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 :-)
--
To unsubscribe, e-mail: opensuse+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse+owner(a)opensuse.org
12:49 p.m.
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.
--
Cheers / Saludos,
Carlos E. R.
(from 42.2 x86_64 "Malachite" at Telcontar)
9 May
9 May
1:41 p.m.
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.
--
A: Yes.
Q: Are you sure?
> A: Because it reverses the logical flow of conversation.
>> Q: Why is top posting frowned upon?
--
To unsubscribe, e-mail: opensuse+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse+owner(a)opensuse.org
8 May
8 May
7:01 p.m.
Hello,
On Sun, 07 May 2017, Bjoern Voigt wrote:
Wols Lists wrote:
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
--
printk(" Speed now 1x"); /* Pull my finger! */
linux-2.6.6/drivers/cdrom/mcd.c
--
To unsubscribe, e-mail: opensuse+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse+owner(a)opensuse.org
On 07/05/17 15:57, 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: 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. 
2:51 p.m.
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
--
To unsubscribe, e-mail: opensuse+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse+owner(a)opensuse.org
1333
days inactive
1359
days old
25 comments
13 participants
participants (13)
-
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