1 |
james wrote: |
2 |
|
3 |
> On 07/31/2016 12:56 PM, Jörg Schaible wrote: |
4 |
>> Jörg Schaible wrote: |
5 |
>> |
6 |
>>> Hi Daniel, |
7 |
>>> |
8 |
>>> thanks for your response. |
9 |
>>> |
10 |
>>> Daniel Frey wrote: |
11 |
>>> |
12 |
>>> [snip] |
13 |
>>> |
14 |
>>>> I can only think of two reasons, the kernel on the livecd doesn't |
15 |
>>>> support GPT (which is unlikely) |
16 |
>>> |
17 |
>>> That would be really strange. However, how can I prove it? |
18 |
>>> |
19 |
>>>> or you're booting a 32-bit kernel live |
20 |
>>>> USB. I am reasonably certain for drives > 2TB a 64-bit kernel and GPT |
21 |
>>>> are required. |
22 |
>>> |
23 |
>>> No, I've always chosen 64-bit kernels. I wonder what is so special about |
24 |
>>> this partition ... |
25 |
>> |
26 |
>> Currently I wonder, why my system can find the partition at all: |
27 |
>> |
28 |
>> ======================== %< ======================== |
29 |
>> # gdisk -l /dev/sdi |
30 |
>> GPT fdisk (gdisk) version 1.0.1 |
31 |
>> |
32 |
>> Partition table scan: |
33 |
>> MBR: protective |
34 |
>> BSD: not present |
35 |
>> APM: not present |
36 |
>> GPT: not present |
37 |
> |
38 |
> If you have seen my recent thread, |
39 |
|
40 |
I saw it, but did not read it in depth, because I had the impression, it is |
41 |
mainly about EFI systems. I'll re-read it ... |
42 |
|
43 |
> much of this automounting during |
44 |
> boot(strapping) is flaky that is much of what I have been searching out |
45 |
> is a default (magical) partitioning schema that will eventually lead to |
46 |
> clear documents on the current state of affairs not only with old versus |
47 |
> new motherboards (mbr-->efi) and disk (mbr < 2.2T and gpt >2.2T) |
48 |
> but including all sorts of new arm and other embedded (linux) boards. |
49 |
> |
50 |
> Different forms of Solid State memory are next on my list, with usb (1.x |
51 |
> --> 3.x) being top of the SS memory mediums..... (Sorry I do not have |
52 |
> more atm). |
53 |
> |
54 |
>> Creating new GPT entries. |
55 |
>> Disk /dev/sdi: 732566646 sectors, 2.7 TiB |
56 |
>> Logical sector size: 4096 bytes |
57 |
>> Disk identifier (GUID): 80C04475-9B51-4A44-A52F-1F165AE02695 |
58 |
>> Partition table holds up to 128 entries |
59 |
>> First usable sector is 6, last usable sector is 732566640 |
60 |
>> Partitions will be aligned on 256-sector boundaries |
61 |
>> Total free space is 732566635 sectors (2.7 TiB) |
62 |
>> |
63 |
>> Number Start (sector) End (sector) Size Code Name |
64 |
>> ======================== %< ======================== |
65 |
>> |
66 |
>> However, it's mounted successfully, see system logs: |
67 |
>> |
68 |
>> ======================== %< ======================== |
69 |
>> [22735.626752] sd 13:0:0:0: [sdi] 732566646 4096-byte logical blocks: |
70 |
>> [(3.00 |
71 |
>> TB/2.73 TiB) |
72 |
>> [22735.629255] sdi: sdi1 |
73 |
>> [23414.066315] EXT4-fs (sdi1): mounted filesystem with ordered data mode. |
74 |
>> Opts: (null) |
75 |
>> ======================== %< ======================== |
76 |
>> |
77 |
>> Has anyone ever tried the recovery option of GPT disk to rebuild GPT from |
78 |
>> MBR? |
79 |
> |
80 |
> I see some sort of 'auto correction' by gpt technology to convert many |
81 |
> forms of perceived mbr to gpt to be used by the booting process for |
82 |
> spinning rust. So this issue is not limited to usb medium. I would also |
83 |
> point out that I'd look deeply into the usb specs for the vendor of your |
84 |
> usb sticks, as they do some 'funky things' at the firmware level inside |
85 |
> many of the newer/faster/larger usb devices. It not just dumb memory |
86 |
> like the early 1.x devices. Many are slanted to Microsoft business |
87 |
> strategies. I'm not suggesting that is your current issues. I'm merely |
88 |
> pointing out that some newer usb sticks are systems themselves complete |
89 |
> with firmware so the devices looks like dumb memory. Furthermore, the |
90 |
> silicon vendors provide firmware options to usb sticks vendors (like |
91 |
> Texas Instruments) but also the vendor add to or change the hidden |
92 |
> firmware as meets their multifaceted business objects. Sadly, the NSA is |
93 |
> deeply involved here, as are many nation states and large corporations. |
94 |
> You'd be surprised what youd find in a modern usb stick, should you take |
95 |
> it into a class 6+ clean-room for analysis. The lower the particle count |
96 |
> the more fantastic the tools |
97 |
> to open up silicon and look deeply into what is actually going on. |
98 |
> This is why folks love those classified research facilities that have |
99 |
> govt contract and folks hanging around. Lots of very, very cool toys |
100 |
> you just do not hear about...... Way beyond microscopes built by |
101 |
> physicist..... |
102 |
|
103 |
Actually it is not that modern. ~5 year old Intenso 2GB. I'd be surprised if |
104 |
booting from the stick prevents partition detection of another USB drive, |
105 |
but who knows? Maybe I should burn the iso instead and boot that one ;-) |
106 |
|
107 |
> Prolly not your issue, but still present. Cheap ass usb vendors often |
108 |
> have corner issues that are unintentional, that is why well recognized |
109 |
> vendors of SS memory are the best to deal with, for consistency of |
110 |
> behavior. |
111 |
> |
112 |
> I'd use as many different tools as you can find and read the vendor & |
113 |
> silicon manufacturer's docs to see what you are really dealing with to |
114 |
> ferret out this weirdness. (it's a darn time sync, just so you know). |
115 |
> |
116 |
> |
117 |
> [1] http://www.cleanroom.byu.edu/particlecount.phtml |
118 |
> |
119 |
> hth, |
120 |
> James |
121 |
|
122 |
Thanks, |
123 |
Jörg |