All the following assuming that the disk was originally partitioned as
GPT, but after that exclusively accessed as an MBR disk.
PT fdisk (gdisk) version 1.0.5
Caution: invalid main GPT header, but valid backup; regenerating main header
from backup!
This makes sense since the GPT backup at the very end of the disk would
most likely still be intact. gdisk identifies it correctly, but assumes
(wrongly) that the data on the disk is governed by the GPT layout.
Since the disk was only ever accessed through an operating system that
knew solely about MBR, the GPT data meant nothing to it. It happily
wrote data past the MBR headers. Because the protective MBR is
positioned before GPT information, the primary GPT header was destroyed
and most likely overwritten with the file system. See also [1], the
actual file system data probably begins somewhere past LBA 0.
Caution! After loading partitions, the CRC doesn't check out!
Warning: Invalid CRC on main header data; loaded backup partition table.
Warning! Main and backup partition tables differ! Use the 'c' and 'e' options
on the recovery & transformation menu to examine the two tables.
This is because the backup GPT written when first partitioned does no
longer match the data present at the very beginning of the disk.
If the initial assumption is correct, GPT *must not* be restored. Your
modern PC sees the GPT partition type and assumes the existence of a
GPT. It should, however, access the MBR layout and interpret the
partition marked with the GPT ID as a regular partition.
Now, how to fix this?
Like Andrea already said earlier:
Since the disk is only 1TB, there is no reason to use GPT at all, so
your best bet is to use fdisk to make that a standard MBR by changing
the partition type from 'ee' to '83'.
This would *not* repartition or reformat any data, it would simply tell
your modern operating system to access the protective partition as a
regular one.
It would, however, require writing the new type to disk. What you could
do to be more safe here is to take a backup of the first 512 bytes with
`dd', then change the partition ID with `fdisk', and try mounting it.
If it works, great. If not, you can restore the first 512 bytes of the
disk with the backup.
"fix manually" scares me...especially because I have no place for
1TB of an image file to with which I can experiment ...
Any ideas which could ease my burden and to un-scare my
"need to fix it manually" ??? ;) ;)
There's a few alternatives:
1) Boot an older system that only understands MBR, and mount the disk
there. This was suggested earlier but was dismissed because we assumed
the sector size had something to do with it. I do not think this is the
case anymore - the old system should be able to read it.
2) Boot a VM with a kernel that only understands MBR, pass USB through
to the virtual machine, mount the disk there.
3) Try confirming that there exists file system data past the MBR header.
Maybe something like this:
# dd if=/dev/sdb of=sdb-data bs=512 skip=1 count=16384
$ file sdb-data
As established, the block size is 512 bytes. We skip the first 512 bytes
since that is the protective MBR. sdb-data should then contain the first
8MiB worth of actual file system data. The `file' utility can tell you
what kind of data it is.
[1]
https://en.wikipedia.org/wiki/GUID_Partition_Table#/media/File:GUID_Partition_Table_Scheme.svg
--
Wolf
