1 |
Hi Wolf |
2 |
|
3 |
thank you very much for your analysis ! :) |
4 |
|
5 |
On 04/30 03:10, Wynn Wolf Arbor wrote: |
6 |
> Hi, |
7 |
> |
8 |
> On 2020-04-30 13:17, Wols Lists wrote: |
9 |
> > All I can suggest is to check the kernel and see if it's an option that |
10 |
> > has been disabled (512-byte sectors, that is). |
11 |
> |
12 |
> As far as I know the kernel still uses 512 bytes internally [1], and I do |
13 |
> not recall having seen an option that enables or disables support for 512/4K |
14 |
> sectors. |
15 |
> |
16 |
> That said, the problem may well be stemming from a sector size discrepancy, |
17 |
> but as I understand it, it would have to do with how and when the partition |
18 |
> table was created. That is, like described in [2], some USB enclosures seem |
19 |
> to be a bit overzealous with obscure features, and might take eight disk |
20 |
> sectors and bundle them together into one 4K sector. |
21 |
> |
22 |
> If the disk was partitioned in the exact same enclosure, and is read from |
23 |
> the exact same enclosure right now, there shouldn't be any problems. Is this |
24 |
> the case, Meino? |
25 |
|
26 |
I have two external disks of that kind, same product, nearly the same |
27 |
contents, both have a "fixed case" (sorry...no native speaker...the |
28 |
case and the disk mechanics/electronics is "one thing"). |
29 |
> |
30 |
> Also, when did you last access the drives successfully, and with which |
31 |
> system? |
32 |
|
33 |
Three weeks ago...about...guessed...with my old system. |
34 |
Because these were backup disks I *NEVER* touch them with |
35 |
any partitioning tool whatsoever... |
36 |
|
37 |
It is complete unknown to me, what could have destroyed the |
38 |
partitioning... |
39 |
|
40 |
> On 2020-04-30 11:32, Meino wrote: |
41 |
> > Disk /dev/sdb: 931.49 GiB, 1000170586112 bytes, 1953458176 sectors |
42 |
> > Disk model: Elements 25A2 Units: sectors of 1 * 512 = 512 bytes |
43 |
> > Sector size (logical/physical): 512 bytes / 512 bytes |
44 |
> > I/O size (minimum/optimal): 512 bytes / 512 bytes |
45 |
> > |
46 |
> > Disklabel type: dos |
47 |
> > Disk identifier: 0x16f2a91f |
48 |
> > |
49 |
> > Device Boot Start End Sectors Size Id Type |
50 |
> > /dev/sdb1 1 1953458175 1953458175 931.5G ee GPT |
51 |
> |
52 |
> Interestingly, this reads *exactly* like the Protective MBR [3] that GPT |
53 |
> has. That is, the disklabel type is DOS whilst the partition ID is EE. |
54 |
> There's a single partition that spans the entire drive (and it's also |
55 |
> seemingly not aligned properly - usually you see Start at 2048). |
56 |
|
57 |
> As a comparison, here's the output from fdisk for the Protective MBR from |
58 |
> one of my GPT drives: |
59 |
> |
60 |
> > Disklabel type: dos |
61 |
> > Disk identifier: 0x00000000 |
62 |
> |
63 |
> > Device Boot Start End Sectors Size Id Type |
64 |
> > /dev/sdc1 1 4294967295 4294967295 2T ee GPT |
65 |
> |
66 |
> I'd assume that the missing disk identifier here is coming from different |
67 |
> tools writing the protective MBR differently. |
68 |
> |
69 |
> With that said, are you absolutely certain that you did not partition this |
70 |
> drive with GPT instead of MBR? |
71 |
|
72 |
YES! These drives were used as backup and as backup of the backup. I |
73 |
NEVER touched them with any partitioning tool after I had put a |
74 |
filesystem and data on it. |
75 |
|
76 |
> Did you do the partitioning in something like |
77 |
> fdisk (which asks you specifically what you want), or some other |
78 |
> application? Did you maybe format this drive on a Windows system? |
79 |
|
80 |
Windows? ....no thank you...all my windows here are transparent and |
81 |
open,.. ;) |
82 |
Joke aside.. |
83 |
No Windows (tm) here. The disks are used only with my Linux box using |
84 |
ext4 as filesystem. |
85 |
|
86 |
> |
87 |
> I'm not one to discount entirely strange things happening, but I have never |
88 |
> before seen a proper MBR laid out like a protective MBR. Indeed it would be |
89 |
> quite impossible to have systems access data through such a table, since the |
90 |
> partitions are hidden within that one huge contiguous block. |
91 |
> |
92 |
> Ordinarily I'd point to fdisk not reading the partition table properly, but |
93 |
> it seems that although your kernel has support for GPT, it doesn't seem to |
94 |
> see the partitions either (assuming a proper GPT exists at all). |
95 |
|
96 |
> Do you have some other GPT drives you can access successfully? |
97 |
With my new PC (my old MBR-based system was 12 years old and needed to |
98 |
be replaced. My kernel became "GPT aware onlu with my new PC. |
99 |
Everything before was based on MBR. |
100 |
|
101 |
My new PC can read GPT disks...my system is based on it. |
102 |
> |
103 |
> I'd say that this requires some more forensic work. Perhaps extracting the |
104 |
> first few megabytes of the disk and seeing whether there's a proper GPT or |
105 |
> not. This would of course require manual work. |
106 |
|
107 |
I copied the first 230GB of that disk to an empty partition of my new |
108 |
system and run "testdisk" on it....after the analysis it came back |
109 |
with "this partition cannot be recovered" but did not sau. whether the |
110 |
reason is a partition table, which is broken beyond repair, or simply |
111 |
due to the incomplete image file... |
112 |
|
113 |
> |
114 |
> A few more things to try: |
115 |
> |
116 |
> To see what the kernel uses for a particular disk, you can run the |
117 |
> following: cat /sys/block/sdb/queue/{physical,logical}_block_size |
118 |
|
119 |
|
120 |
host:/home/user>cat /sys/block/sdb/queue/physical_block_size |
121 |
512 |
122 |
solfire:/home/user>cat /sys/block/sdb/queue/logical_block_size |
123 |
512 |
124 |
host:/home/user> |
125 |
|
126 |
> fdisk takes a sector size with -b, --sector-size (should be non-destructive |
127 |
> as long as you don't write anything, but I am not sure). Also, fdisk has a |
128 |
> compatibility mode for dos with -c=dos. Might be worth a short. |
129 |
|
130 |
host:data/pool07>fdisk -c=dos testf.bin |
131 |
|
132 |
Welcome to fdisk (util-linux 2.35.1). |
133 |
Changes will remain in memory only, until you decide to write them. |
134 |
Be careful before using the write command. |
135 |
|
136 |
GPT PMBR size mismatch (1953458175 != 455078119) will be corrected by write. |
137 |
DOS-compatible mode is deprecated. |
138 |
|
139 |
Command (m for help): p |
140 |
|
141 |
Disk testf.bin: 216.102 GiB, 232999997440 bytes, 455078120 sectors |
142 |
Geometry: 256 heads, 63 sectors/track, 28327 cylinders |
143 |
Units: sectors of 1 * 512 = 512 bytes |
144 |
Sector size (logical/physical): 512 bytes / 512 bytes |
145 |
I/O size (minimum/optimal): 512 bytes / 512 bytes |
146 |
Disklabel type: dos |
147 |
Disk identifier: 0x16f2a91f |
148 |
|
149 |
Device Boot Start End Sectors Size Id Type |
150 |
testf.bin1 1 455078119 455078119 217G ee GPT |
151 |
|
152 |
Command (m for help): |
153 |
|
154 |
|
155 |
|
156 |
> fdisk should support GPT starting with util-linux 2.23, but you can also try |
157 |
> gptfdisk (it's in the tree). |
158 |
> |
159 |
> Hope this helps. |
160 |
> |
161 |
> [1] https://github.com/torvalds/linux/blob/master/include/linux/types.h#L120 |
162 |
> [2] https://superuser.com/questions/679725/how-to-correct-512-byte-sector-mbr-on-a-4096-byte-sector-disk/679800#679800 |
163 |
> [3] https://en.wikipedia.org/wiki/GUID_Partition_Table#PROTECTIVE-MBR |
164 |
> |
165 |
> -- |
166 |
> Wolf |
167 |
|
168 |
Thanks a lot Wolf!!! |
169 |
|
170 |
Cheers! |
171 |
Meino |