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
