1 |
All the following assuming that the disk was originally partitioned as |
2 |
GPT, but after that exclusively accessed as an MBR disk. |
3 |
|
4 |
>PT fdisk (gdisk) version 1.0.5 |
5 |
> |
6 |
>Caution: invalid main GPT header, but valid backup; regenerating main header |
7 |
>from backup! |
8 |
|
9 |
This makes sense since the GPT backup at the very end of the disk would |
10 |
most likely still be intact. gdisk identifies it correctly, but assumes |
11 |
(wrongly) that the data on the disk is governed by the GPT layout. |
12 |
|
13 |
Since the disk was only ever accessed through an operating system that |
14 |
knew solely about MBR, the GPT data meant nothing to it. It happily |
15 |
wrote data past the MBR headers. Because the protective MBR is |
16 |
positioned before GPT information, the primary GPT header was destroyed |
17 |
and most likely overwritten with the file system. See also [1], the |
18 |
actual file system data probably begins somewhere past LBA 0. |
19 |
|
20 |
>Caution! After loading partitions, the CRC doesn't check out! |
21 |
>Warning: Invalid CRC on main header data; loaded backup partition table. |
22 |
>Warning! Main and backup partition tables differ! Use the 'c' and 'e' options |
23 |
>on the recovery & transformation menu to examine the two tables. |
24 |
|
25 |
This is because the backup GPT written when first partitioned does no |
26 |
longer match the data present at the very beginning of the disk. |
27 |
|
28 |
If the initial assumption is correct, GPT *must not* be restored. Your |
29 |
modern PC sees the GPT partition type and assumes the existence of a |
30 |
GPT. It should, however, access the MBR layout and interpret the |
31 |
partition marked with the GPT ID as a regular partition. |
32 |
|
33 |
Now, how to fix this? |
34 |
|
35 |
Like Andrea already said earlier: |
36 |
|
37 |
> Since the disk is only 1TB, there is no reason to use GPT at all, so |
38 |
> your best bet is to use fdisk to make that a standard MBR by changing |
39 |
> the partition type from 'ee' to '83'. |
40 |
|
41 |
This would *not* repartition or reformat any data, it would simply tell |
42 |
your modern operating system to access the protective partition as a |
43 |
regular one. |
44 |
|
45 |
It would, however, require writing the new type to disk. What you could |
46 |
do to be more safe here is to take a backup of the first 512 bytes with |
47 |
`dd', then change the partition ID with `fdisk', and try mounting it. |
48 |
|
49 |
If it works, great. If not, you can restore the first 512 bytes of the |
50 |
disk with the backup. |
51 |
|
52 |
>"fix manually" scares me...especially because I have no place for |
53 |
>1TB of an image file to with which I can experiment ... |
54 |
|
55 |
>Any ideas which could ease my burden and to un-scare my |
56 |
>"need to fix it manually" ??? ;) ;) |
57 |
|
58 |
There's a few alternatives: |
59 |
|
60 |
1) Boot an older system that only understands MBR, and mount the disk |
61 |
there. This was suggested earlier but was dismissed because we assumed |
62 |
the sector size had something to do with it. I do not think this is the |
63 |
case anymore - the old system should be able to read it. |
64 |
|
65 |
2) Boot a VM with a kernel that only understands MBR, pass USB through |
66 |
to the virtual machine, mount the disk there. |
67 |
|
68 |
3) Try confirming that there exists file system data past the MBR header. |
69 |
|
70 |
Maybe something like this: |
71 |
|
72 |
# dd if=/dev/sdb of=sdb-data bs=512 skip=1 count=16384 |
73 |
$ file sdb-data |
74 |
|
75 |
As established, the block size is 512 bytes. We skip the first 512 bytes |
76 |
since that is the protective MBR. sdb-data should then contain the first |
77 |
8MiB worth of actual file system data. The `file' utility can tell you |
78 |
what kind of data it is. |
79 |
|
80 |
[1] https://en.wikipedia.org/wiki/GUID_Partition_Table#/media/File:GUID_Partition_Table_Scheme.svg |
81 |
|
82 |
-- |
83 |
Wolf |