Re: [gentoo-user] Trouble with backup harddisks

[Wynn Wolf Arbor]

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