Re: [gentoo-user] Re: Partition of 3TB USB drive not detected

[james <garftd@verizon.net>]

On 07/31/2016 12:56 PM, Jörg Schaible wrote:
> Jörg Schaible wrote:
>
>> Hi Daniel,
>>
>> thanks for your response.
>>
>> Daniel Frey wrote:
>>
>> [snip]
>>
>>> I can only think of two reasons, the kernel on the livecd doesn't
>>> support GPT (which is unlikely)
>>
>> That would be really strange. However, how can I prove it?
>>
>>> or you're booting a 32-bit kernel live
>>> USB. I am reasonably certain for drives > 2TB a 64-bit kernel and GPT
>>> are required.
>>
>> No, I've always chosen 64-bit kernels. I wonder what is so special about
>> this partition ...
>
> Currently I wonder, why my system can find the partition at all:
>
> ======================== %< ========================
> # gdisk -l /dev/sdi
> GPT fdisk (gdisk) version 1.0.1
>
> Partition table scan:
>   MBR: protective
>   BSD: not present
>   APM: not present
>   GPT: not present

If you have seen my recent thread, much of this automounting during 
boot(strapping) is flaky that is much of what I have been searching out
is a default (magical) partitioning schema that will eventually lead to
clear documents on the current state of affairs not only with old versus 
new motherboards (mbr-->efi) and disk (mbr < 2.2T and gpt >2.2T)
but including all sorts of new arm and other embedded (linux) boards.

Different forms of Solid State memory are next on my list, with usb (1.x 
--> 3.x) being top of the SS memory mediums..... (Sorry I do not have 
more atm).


>
> Creating new GPT entries.
> Disk /dev/sdi: 732566646 sectors, 2.7 TiB
> Logical sector size: 4096 bytes
> Disk identifier (GUID): 80C04475-9B51-4A44-A52F-1F165AE02695
> Partition table holds up to 128 entries
> First usable sector is 6, last usable sector is 732566640
> Partitions will be aligned on 256-sector boundaries
> Total free space is 732566635 sectors (2.7 TiB)
>
> Number  Start (sector)    End (sector)  Size       Code  Name
> ======================== %< ========================
>
> However, it's mounted successfully, see system logs:
>
> ======================== %< ========================
> [22735.626752] sd 13:0:0:0: [sdi] 732566646 4096-byte logical blocks: (3.00
> TB/2.73 TiB)
> [22735.629255]  sdi: sdi1
> [23414.066315] EXT4-fs (sdi1): mounted filesystem with ordered data mode.
> Opts: (null)
> ======================== %< ========================
>
> Has anyone ever tried the recovery option of GPT disk to rebuild GPT from
> MBR?

I see some sort of 'auto correction' by gpt technology to convert many 
forms of perceived mbr to gpt to be used by the booting process for 
spinning rust. So this issue is not limited to usb medium. I would also 
point out that I'd look deeply into the usb specs for the vendor of your 
usb sticks, as they do some 'funky things' at the firmware level inside 
many of the newer/faster/larger usb devices. It not just dumb memory 
like the early 1.x devices. Many are slanted to Microsoft business 
strategies. I'm not suggesting that is your current issues. I'm merely 
pointing out that some newer usb sticks are systems themselves complete 
with firmware so the devices looks like dumb memory. Furthermore, the 
silicon vendors provide firmware options to usb sticks vendors (like 
Texas Instruments) but also the vendor add to or change the hidden 
firmware as meets their multifaceted business objects. Sadly, the NSA is 
deeply involved here, as are many nation states and large corporations. 
You'd be surprised what youd find in a modern usb stick, should you take 
it into a class 6+ clean-room for analysis. The lower the particle count 
the more fantastic the tools
to open up silicon and look deeply into what is actually going on.
This is why folks love those classified research facilities that have 
govt contract and folks hanging around. Lots of very, very cool toys
you just do not hear about...... Way beyond microscopes built by 
physicist.....

Prolly not your issue, but still present. Cheap ass usb vendors often 
have corner issues that are unintentional, that is why well recognized 
vendors of SS memory are the best to deal with, for consistency of behavior.

I'd use as many different tools as you can find and read the vendor & 
silicon manufacturer's docs to see what you are really dealing with to 
ferret out this weirdness. (it's a darn time sync, just so you know).


[1] http://www.cleanroom.byu.edu/particlecount.phtml

hth,
James