How to safely remove rest of GTP?

[Slawa Olhovchenkov]

How to safely remove rest of GPT?
Disk have actual data (part of ZFS), I am don't need to destroy this
data.

GEOM: da6: the primary GPT table is corrupt or invalid.
GEOM: da6: using the secondary instead -- recovery strongly advised.
GEOM: da22: the primary GPT table is corrupt or invalid.
GEOM: da22: using the secondary instead -- recovery strongly advised.
GEOM: da6: the primary GPT table is corrupt or invalid.
GEOM: da6: using the secondary instead -- recovery strongly advised.
GEOM: da22: the primary GPT table is corrupt or invalid.
GEOM: da22: using the secondary instead -- recovery strongly advised.

_______________________________________________
freebsd...@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hacke...@freebsd.org"

[Alan Somers]

On Fri, Dec 30, 2016 at 5:44 AM, Slawa Olhovchenkov <s...@zxy.spb.ru> wrote:
> How to safely remove rest of GPT?
> Disk have actual data (part of ZFS), I am don't need to destroy this
> data.
>
> GEOM: da6: the primary GPT table is corrupt or invalid.
> GEOM: da6: using the secondary instead -- recovery strongly advised.
> GEOM: da22: the primary GPT table is corrupt or invalid.
> GEOM: da22: using the secondary instead -- recovery strongly advised.
> GEOM: da6: the primary GPT table is corrupt or invalid.
> GEOM: da6: using the secondary instead -- recovery strongly advised.
> GEOM: da22: the primary GPT table is corrupt or invalid.
> GEOM: da22: using the secondary instead -- recovery strongly advised.

It sounds like you created a GPT partition table, then created a ZFS
Pool on the raw device, leaving part of the GPT partition table
hanging around. If you're very careful, you can use dd to erase the
GPT partition table. The following command worked for me. YMMV.

dd if=/dev/zero of=/dev/vtbd1 bs=8192 count=2

-Alan

[Andrey Fesenko]

On Fri, Dec 30, 2016 at 7:00 PM, Alan Somers <aso...@freebsd.org> wrote:
> On Fri, Dec 30, 2016 at 5:44 AM, Slawa Olhovchenkov <s...@zxy.spb.ru> wrote:
>> How to safely remove rest of GPT?
>> Disk have actual data (part of ZFS), I am don't need to destroy this
>> data.
>>
>> GEOM: da6: the primary GPT table is corrupt or invalid.
>> GEOM: da6: using the secondary instead -- recovery strongly advised.
>> GEOM: da22: the primary GPT table is corrupt or invalid.
>> GEOM: da22: using the secondary instead -- recovery strongly advised.
>> GEOM: da6: the primary GPT table is corrupt or invalid.
>> GEOM: da6: using the secondary instead -- recovery strongly advised.
>> GEOM: da22: the primary GPT table is corrupt or invalid.
>> GEOM: da22: using the secondary instead -- recovery strongly advised.
>
>

> dd if=/dev/zero of=/dev/vtbd1 bs=8192 count=2
>

>> secondary instead

It's last sector on the disk

[Andrey V. Elsukov]

On 30.12.2016 15:44, Slawa Olhovchenkov wrote:
> How to safely remove rest of GPT?
> Disk have actual data (part of ZFS), I am don't need to destroy this
> data.
>
> GEOM: da6: the primary GPT table is corrupt or invalid.
> GEOM: da6: using the secondary instead -- recovery strongly advised.
> GEOM: da22: the primary GPT table is corrupt or invalid.
> GEOM: da22: using the secondary instead -- recovery strongly advised.
> GEOM: da6: the primary GPT table is corrupt or invalid.
> GEOM: da6: using the secondary instead -- recovery strongly advised.
> GEOM: da22: the primary GPT table is corrupt or invalid.
> GEOM: da22: using the secondary instead -- recovery strongly advised.

You may try attached patch, I did only basic tests, so first try
somewhere :)

--
WBR, Andrey V. Elsukov

[Ian Lepore]

On Fri, 2016-12-30 at 15:44 +0300, Slawa Olhovchenkov wrote:
> How to safely remove rest of GPT?
> Disk have actual data (part of ZFS), I am don't need to destroy this
> data.
>
> GEOM: da6: the primary GPT table is corrupt or invalid.
> GEOM: da6: using the secondary instead -- recovery strongly advised.
> GEOM: da22: the primary GPT table is corrupt or invalid.
> GEOM: da22: using the secondary instead -- recovery strongly advised.
> GEOM: da6: the primary GPT table is corrupt or invalid.
> GEOM: da6: using the secondary instead -- recovery strongly advised.
> GEOM: da22: the primary GPT table is corrupt or invalid.
> GEOM: da22: using the secondary instead -- recovery strongly advised.
>

You need to zero out the backup gpt header.  Geom locates that header
using (mediasize / sectorsize) - 1.  I think mediasize/sectorsize is
exactly what's displayed by diskinfo -v as "mediasize in sectors", so
that number - 1 would be lastsector in:

 dd if=/dev/zero of=/dev/da6 bs=<sectorsize> oseek=<lastsector> count=1

-- Ian

[Slawa Olhovchenkov]

What purpose of this patch?

> --
> WBR, Andrey V. Elsukov

> Index: sys/geom/part/g_part_gpt.c
> ===================================================================
> --- sys/geom/part/g_part_gpt.c (revision 310784)
> +++ sys/geom/part/g_part_gpt.c (working copy)
> @@ -690,7 +690,8 @@ g_part_gpt_destroy(struct g_part_table *basetable,
> * Wipe the first 2 sectors to clear the partitioning. Wipe the last
> * sector only if it has valid secondary header.
> */
> - basetable->gpt_smhead |= 3;
> + if (table->state[GPT_ELT_PRIHDR] == GPT_STATE_OK)
> + basetable->gpt_smhead |= 3;
> if (table->state[GPT_ELT_SECHDR] == GPT_STATE_OK &&
> table->lba[GPT_ELT_SECHDR] == pp->mediasize / pp->sectorsize - 1)
> basetable->gpt_smtail |= 1;

[Andrey V. Elsukov]

On 30.12.2016 19:46, Slawa Olhovchenkov wrote:
> On Fri, Dec 30, 2016 at 07:28:19PM +0300, Andrey V. Elsukov wrote:
>
>> On 30.12.2016 15:44, Slawa Olhovchenkov wrote:
>>> How to safely remove rest of GPT?
>>> Disk have actual data (part of ZFS), I am don't need to destroy this
>>> data.
>>>
>>> GEOM: da6: the primary GPT table is corrupt or invalid.
>>> GEOM: da6: using the secondary instead -- recovery strongly advised.
>>> GEOM: da22: the primary GPT table is corrupt or invalid.
>>> GEOM: da22: using the secondary instead -- recovery strongly advised.
>>> GEOM: da6: the primary GPT table is corrupt or invalid.
>>> GEOM: da6: using the secondary instead -- recovery strongly advised.
>>> GEOM: da22: the primary GPT table is corrupt or invalid.
>>> GEOM: da22: using the secondary instead -- recovery strongly advised.
>>
>> You may try attached patch, I did only basic tests, so first try
>> somewhere :)
>
> What purpose of this patch?

In case when you have not valid primary header, `gpart destroy` will not
touch first two sectors. In you case you can wipe only last sector, like
Ian suggested, but use 'gpart destroy -F da6' instead of dd.

--
WBR, Andrey V. Elsukov

[Ian Lepore]

If you gpart destroy -F da6 won't that also clear the valid MBR at the
start of the disk?  I think Slawa needs to preserve that.

I think it would be really useful if gpart recover could help with this
somehow.  There is a valid mbr, and a partially-valid gpt (only the
backup is valid).  So gpart recover should provide a way to recover the
gpt by refreshing the primary gpt and the pbmr, or recover the mbr by
wiping the backup gpt.  I'm not sure what the syntax would be to
specify that, though.

This didn't used to be a problem until the changes that made the backup
gpt get used automatically without any sysadmin intervention.

-- Ian

[Slawa Olhovchenkov]

I am don't have any partition scheme on disk -- whole disk for ZFS.
May be someone use some scheme before, on other server, before insert.
I am don't need it.

> I think it would be really useful if gpart recover could help with this
> somehow.  There is a valid mbr, and a partially-valid gpt (only the
> backup is valid).  So gpart recover should provide a way to recover the
> gpt by refreshing the primary gpt and the pbmr, or recover the mbr by
> wiping the backup gpt.  I'm not sure what the syntax would be to
> specify that, though.
>
> This didn't used to be a problem until the changes that made the backup
> gpt get used automatically without any sysadmin intervention.

This is other case, but may be usefull too.

[Andrey V. Elsukov]

On 30.12.2016 20:37, Ian Lepore wrote:
>> In case when you have not valid primary header, `gpart destroy` will
>> not
>> touch first two sectors. In you case you can wipe only last sector,
>> like
>> Ian suggested, but use 'gpart destroy -F da6' instead of dd.
>>
>
> If you gpart destroy -F da6 won't that also clear the valid MBR at the
> start of the disk? I think Slawa needs to preserve that.

As I said, it will not touch first two sectors, where PMBR and primary
GPT headers are.

> I think it would be really useful if gpart recover could help with this
> somehow. There is a valid mbr, and a partially-valid gpt (only the
> backup is valid). So gpart recover should provide a way to recover the
> gpt by refreshing the primary gpt and the pbmr,

`gpart recover` will restore GPT using information from backup header
and table and construct new PMBR. After that you need to write bootcode
if needed.

> or recover the mbr by
> wiping the backup gpt.

This is what the patch does. You need to use `gpart destroy -F` to
CORRUPTED GPT, this command will wipe last sector where GPT backup
header is located. Since GPT is in CORRUPT state, the primary header
will not be overwrited by this command.

When both primary and backup headers and tables are valid, `gpart
destroy` overwites PMBR, primary and backup headers.

> I'm not sure what the syntax would be to
> specify that, though.
>
> This didn't used to be a problem until the changes that made the backup
> gpt get used automatically without any sysadmin intervention.

For some users the problem was that they could not find their GPT, that
declares its reliability.

--
WBR, Andrey V. Elsukov

[Ian Lepore]

Do you seriously believe that people are going to just do a gpart
destroy -F on a device with a valid MBR as a method of preserving that
mbr?  If that's the kind of thinking behind the gpart interface, I
guess that helps explain why it's so nearly impossible to understand
and use already.

-- Ian

[Andrey V. Elsukov]

On 30.12.2016 22:02, Ian Lepore wrote:
>
> Do you seriously believe that people are going to just do a gpart
> destroy -F on a device with a valid MBR as a method of preserving that
> mbr? If that's the kind of thinking behind the gpart interface, I
> guess that helps explain why it's so nearly impossible to understand
> and use already.

People, who have valid MBR will never see messages about corrupt GPT.

--
WBR, Andrey V. Elsukov

[Warren Block]

I really like the idea of gpart being able to remove the secondary GPT,
but combining it with the existing destroy command is ambiguous. It's
hard for the user to tell what will happen, and the command itself
implies that it will destroy all partitioning.

A different command or option name, maybe, but it's hard to think of a
good name on a Monday morning. Certainly the problem of stale secondary
GPTs comes up a lot.

[Andrey V. Elsukov]

On 30.01.2017 18:55, Warren Block wrote:
>>> GEOM: da6: the primary GPT table is corrupt or invalid.
>>> GEOM: da6: using the secondary instead -- recovery strongly advised.
>>> GEOM: da22: the primary GPT table is corrupt or invalid.
>>> GEOM: da22: using the secondary instead -- recovery strongly advised.
>>> GEOM: da6: the primary GPT table is corrupt or invalid.
>>> GEOM: da6: using the secondary instead -- recovery strongly advised.
>>> GEOM: da22: the primary GPT table is corrupt or invalid.
>>> GEOM: da22: using the secondary instead -- recovery strongly advised.
>>
>> You may try attached patch, I did only basic tests, so first try
>> somewhere :)
>
> I really like the idea of gpart being able to remove the secondary GPT,
> but combining it with the existing destroy command is ambiguous. It's
> hard for the user to tell what will happen, and the command itself
> implies that it will destroy all partitioning.

I don't see any ambiguity here. A user sees corrupted GPT, it can only
destroy or recover it. It is impossible to have a corrupted GPT and some
other type of partition table in the same time. So, if you use 'gpart
destroy' - you want to explicitly destroy it.

--
WBR, Andrey V. Elsukov

[Ian Lepore]

The question to ask here is why are you the only one who can't see or
understand that a user is NOT going to use a "destroy" command on a
 disk containing live data?  Especially given the confusing vagueness
of the gpart docs.

-- Ian

[Allan Jude]

On my todo list for a while, has been a gpart command to clear the first
and last 1MB of a disk. To remove whatever happens to be there: MBR,
GPT, ZFS Labels, whatever.

Just 'nuke it from orbit'.

gpart zero ada0

or gpart clear ada0

something to that affect.

--
Allan Jude

[Andrey V. Elsukov]

On 30.01.2017 20:23, Ian Lepore wrote:
>> other type of partition table in the same time. So, if you use
>> 'gpart
>> destroy' - you want to explicitly destroy it.
>>
>
> The question to ask here is why are you the only one who can't see or
> understand that a user is NOT going to use a "destroy" command on a
> disk containing live data? Especially given the confusing vagueness
> of the gpart docs.

Because I have read the docs and understood them? Did you tried do that
instead of attacking me each time, when geom/gpart is discussed? I'm
even not an author of this. If you don't like the existing
documentation, the sources are open, read them and write better
documentation.

--
WBR, Andrey V. Elsukov

[Ian Lepore]

On Tue, 2017-01-31 at 00:33 +0300, Andrey V. Elsukov wrote:
> On 30.01.2017 20:23, Ian Lepore wrote:
> >
> > >
> > > other type of partition table in the same time. So, if you use
> > > 'gpart
> > > destroy' - you want to explicitly destroy it.
> > >
> > The question to ask here is why are you the only one who can't see
> > or
> > understand that a user is NOT going to use a "destroy" command on a
> >  disk containing live data?  Especially given the confusing
> > vagueness
> > of the gpart docs.
> Because I have read the docs and understood them? Did you tried do
> that 
> instead of attacking me each time, when geom/gpart is discussed? I'm 
> even not an author  of this. If you don't like the existing 
> documentation, the sources are open, read them and write better 
> documentation.
>

Every time someone says they can't understand how to do something with
gpart, you imply that the problem is all theirs, because the
documentation is clear.  The documentation is NOT clear, and every time
you say so, I'm going to point out it is not.

-- Ian

[Andrey V. Elsukov]

On 31.01.2017 00:37, Ian Lepore wrote:
>> instead of attacking me each time, when geom/gpart is discussed? I'm
>> even not an author of this. If you don't like the existing
>> documentation, the sources are open, read them and write better
>> documentation.
>>
>
> Every time someone says they can't understand how to do something with
> gpart, you imply that the problem is all theirs, because the
> documentation is clear. The documentation is NOT clear, and every time
> you say so, I'm going to point out it is not.

Of course, it is very useful action. Instead of fixing the documentation
you say to me that is not clear. To me, who understand it and doesn't
see what is not clear.

--
WBR, Andrey V. Elsukov

[Ian Lepore]

On Tue, 2017-01-31 at 01:00 +0300, Andrey V. Elsukov wrote:
> On 31.01.2017 00:37, Ian Lepore wrote:
> > >
> > > instead of attacking me each time, when geom/gpart is discussed?
> > > I'm
> > > even not an author  of this. If you don't like the existing
> > > documentation, the sources are open, read them and write better
> > > documentation.
> > >
> > Every time someone says they can't understand how to do something
> > with
> > gpart, you imply that the problem is all theirs, because the
> > documentation is clear.  The documentation is NOT clear, and every
> > time
> > you say so, I'm going to point out it is not.
> Of course, it is very useful action. Instead of fixing the
> documentation 
> you say to me that is not clear. To me, who understand it and
> doesn't 
> see what is not clear.
>

It's really not rocket science:  as long as you keep telling people
that they are the problem, I'm going to keep pointing out that they are
not the problem, and that their confusion is the same as other people
are having.

-- Ian

[Andrey V. Elsukov]

On 31.01.2017 01:09, Ian Lepore wrote:
>> Of course, it is very useful action. Instead of fixing the
>> documentation
>> you say to me that is not clear. To me, who understand it and
>> doesn't
>> see what is not clear.
>>
>
> It's really not rocket science: as long as you keep telling people
> that they are the problem, I'm going to keep pointing out that they are
> not the problem, and that their confusion is the same as other people
> are having.

Ok, I can just ignore such questions and don't answer. You will continue
suggest to use dd(1). Documentation will remain the same. All will be
happy. Is it right?

--
WBR, Andrey V. Elsukov

[Warren Block]

On Mon, 30 Jan 2017, Andrey V. Elsukov wrote:

> On 30.01.2017 18:55, Warren Block wrote:
>>>> GEOM: da6: the primary GPT table is corrupt or invalid.
>>>> GEOM: da6: using the secondary instead -- recovery strongly advised.
>>>> GEOM: da22: the primary GPT table is corrupt or invalid.
>>>> GEOM: da22: using the secondary instead -- recovery strongly advised.
>>>> GEOM: da6: the primary GPT table is corrupt or invalid.
>>>> GEOM: da6: using the secondary instead -- recovery strongly advised.
>>>> GEOM: da22: the primary GPT table is corrupt or invalid.
>>>> GEOM: da22: using the secondary instead -- recovery strongly advised.
>>>
>>> You may try attached patch, I did only basic tests, so first try
>>> somewhere :)
>>
>> I really like the idea of gpart being able to remove the secondary GPT,
>> but combining it with the existing destroy command is ambiguous. It's
>> hard for the user to tell what will happen, and the command itself
>> implies that it will destroy all partitioning.
>
> I don't see any ambiguity here. A user sees corrupted GPT, it can only
> destroy or recover it.

Ah, but the user might not even see it. "I wrote an MBR to my disk
(with some other software) and now FreeBSD says it has a corrupted GPT."

In this case, it can have a valid MBR which the user does not want to
destroy. So re-using the gpart destroy command for this is ambiguous.
It's also kind of dangerous, in that when the user finally does
understand that "destroy" doesn't really destroy all partitioning, they
might use it expecting to only destroy the "bad" partitioning and be
surprised because things were not like they thought and it wiped out the
"good" partitioning.

Put another way:

`gpart destroy -F` means "destroy the GEOM unconditionally".

Adding this additional function to it makes it "destroy the GEOM, unless
some specific condition, and then it means only destroy a part of it."

As I think I said before, the function is really needed. It is just
making the user interface unambiguous that is my concern.

zfs has "labelclear". If gpart did that, along with a set amount of
space to clear at the beginning and end of the drive, I'd be happy with
it. It does not need to detect the type of geom.

gpart labelclear -F -s1m da22

to clear the first and last 1M of da22. Maybe force the user to give
the -F flag. (Yes, this can be done with dd, but slowly because of
oseeking to the end of a big drive. And it requires math, which is both
scary and beyond the capacity of many people to calculate.)

> It is impossible to have a corrupted GPT and some
> other type of partition table in the same time.

Maybe when only using FreeBSD and gpart, but I'm pretty sure I've seen
forum users who have tried some crappy other formatting tool and have
overwritten the primary GPT with a valid MBR and left the secondary GPT
untouched. This only becomes obvious when they bring the disk back to a
FreeBSD system.

[Andrey V. Elsukov]

On 31.01.2017 02:21, Warren Block wrote:
> On Mon, 30 Jan 2017, Andrey V. Elsukov wrote:
>
>> On 30.01.2017 18:55, Warren Block wrote:
>>>>> GEOM: da6: the primary GPT table is corrupt or invalid.
>>>>> GEOM: da6: using the secondary instead -- recovery strongly advised.
>>>>> GEOM: da22: the primary GPT table is corrupt or invalid.
>>>>> GEOM: da22: using the secondary instead -- recovery strongly advised.
>>>>> GEOM: da6: the primary GPT table is corrupt or invalid.
>>>>> GEOM: da6: using the secondary instead -- recovery strongly advised.
>>>>> GEOM: da22: the primary GPT table is corrupt or invalid.
>>>>> GEOM: da22: using the secondary instead -- recovery strongly advised.
>>>>
>>>> You may try attached patch, I did only basic tests, so first try
>>>> somewhere :)
>>>
>>> I really like the idea of gpart being able to remove the secondary GPT,
>>> but combining it with the existing destroy command is ambiguous. It's
>>> hard for the user to tell what will happen, and the command itself
>>> implies that it will destroy all partitioning.
>>
>> I don't see any ambiguity here. A user sees corrupted GPT, it can only
>> destroy or recover it.
>
> Ah, but the user might not even see it. "I wrote an MBR to my disk
> (with some other software) and now FreeBSD says it has a corrupted GPT."

I'm sure this is not true. GEOM_PART has several probe priorities. If
there is valid MBR, GPT will not have a chance to print messages about
corrupted tables.

Look at this example:

# truncate -s 100m disk
# mdconfig -f disk
md0
# gpart create -s gpt md0
md0 created
# gpart add -t freebsd-boot -s 128k md0
md0p1 added
# gpart show md0
=> 40 204720 md0 GPT (100M)
40 256 1 freebsd-boot (128K)
296 204464 - free - (100M)

# dd if=/dev/zero of=/dev/md0 count=2
2+0 records in
2+0 records out
1024 bytes transferred in 0.304545 secs (3362 bytes/sec)
# gpart show md0
=> 40 204720 md0 GPT (100M) [CORRUPT]
40 256 1 freebsd-boot (128K)
296 204464 - free - (100M)

# dmesg | grep GEOM
GEOM: md0: the primary GPT table is corrupt or invalid.
GEOM: md0: using the secondary instead -- recovery strongly advised.

Now let's write the MBR:

# dd if=/boot/mbr of=/dev/md0
1+0 records in
1+0 records out
512 bytes transferred in 0.033823 secs (15138 bytes/sec)
# gpart show md0
=> 9 204791 md0 MBR (100M)
9 204791 - free - (100M)

# mdconfig -du 0
# mdconfig -f disk
md0
# dmesg | grep GEOM
<no new messages about corrupted GPT>
# gpart show md0
=> 9 204791 md0 MBR (100M)
9 204791 - free - (100M)

> In this case, it can have a valid MBR which the user does not want to
> destroy. So re-using the gpart destroy command for this is ambiguous.
> It's also kind of dangerous, in that when the user finally does
> understand that "destroy" doesn't really destroy all partitioning, they
> might use it expecting to only destroy the "bad" partitioning and be
> surprised because things were not like they thought and it wiped out the
> "good" partitioning.

It is impossible to have two GEOM_PART's geoms on the same provider.

> Put another way:
>
> `gpart destroy -F` means "destroy the GEOM unconditionally".
>
> Adding this additional function to it makes it "destroy the GEOM, unless
> some specific condition, and then it means only destroy a part of it."

There is no need to add such "partial destroy", it still always destroys
GEOM. It always destroys partition table metadata. The proposed patch
only adds additional check. Since GPT has two parts of metadata, it
checks, that each part of metadata is valid before wipe them.

> As I think I said before, the function is really needed. It is just
> making the user interface unambiguous that is my concern.
>
> zfs has "labelclear". If gpart did that, along with a set amount of
> space to clear at the beginning and end of the drive, I'd be happy with
> it. It does not need to detect the type of geom.
>
> gpart labelclear -F -s1m da22
>
> to clear the first and last 1M of da22. Maybe force the user to give
> the -F flag. (Yes, this can be done with dd, but slowly because of
> oseeking to the end of a big drive. And it requires math, which is both
> scary and beyond the capacity of many people to calculate.)
>
>> It is impossible to have a corrupted GPT and some other type of
>> partition table in the same time.
>
> Maybe when only using FreeBSD and gpart, but I'm pretty sure I've seen
> forum users who have tried some crappy other formatting tool and have
> overwritten the primary GPT with a valid MBR and left the secondary GPT
> untouched. This only becomes obvious when they bring the disk back to a
> FreeBSD system.

As I said, in this case MBR will have higher priority and there will no
GPT, until you destroy MBR. After that GPT will appear. And you will be
able correctly destroy GPT using 'gpart destroy -F'.

--
WBR, Andrey V. Elsukov

[Warren Block]

On Mon, 30 Jan 2017, Ian Lepore wrote:

> On Tue, 2017-01-31 at 00:33 +0300, Andrey V. Elsukov wrote:
>> On 30.01.2017 20:23, Ian Lepore wrote:
>>>
>>>>
>>>> other type of partition table in the same time. So, if you use
>>>> 'gpart
>>>> destroy' - you want to explicitly destroy it.
>>>>
>>> The question to ask here is why are you the only one who can't see
>>> or
>>> understand that a user is NOT going to use a "destroy" command on a
>>>  disk containing live data?  Especially given the confusing
>>> vagueness
>>> of the gpart docs.
>> Because I have read the docs and understood them? Did you tried do
>> that 
>> instead of attacking me each time, when geom/gpart is discussed? I'm 
>> even not an author  of this. If you don't like the existing 
>> documentation, the sources are open, read them and write better 
>> documentation.
>>
>
> Every time someone says they can't understand how to do something with
> gpart, you imply that the problem is all theirs, because the
> documentation is clear.  The documentation is NOT clear, and every time
> you say so, I'm going to point out it is not.

I am interested in improving gpart documentation, if you have specific
suggestions.

Beyond that, these responses seem unnecessarily harsh and personal.

[Andrey V. Elsukov]

On 31.01.2017 18:43, Rodney W. Grimes wrote:
> ... much deleted ...

>>
>>> It is impossible to have a corrupted GPT and some

>>> other type of partition table in the same time.
>

> I believe that statement is in error.
> dd if=/boot/boot0 of=/dev/ada0
> Would not that lead to this very situation if done
> to a GPT parted disk drive?

No, it will not lead to this situation.
/boot/boot0 is similar to /boot/mbr in the example, and with /dev/ada0
all will behaves like with /dev/md0.

>> Maybe when only using FreeBSD and gpart, but I'm pretty sure I've seen
>> forum users who have tried some crappy other formatting tool and have
>> overwritten the primary GPT with a valid MBR and left the secondary GPT
>> untouched. This only becomes obvious when they bring the disk back to a
>> FreeBSD system.
>

> As almost all MBR tools are un aware of GPT so well not do anything to
> destroy the secondary GPT, so this is infact very likely to occur.

Please, give me some working example, when or where you have a problem,
and not some theoretical, based on previous negative experience or memories.

--
WBR, Andrey V. Elsukov

[Rodney W. Grimes]

... much deleted ...

>
> > It is impossible to have a corrupted GPT and some
> > other type of partition table in the same time.

I believe that statement is in error.
dd if=/boot/boot0 of=/dev/ada0
Would not that lead to this very situation if done
to a GPT parted disk drive?

> Maybe when only using FreeBSD and gpart, but I'm pretty sure I've seen
> forum users who have tried some crappy other formatting tool and have
> overwritten the primary GPT with a valid MBR and left the secondary GPT
> untouched. This only becomes obvious when they bring the disk back to a
> FreeBSD system.

As almost all MBR tools are un aware of GPT so well not do anything to
destroy the secondary GPT, so this is infact very likely to occur.

--
Rod Grimes rgr...@freebsd.org

[Andrey V. Elsukov]

On 31.01.2017 23:58, Rodney W. Grimes wrote:
>> No, it will not lead to this situation.
>> /boot/boot0 is similar to /boot/mbr in the example, and with /dev/ada0
>> all will behaves like with /dev/md0.
>

> Well if that is the case then the GPT backup copy is... well useless as
> I just clobbered the MBR of a drive and now gpart is gona just take that
> as fine and dandy?
>
> Doesnt that defeat the purpose of the backup GPT?

When you overwrite PMBR with MBR, you get MBR, but the GPT is still
here. If you need to recover your GPT, you need to put PMBR back (or
just destroy MBR with `gpart destroy`), and GPT will be detected again.
Even if you have overwritten GPT primary header and GPT primary table,
backup header and table give a chance for recovery to you.

--
WBR, Andrey V. Elsukov

[Rodney W. Grimes]

> On 31.01.2017 18:43, Rodney W. Grimes wrote:
> > ... much deleted ...
> >>
> >>> It is impossible to have a corrupted GPT and some
> >>> other type of partition table in the same time.
> >
> > I believe that statement is in error.
> > dd if=/boot/boot0 of=/dev/ada0
> > Would not that lead to this very situation if done
> > to a GPT parted disk drive?
>
> No, it will not lead to this situation.
> /boot/boot0 is similar to /boot/mbr in the example, and with /dev/ada0
> all will behaves like with /dev/md0.

Well if that is the case then the GPT backup copy is... well useless as
I just clobbered the MBR of a drive and now gpart is gona just take that
as fine and dandy?

Doesnt that defeat the purpose of the backup GPT?

> >> Maybe when only using FreeBSD and gpart, but I'm pretty sure I've seen
> >> forum users who have tried some crappy other formatting tool and have
> >> overwritten the primary GPT with a valid MBR and left the secondary GPT
> >> untouched. This only becomes obvious when they bring the disk back to a
> >> FreeBSD system.
> >
> > As almost all MBR tools are un aware of GPT so well not do anything to
> > destroy the secondary GPT, so this is infact very likely to occur.
>
> Please, give me some working example, when or where you have a problem,
> and not some theoretical, based on previous negative experience or memories.

Next time I see one I well be sure to preserve it, but I have seen problems
with bad interactions between GPT and MBR.

--
Rod Grimes rgr...@freebsd.org

[Ngie Cooper]

*snort* I completely forgot I had scripted this back 1.5 years ago:
https://github.com/yaneurabeya/scratch/blob/master/bayonetta/scratch/scripts/freebsd/wipe-gpt-partitions.sh
. This basically napalms all of the blocks at the beginning and end
that count per GPT (and MBR as well).

If someone wants, I can check this into FreeBSD somewhere under tools...

Thanks,
-Ngie

[Warren Block]

On Thu, 2 Feb 2017, Ngie Cooper wrote:

> *snort* I completely forgot I had scripted this back 1.5 years ago:
> https://github.com/yaneurabeya/scratch/blob/master/bayonetta/scratch/scripts/freebsd/wipe-gpt-partitions.sh
> . This basically napalms all of the blocks at the beginning and end
> that count per GPT (and MBR as well).
>
> If someone wants, I can check this into FreeBSD somewhere under tools...

dd is the standard solution, but the oseek to the end of the drive is
relatively slow. Or at least it seemed like it the last time I tried it
on a big drive. And thematically, the function goes with gpart.

[Warren Block]

On Tue, 31 Jan 2017, Andrey V. Elsukov wrote:

> On 31.01.2017 18:43, Rodney W. Grimes wrote:
>> ... much deleted ...
>>>
>>>> It is impossible to have a corrupted GPT and some
>>>> other type of partition table in the same time.
>>
>> I believe that statement is in error.
>> dd if=/boot/boot0 of=/dev/ada0
>> Would not that lead to this very situation if done
>> to a GPT parted disk drive?
>
> No, it will not lead to this situation.
> /boot/boot0 is similar to /boot/mbr in the example, and with /dev/ada0 all
> will behaves like with /dev/md0.
>
>>> Maybe when only using FreeBSD and gpart, but I'm pretty sure I've seen
>>> forum users who have tried some crappy other formatting tool and have
>>> overwritten the primary GPT with a valid MBR and left the secondary GPT
>>> untouched. This only becomes obvious when they bring the disk back to a
>>> FreeBSD system.
>>
>> As almost all MBR tools are un aware of GPT so well not do anything to
>> destroy the secondary GPT, so this is infact very likely to occur.
>
> Please, give me some working example, when or where you have a problem, and
> not some theoretical, based on previous negative experience or memories.

I just encountered something similar with a Windows 7 install on a disk
that previously had a FreeBSD GPT layout.

Clonezilla reported a conflicting GPT/MBR layout on the disk. In gpart,
it showed a valid GPT (not corrupt) with no partitions. After all the
cursing, I ran 'sudo sgdisk -z /dev/sda' as instructed by Clonezilla.

It was only after that I realized I should have saved at least the
partition tables.

[Andrey V. Elsukov]

On 04.02.2017 21:57, Warren Block wrote:
>> Please, give me some working example, when or where you have a
>> problem, and not some theoretical, based on previous negative
>> experience or memories.
>
> I just encountered something similar with a Windows 7 install on a disk
> that previously had a FreeBSD GPT layout.
>
> Clonezilla reported a conflicting GPT/MBR layout on the disk. In gpart,
> it showed a valid GPT (not corrupt) with no partitions. After all the
> cursing, I ran 'sudo sgdisk -z /dev/sda' as instructed by Clonezilla.
>
> It was only after that I realized I should have saved at least the
> partition tables.

Hi,

so, what is wrong here from your point of view?
I can imagine a way how to reproduce it.

Create two partition tables MBR and GPT.
# truncate -s 100m disk0
# truncate -s 100m disk1
# mdconfig -f disk0
md0
# mdconfig -f disk1
md1

# gpart create -s gpt md0
md0 created

# gpart create -s mbr md1
md1 created
# gpart add -t fat32 -s 25m md1
md1s1 added
# gpart add -t ntfs -s 25m md1
md1s2 added
# gpart add -t \!238 md1
md1s3 added
# gpart show md0 md1

=> 40 204720 md0 GPT (100M)

40 204720 - free - (100M)

=> 9 204791 md1 MBR (100M)
9 51200 1 fat32 (25M)
51209 51200 2 ntfs (25M)
102409 102391 3 !238 (50M)


Copy MBR from md1 to md0:

# dd if=/dev/md1 of=/dev/md0 count=1

1+0 records in
1+0 records out

512 bytes transferred in 0.285149 secs (1796 bytes/sec)
# gpart show md0 md1

=> 40 204720 md0 GPT (100M)

40 204720 - free - (100M)

=> 9 204791 md1 MBR (100M)
9 51200 1 fat32 (25M)
51209 51200 2 ntfs (25M)
102409 102391 3 !238 (50M)

Now md0 has correct MBR and GPT (not corrupt). GPT has higher priority,
due to MBR has partition with type 0xee (PMBR).
https://svnweb.freebsd.org/base?view=revision&revision=258448

Remove "PMBR" partition and overwrite MBR on md0 again:
# gpart delete -i 3 md1
md1s3 deleted
# dd if=/dev/md1 of=/dev/md0 count=1

1+0 records in
1+0 records out

512 bytes transferred in 0.289039 secs (1771 bytes/sec)
# gpart show md0 md1

=> 9 204791 md0 MBR (100M)

9 51200 1 fat32 (25M)
51209 51200 2 ntfs (25M)
102409 102391 - free - (50M)

=> 9 204791 md1 MBR (100M)
9 51200 1 fat32 (25M)
51209 51200 2 ntfs (25M)
102409 102391 - free - (50M)

md0 still has both GPT and MBR, but GPT has lower priority, because
there is no PMBR partition.

Destroy MBR on the md0:

# gpart destroy -F md0
md0 destroyed
# gpart show md0 md1
gpart: No such geom: md0.

And force retaste:
# true > /dev/md0
# gpart show md0 md1

=> 40 204720 md0 GPT (100M)

40 204720 - free - (100M)

=> 9 204791 md1 MBR (100M)
9 51200 1 fat32 (25M)
51209 51200 2 ntfs (25M)
102409 102391 - free - (50M)

--
WBR, Andrey V. Elsukov