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