GPT partition only?

This is not a big deal but I decided to put a 750 gig drive from a dead
laptop and put it in an external USB enclosure to use as a backup drive.

I connected it to my Linux machine and deleted the partitions, then
recreated a single primary NTFS partition. I was able to copy date to it
and use it with my Linux machine and also my Win7 and Win10 machines.


Next I decided to back up a few files from some older Win2k and XP
machines...but Windows Explorer did not recognize the drive.

Disk management sees it as a GPT partition.



From XP or Win2k there was no option to delete the partition so I
attached it to my Linux machine and just deleted the drive and did not
recreate a partition.


Back in the XP or Win2k machine Disk Management still sees it as GPT


I'm now puzzled.


At any rate, Since I can easily back up those old machine with other
drives, I'm going to just leave that one as GPT...but still I'm curious
as to what might have happened.

philo wrote:
This is not a big deal but I decided to put a 750 gig drive from a dead
laptop and put it in an external USB enclosure to use as a backup drive.

I connected it to my Linux machine and deleted the partitions, then
recreated a single primary NTFS partition. I was able to copy date to it
and use it with my Linux machine and also my Win7 and Win10 machines.


Next I decided to back up a few files from some older Win2k and XP
machines...but Windows Explorer did not recognize the drive.

Disk management sees it as a GPT partition.



From XP or Win2k there was no option to delete the partition so I
attached it to my Linux machine and just deleted the drive and did not
recreate a partition.


Back in the XP or Win2k machine Disk Management still sees it as GPT


I'm now puzzled.


At any rate, Since I can easily back up those old machine with other
drives, I'm going to just leave that one as GPT...but still I'm curious
as to what might have happened.

In diskpart, do a Clean All on the selected drive,
and it'll stop complaining about everything. Clean All
zeros the entire drive, and no 128MB GPT partition tables
will be discovered by accident. The "Clean" option just
zeros the MBR itself and takes a microsecond. Whereas
Clean All will take a couple hours.

On your Linux machine, you can try

disktype /dev/sda

and have it analyze what it sees. Or try gparted
and see if it noticed any traces of GPT. I think
I've had TestDisk jump to conclusions about what
is on a drive too.

I don't really know what a good amount of zeroing is
for such a drive. Would just zeroing the first 1GB of the
drive stop this behavior ? It seems that removing the 0xEE
partition from the partition table, is not sufficient to
prevent GPT detection by all tools.

There is a protective partition entry in the MBR. It's
a single entry. The size of the entry spans the entire
drive. The partition type is 0xEE. That indicates a GPT
table is present. A 128MB GPT table presumably is
big enough to define 128 partitions.

For some reason, the GPT partition table might still be
recognized once that is removed or replaced with real
MBR partition info. And what I usually do to stop such
behavior, is just Clean All and walk away.

If you're in a rush, you can dab at it with

dd if=/dev/zero of=/dev/sdX bs=1048576 count=1024

and see if the obnoxious detections stop. Since that also
clears the MBR on that drive, no partitions will be defined
right after that. And then Disk Management is going to
ask you to pick a partition scheme (MBR or GPT).

The only reason I'm not recommending the usage of GPT,
is because of the state of free tools available to work
on hard drives. It's just "cheaper" to leave drives
smaller than 2.2TB in MBR partition mode. For example,
TestDisk will probably work better, or that free NTFS
recovery utility only knows about MBR, and it's probably
easier to get a fix for a situation like that later
(legacy MBR).

Paul

On 02/05/2018 07:18 PM, Paul wrote:


and have it analyze what it sees. Or try gparted
and see if it noticed any traces of GPT. I think
I've had TestDisk jump to conclusions about what
is on a drive too.

I don't really know what a good amount of zeroing is
for such a drive. Would just zeroing the first 1GB of the
drive stop this behavior ? It seems that removing the 0xEE
partition from the partition table, is not sufficient to
prevent GPT detection by all tools.

There is a protective partition entry in the MBR. It's
a single entry. The size of the entry spans the entire
drive. The partition type is 0xEE. That indicates a GPT
table is present. A 128MB GPT table presumably is
big enough to define 128 partitions.

For some reason, the GPT partition table might still be
recognized once that is removed or replaced with real
MBR partition info. And what I usually do to stop such
behavior, is just Clean All and walk away.

If you're in a rush, you can dab at it with

Â*Â* dd if=/dev/zero of=/dev/sdX bs=1048576 count=1024

and see if the obnoxious detections stop. Since that also
clears the MBR on that drive, no partitions will be defined
right after that. And then Disk Management is going to
ask you to pick a partition scheme (MBR or GPT).

The only reason I'm not recommending the usage of GPT,
is because of the state of free tools available to work
on hard drives. It's just "cheaper" to leave drives
smaller than 2.2TB in MBR partition mode. For example,
TestDisk will probably work better, or that free NTFS
recovery utility only knows about MBR, and it's probably
easier to get a fix for a situation like that later
(legacy MBR).

Â*Â* Paul



Thank you very much Paul.

Since I'm now copying data to the drive I guess I will just leave it but
now I will know the next time anything like this happens.

You really know your stuff!

philo wrote:
On 02/05/2018 07:18 PM, Paul wrote:


and have it analyze what it sees. Or try gparted
and see if it noticed any traces of GPT. I think
I've had TestDisk jump to conclusions about what
is on a drive too.

I don't really know what a good amount of zeroing is
for such a drive. Would just zeroing the first 1GB of the
drive stop this behavior ? It seems that removing the 0xEE
partition from the partition table, is not sufficient to
prevent GPT detection by all tools.

There is a protective partition entry in the MBR. It's
a single entry. The size of the entry spans the entire
drive. The partition type is 0xEE. That indicates a GPT
table is present. A 128MB GPT table presumably is
big enough to define 128 partitions.

For some reason, the GPT partition table might still be
recognized once that is removed or replaced with real
MBR partition info. And what I usually do to stop such
behavior, is just Clean All and walk away.

If you're in a rush, you can dab at it with

dd if=/dev/zero of=/dev/sdX bs=1048576 count=1024

and see if the obnoxious detections stop. Since that also
clears the MBR on that drive, no partitions will be defined
right after that. And then Disk Management is going to
ask you to pick a partition scheme (MBR or GPT).

The only reason I'm not recommending the usage of GPT,
is because of the state of free tools available to work
on hard drives. It's just "cheaper" to leave drives
smaller than 2.2TB in MBR partition mode. For example,
TestDisk will probably work better, or that free NTFS
recovery utility only knows about MBR, and it's probably
easier to get a fix for a situation like that later
(legacy MBR).

Paul



Thank you very much Paul.

Since I'm now copying data to the drive I guess I will just leave it but
now I will know the next time anything like this happens.

You really know your stuff!

In this case, all I'm doing is relaying the weirdness I've seen.
For whatever reason, just zeroing the MBR isn't enough for GPT
drives, when it really should be. It suggests the MBR is protective
and not descriptive (it's there to make legacy OSes go
away, not to actual dictate what kind of partitioning
scheme it is).

It suggests an OS may be looking for the partition table GPT uses
in any case. That's the only explanation that fits the symptoms.

*******

One other tidbit for your trivial collection - *don't* make
NTFS partitions in Windows 10 at the current time. Use your
Windows 7 OS to make an NTFS partition. Since 16299, I've noticed
that $MFTMIRR is not being made properly by Windows 10. This
is not an MBR versus GPT issue, and it could happen any
time you make a fresh NTFS partition under Windows 10.

The problem can be fixed by TestDisk. It has an MFTMIRR repair
facility.

Windows doesn't seem to care, and CHKDSK won't fix it.

If you don't fix it, the partition won't mount in Linux.
That's how I detected there was a problem, and TestDisk
verified it.

Paul


Paul

On 02/05/2018 09:06 PM, Paul wrote:
philo wrote:
On 02/05/2018 07:18 PM, Paul wrote:


and have it analyze what it sees. Or try gparted
and see if it noticed any traces of GPT. I think
I've had TestDisk jump to conclusions about what
is on a drive too.

I don't really know what a good amount of zeroing is
for such a drive. Would just zeroing the first 1GB of the
drive stop this behavior ? It seems that removing the 0xEE
partition from the partition table, is not sufficient to
prevent GPT detection by all tools.

There is a protective partition entry in the MBR. It's
a single entry. The size of the entry spans the entire
drive. The partition type is 0xEE. That indicates a GPT
table is present. A 128MB GPT table presumably is
big enough to define 128 partitions.

For some reason, the GPT partition table might still be
recognized once that is removed or replaced with real
MBR partition info. And what I usually do to stop such
behavior, is just Clean All and walk away.

If you're in a rush, you can dab at it with

Â*Â*Â* dd if=/dev/zero of=/dev/sdX bs=1048576 count=1024

and see if the obnoxious detections stop. Since that also
clears the MBR on that drive, no partitions will be defined
right after that. And then Disk Management is going to
ask you to pick a partition scheme (MBR or GPT).

The only reason I'm not recommending the usage of GPT,
is because of the state of free tools available to work
on hard drives. It's just "cheaper" to leave drives
smaller than 2.2TB in MBR partition mode. For example,
TestDisk will probably work better, or that free NTFS
recovery utility only knows about MBR, and it's probably
easier to get a fix for a situation like that later
(legacy MBR).

Â*Â*Â* Paul



Thank you very much Paul.

Since I'm now copying data to the drive I guess I will just leave it
but now I will know the next time anything like this happens.

You really know your stuff!

In this case, all I'm doing is relaying the weirdness I've seen.
For whatever reason, just zeroing the MBR isn't enough for GPT
drives, when it really should be. It suggests the MBR is protective
and not descriptive (it's there to make legacy OSes go
away, not to actual dictate what kind of partitioning
scheme it is).

It suggests an OS may be looking for the partition table GPT uses
in any case. That's the only explanation that fits the symptoms.

*******

One other tidbit for your trivial collection - *don't* make
NTFS partitions in Windows 10 at the current time. Use your
Windows 7 OS to make an NTFS partition. Since 16299, I've noticed
that $MFTMIRR is not being made properly by Windows 10. This
is not an MBR versus GPT issue, and it could happen any
time you make a fresh NTFS partition under Windows 10.

The problem can be fixed by TestDisk. It has an MFTMIRR repair
facility.

Windows doesn't seem to care, and CHKDSK won't fix it.

If you don't fix it, the partition won't mount in Linux.
That's how I detected there was a problem, and TestDisk
verified it.

Â*Â* Paul


Â*Â* Paul



As it turned out, the data copy was going abnormally slow ...so I ran
the WD diagnostic and got:


Data Address Mark (DAM) Error. There may be media errors present on this
drive.


Test was early aborted due to too many errors


So the drive is junk.


But just the same thank you for the valuable info

philo wrote:

This is not a big deal but I decided to put a 750 gig drive from a dead
laptop and put it in an external USB enclosure to use as a backup drive.

I connected it to my Linux machine and deleted the partitions, then
recreated a single primary NTFS partition. I was able to copy date to it
and use it with my Linux machine and also my Win7 and Win10 machines.


Next I decided to back up a few files from some older Win2k and XP
machines...but Windows Explorer did not recognize the drive.

Disk management sees it as a GPT partition.

GPT is not a type of partition, it's a type of partition table, which
describes the partitions on the disk. So it sounds like you have a GPT
partition table, that points to a single NTFS partition. Is it
possible that when you worked the disk over with Linux you wiped out
and recreated the partition table in the GPT format?

It's certainly possible that an older OS - like Win2K or XP - wouldn't
know how to read a GPT table.

From XP or Win2k there was no option to delete the partition

If it can't read the table, it can't even tell that there is a
partition, much less give you an option to delete it.

so I
attached it to my Linux machine and just deleted the drive and did not
recreate a partition.

Deleted the drive? I assume you mean you deleted the partition.

Back in the XP or Win2k machine Disk Management still sees it as GPT

Of course, because you didn't delete the partition table, just the
partition.

--
Tim Slattery
tim at risingdove dot com

On 02/06/2018 09:52 AM, Tim Slattery wrote:
philo wrote:

This is not a big deal but I decided to put a 750 gig drive from a dead
laptop and put it in an external USB enclosure to use as a backup drive.

I connected it to my Linux machine and deleted the partitions, then
recreated a single primary NTFS partition. I was able to copy date to it
and use it with my Linux machine and also my Win7 and Win10 machines.


Next I decided to back up a few files from some older Win2k and XP
machines...but Windows Explorer did not recognize the drive.

Disk management sees it as a GPT partition.

GPT is not a type of partition, it's a type of partition table, which
describes the partitions on the disk. So it sounds like you have a GPT
partition table, that points to a single NTFS partition. Is it
possible that when you worked the disk over with Linux you wiped out
and recreated the partition table in the GPT format?

It's certainly possible that an older OS - like Win2K or XP - wouldn't
know how to read a GPT table.

From XP or Win2k there was no option to delete the partition

If it can't read the table, it can't even tell that there is a
partition, much less give you an option to delete it.

so I
attached it to my Linux machine and just deleted the drive and did not
recreate a partition.

Deleted the drive? I assume you mean you deleted the partition.

Back in the XP or Win2k machine Disk Management still sees it as GPT

Of course, because you didn't delete the partition table, just the
partition.




Thanks for the info...

I am pretty sure my problem was due to the drive itself being defective.

On 02/06/2018 08:43 AM, philo wrote:



snip
(legacy MBR).

Â*Â*Â* Paul



Thank you very much Paul.

Since I'm now copying data to the drive I guess I will just leave it
but now I will know the next time anything like this happens.

You really know your stuff!

In this case, all I'm doing is relaying the weirdness I've seen.
For whatever reason, just zeroing the MBR isn't enough for GPT
drives, when it really should be. It suggests the MBR is protective
and not descriptive (it's there to make legacy OSes go
away, not to actual dictate what kind of partitioning
scheme it is).

It suggests an OS may be looking for the partition table GPT uses
in any case. That's the only explanation that fits the symptoms.

*******

One other tidbit for your trivial collection - *don't* make
NTFS partitions in Windows 10 at the current time. Use your
Windows 7 OS to make an NTFS partition. Since 16299, I've noticed
that $MFTMIRR is not being made properly by Windows 10. This
is not an MBR versus GPT issue, and it could happen any
time you make a fresh NTFS partition under Windows 10.

The problem can be fixed by TestDisk. It has an MFTMIRR repair
facility.

Windows doesn't seem to care, and CHKDSK won't fix it.

If you don't fix it, the partition won't mount in Linux.
That's how I detected there was a problem, and TestDisk
verified it.

Â*Â*Â* Paul


Â*Â*Â* Paul



As it turned out, the data copy was going abnormally slow ...so I ran
the WD diagnostic and got:


Data Address Mark (DAM) Error. There may be media errors present on this
drive.


Test was early aborted due to too many errors


So the drive is junk.


But just the same thank you for the valuable info




Because I have no other major projects going , I decided to try a newer
WD utility and it disagreed with the results of the other one.


It has a "fast" zero wipe utility where it simply zeros out the
beginning and end of the drive...so I tried that and put it back in an
XP machine and now Disk Management sees it as blank.


I am now giving it a long format and when done will see how it performs.