Jump to content











Photo

GPT disk offset

gpt offset

  • Please log in to reply
13 replies to this topic

#1 Tokener

Tokener

    Frequent Member

  • Developer
  • 378 posts

Posted 14 August 2019 - 07:03 PM

dear friends & members

when I convert a MBR-disk to GPT by DiskPart the program returns:

 

 

 

select disk=5
convert GPT noerr

Microsoft DiskPart-Version 6.1.7601
Copyright (C) 1999-2008 Microsoft Corporation.

Datenträger 5 ist jetzt der gewählte Datenträger.

  Partition ###  Typ               Größe    Offset
  -------------  ----------------  -------  -------
  Partition 1    Reserviert          32 MB    17 KB

I guess the resulting partition 1 is a MSR-partition(?)

I wonder why DiskPart sets offset to 17KB where it should be 1024KB (IMHO).

Does this (17KB setting) stand against correct allignment or are there different rules on GPT disk?

 

Thanks in advance   T.

 

 

 



#2 alacran

alacran

    Platinum Member

  • .script developer
  • 2710 posts
  •  
    Mexico

Posted 14 August 2019 - 09:42 PM

Hello my good friend, I do not have a big experience with GPT partitioned and formated disks, as I always prefer MBR partitioned and formated disks, but as it seems to me the disk in your test was basically with only that single partition (maybe a USB stick), let me suggest you to clean the disk first and repartition it as GPT and then compare.

 

Before and after doing this you can use BootIce (Parts Manage tab) to see partitions info (make a picture of both, if you want) and this will let you compare.

 

Also remember a USB stick MBR FAT-32 (active) formated is capable to MBR or UEFI boot. (the best option to cover both booting ways)

 

alacran


  • Tokener likes this

#3 Tokener

Tokener

    Frequent Member

  • Developer
  • 378 posts

Posted 15 August 2019 - 01:11 PM

 

 

 

hello alacran

thanks for your suggestions.

 

To provide some more details:
 

you have a MBR vDisk (attached)

no partitions

you convert this empty disk to GPT as shown in post#1

the resulting partition has offset 17KB

this partition was created by DiskPart (unintended by me)

 

 

just made a test with USB device:

when converting clean USB disk to GPT no MSR partition is created.

 

 

the conclusion could be: the MSR partition is only created when vDisks are converted.

 

but the questions remain:

why does DiskPart use this offset (17KB) ?

does this stand against correct allignment ?

 

regards   T.

 

 

 



#4 Wonko the Sane

Wonko the Sane

    The Finder

  • Advanced user
  • 16066 posts
  • Location:The Outside of the Asylum (gate is closed)
  •  
    Italy

Posted 15 August 2019 - 03:16 PM

@ReTokener

Use the gpt fdisk to examine the (converted) disk:
http://www.rodsbooks.com/gdisk/
http://www.rodsbooks...alkthrough.html
and report.
Diskpart is not "exact", as it doesn't output the exact offset (in bytes), nor the exact type/GUID of the partition it created.

:duff:
Wonko
  • Tokener likes this

#5 Tokener

Tokener

    Frequent Member

  • Developer
  • 378 posts

Posted 15 August 2019 - 07:18 PM

 

 

 

Thank you Wonko

 

I tested the disk by gdisk, this is the output:

(disk is the same as in post#1 but one more partition is created in the meantime)

 

gdisk64.exe -l 4:
GPT fdisk (gdisk) version 1.0.4

The protective MBR's 0xEE partition is oversized! Auto-repairing.

Partition table scan:
  MBR: protective
  BSD: not present
  APM: not present
  GPT: present

Found valid GPT with protective MBR; using GPT.
Disk 4:: 4096000 sectors, 2.0 GiB
Sector size (logical): 512 bytes
Disk identifier (GUID): 16F1AC60-F15B-4EE0-8DF3-D274B6DD807D
Partition table holds up to 128 entries
Main partition table begins at sector 2 and ends at sector 33
First usable sector is 34, last usable sector is 4095966
Partitions will be aligned on 2-sector boundaries
Total free space is 3006397 sectors (1.4 GiB)

Number  Start (sector)    End (sector)  Size       Code  Name
   1              34           65569   32.0 MiB    0C01  Microsoft reserved ...
   2           67584         1091583   500.0 MiB   0700  Basic data partition

 

regards   T.

 

PS

DiskPart displayed the same GUID as gdisk:

 

Datenträger-ID: {16F1AC60-F15B-4EE0-8DF3-D274B6DD807D}
 

 

 

 

 

 



#6 Wonko the Sane

Wonko the Sane

    The Finder

  • Advanced user
  • 16066 posts
  • Location:The Outside of the Asylum (gate is closed)
  •  
    Italy

Posted 16 August 2019 - 04:17 PM

So Disk 4 is 2.0 GiB in size, this should mean that it *somehow* flies below the radar of the Registry settings for alignment.
 
Check them, but they should be:
http://reboot.pro/to...o-gpt/?p=186428
 
In theory, that MSR partition should have been aligned to 128 LBA or 65536 bytes.
 
The first partition is not aligned to the "old" standard (Cylinder/head), nor to the "new" one (multiple of 4096 bytes) and simply goes "as soon as it will fit", i.e. right after the 33 sectors *needed* for the GPT disk structure.
 
It is possible that for one of the usual reasons (mainly stupidity,  laziness or sloppiness) the good MS guys that made the convert program didn't think to check the Registry.
 
And - seemingly - this non-alignment creates also the second partition not aligned, 67584*512=34603008 which is not any "normal" value.
 
However using the noerr paramter is not exactly smart, maybe if you try without it the tool will provide some feedback. :dubbio:

The fact that gdisk found an error in the MBR protective partition entry size might mean that there were actually some errors in the conversion. :unsure:
 
BTW and JFYI the "16F1AC60-F15B-4EE0-8DF3-D274B6DD807D" is the DISK GUID, it is not the volume/partition GUID, which is represented in gdisk as 0C01 (abbreviated) which is actually MSR or "E3C9E316-0B5C-4DB8-817D-F92DF00215AE". (I wanted to be sure it was actually a MSR as "Reserviert" might have been *any* "reserved" type, even if likely the good MS guys only consider "their own" ID to be actually "reserved" it is always better to make sure).

:duff:
Wonko

#7 Tokener

Tokener

    Frequent Member

  • Developer
  • 378 posts

Posted 16 August 2019 - 10:08 PM

 

 

 

Thank you very much for your efforts Wonko

 

 

However using the noerr paramter is not exactly smart, maybe if you try without it the tool will provide some feedback. :dubbio:

The fact that gdisk found an error in the MBR protective partition entry size might mean that there were actually some errors in the conversion. :unsure:
 

 

same situation without "NOERR"

created a 81gb disk

converted to GPT

 

gdisk64 -l 4:
GPT fdisk (gdisk) version 1.0.4

The protective MBR's 0xEE partition is oversized! Auto-repairing.

Partition table scan:
  MBR: protective
  BSD: not present
  APM: not present
  GPT: present

Found valid GPT with protective MBR; using GPT.
Disk 4:: 165888000 sectors, 79.1 GiB
Sector size (logical): 512 bytes
Disk identifier (GUID): 1C3064D2-529D-44F6-BA36-A1A5ADC8FA4D
Partition table holds up to 128 entries
Main partition table begins at sector 2 and ends at sector 33
First usable sector is 34, last usable sector is 165887966
Partitions will be aligned on 2-sector boundaries
Total free space is 4029 sectors (2.0 MiB)

Number  Start (sector)    End (sector)  Size       Code  Name
   1              34          262177   128.0 MiB   0C01  Microsoft reserved ...
   2          264192       165885951   79.0 GiB    0700  Basic data partition
 

 

one thing was different: the resulting MSR partition was 128mb in size.

 

------------------------------------------------------------------------------------------

Now I went another way:

created a new disk

let gdisk64 convert it

- no MSR partition was created

when I created UEFI partition with Diskpart, offset was 1024kb

 

 

gdisk64 -l 4:
GPT fdisk (gdisk) version 1.0.4

The protective MBR's 0xEE partition is oversized! Auto-repairing.

Partition table scan:
  MBR: protective
  BSD: not present
  APM: not present
  GPT: present

Found valid GPT with protective MBR; using GPT.
Disk 4:: 165888000 sectors, 79.1 GiB
Sector size (logical): 512 bytes
Disk identifier (GUID): 80FBE22E-59AB-4B2D-883C-B34F26AF9595
Partition table holds up to 128 entries
Main partition table begins at sector 2 and ends at sector 33
First usable sector is 34, last usable sector is 165887966
Partitions will be aligned on 2048-sector boundaries
Total free space is 165478333 sectors (78.9 GiB)

Number  Start (sector)    End (sector)  Size       Code  Name
   1            2048          411647   200.0 MiB   EF00  EFI system partition

 

when creating UEFI partition with gdisk offset was 1024kb.

 

 

... there were actually some errors in the conversion. :unsure:

 

another question would be: what caused these errors?

 

but I don't want to be that curious ...

 

thanks a lot   T.

 

 

 

 



#8 Wonko the Sane

Wonko the Sane

    The Finder

  • Advanced user
  • 16066 posts
  • Location:The Outside of the Asylum (gate is closed)
  •  
    Italy

Posted 17 August 2019 - 09:55 AM

Well the point revolves around the specific "conver gpt" command respecting (or ignoring)  the settings in the Registry, "normal" diskpart operation should respect the contents of HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\VDS\ALIGNMENT.
 
About gdisk error, I was talking about the:
"The protective MBR's 0xEE partition is oversized! Auto-repairing."
 
If you happen to repeat the experiment, make a copy of the MBR just after the diskpart conversion and one after gdisk has "corrected" the protective entry.
 
Gdisk seemingly "detects and respects" *whatever* is already there, i.e.:

Partitions will be aligned on 2-sector boundaries

vs.
 

Partitions will be aligned on 2048-sector boundaries

 
Of course  only a MS originated tool will automatically create a (senseless) MSR partition, evidently, although the "canonical" size of the MSR partiton is actually 128 MB, there is a mechanism that "scales its size down" on smallish devices, which confirms the senselessness of that partition (which most probably is only used by Windows Update when making a "major" upgrade as temporary storage.
 
:duff:
Wonko
  • Tokener likes this

#9 Tokener

Tokener

    Frequent Member

  • Developer
  • 378 posts

Posted 17 August 2019 - 12:39 PM

 
 

@Wonko

 

If you happen to repeat the experiment, make a copy of the MBR just after the diskpart conversion and one after gdisk has "corrected" the protective entry.

I did repeat the experiment and compared the MBRs by HEX Editor, but can't get clues.  :o

 

Attached File  AfterConversion.jpg   103.8KB   0 downloads  Attached File  AfterCorrection.jpg   105.83KB   0 downloads

 

 

Regards  T.

 

 

 



#10 Wonko the Sane

Wonko the Sane

    The Finder

  • Advanced user
  • 16066 posts
  • Location:The Outside of the Asylum (gate is closed)
  •  
    Italy

Posted 17 August 2019 - 02:01 PM

@Wonko
I did repeat the experiment and compared the MBRs by HEX Editor, but can't get clues.  :o
 
attachicon.gifAfterConversion.jpg  attachicon.gifAfterCorrection.jpg
 
 
Regards  T.


Sure, get a hex editor with a MBR template/parsing script, shameless plug:

http://reboot.pro/to...-hexer-scripts/

:duff:
Wonko

#11 Tokener

Tokener

    Frequent Member

  • Developer
  • 378 posts

Posted 18 August 2019 - 09:19 AM

 

 

 

@Wonko

 

Sure, get a hex editor with a MBR template/parsing script, shameless plug:

 

I did so and could compare output of the plugin:

Attached File  MBR after diskpart conversion.pdf   26.79KB   2 downloads  Attached File  MBR after gdisk correction.pdf   26.81KB   3 downloads

 

found differences in "Signature" and "Num LBA" values.

Nevertheless I can't find conclusions. :(

 

Sorry   T.



#12 Wonko the Sane

Wonko the Sane

    The Finder

  • Advanced user
  • 16066 posts
  • Location:The Outside of the Asylum (gate is closed)
  •  
    Italy

Posted 18 August 2019 - 11:13 AM

Hmmmm. :dubbio:

The difference in Disk Signature is "queer" (shouldn't happen as it might create issue with a number of things that are based on it), as a matter of fact it is not a "difference",  in the second file the signature is zeroed out, which is even more "queer",  as a NT system as soon as you connect a disk will write a (new) disk signature if is 0x00000000 or if it is the same as an already connected disk. 

I.e. what you posted is a logical impossibility :w00t: :ph34r:, unless the disk has been taken "offline" (by you or by the gdisk program) or - and I believe this is the case at hand - being a virtual disk (i.e. a disk image) it is *somehow* not (yet) been "really-really" connected.

If you try to mount/attach it so that you can see it in Disk Manager and then re-check the MBR a Disk Signature should appear.

 

In any case it is a good finding  :)  and confirms how before using *any* tool it is a good idea to make a copy of the MBR.

 

The LBA change is even worse :ph34r:, IMHO.

The first file sets the start of the LBA @1 (correct) and the size of the protective partition to 0xFFFFFFFF. i.e. 4294967295, so for all a whole lot of programs might believe the disk size is no less than 4294967295+1=4294967296, ie. 4294967296*512=2199023255552 bytes or 2048 GiB/2.2TB! 

The second file has a corrected value of 0x09E33FFF so 165887999+1=165888000 and 165888000*512=84934656000 or 79.1 GiB which sounds just right.

Any program actually believing the protective partition entry data may attempt to write to sectors that do not exist on the device or however report wrong information on size of the device.

 

:duff:

Wonko



#13 Tokener

Tokener

    Frequent Member

  • Developer
  • 378 posts

Posted 18 August 2019 - 12:46 PM

 

du hast recht, sorry, ich habe das in # 3 nicht so gut geklärt

 

Grazie Wonko

 

I believe this is the case at hand - being a virtual disk

... you are right, sorry, I was not clarifying this too good in #3.

 

 

The first file sets the start of the LBA @1 (correct) and the size of the protective partition to 0xFFFFFFFF. i.e. 4294967295, so for all a whole lot of programs might believe the disk size is no less than 4294967295+1=4294967296, ie. 4294967296*512=2199023255552 bytes or 2048 GiB/2.2TB!

 

"The first file" is in our case "DiskPart".

Is this the conclusion: "Do not convert with DiskPart if you want to write correct values to (v)Disk" ?

 

Regards   T.



#14 Wonko the Sane

Wonko the Sane

    The Finder

  • Advanced user
  • 16066 posts
  • Location:The Outside of the Asylum (gate is closed)
  •  
    Italy

Posted 18 August 2019 - 01:26 PM

 

"The first file" is in our case "DiskPart".

Is this the conclusion: "Do not convert with DiskPart if you want to write correct values to (v)Disk" ?

 

Regards   T.

 

 

Yep :), more loosely, NEVER trust any program until you have verified its results.

 

To be fair with the good MS guys (even if they don't really-really deserve it) you are attempting to do something that maybe isn't within the "intended scope" of the command, convert a smallish non-partitioned MBR disk (or vdisk) to GPT.

 

Which in itself makes very little sense, if you have an existing disk with one or more volumes/partitions on it and - presumably - some valuable contents in it/them, then you want to "convert" it, but creating a brand new MBR disk only to immediately (i.e. before having partitioned it nor put any content in it) convert it to GPT seems to me more complicated than just making a brand new GPT disk. ;)

 

Even if this would probably involve (on command line) to use Powershell:

https://www.thomasma...torage-cmdlets/

 

Initialize-Disk 1 -PartitionStyle GPT

 

I mean, most probably a "real world" (even if "virtual") MBR disk would have a partition starting at either LBA 63 (old) or LBA 2048 and most probably the (still stupid) diskpart  convert gpt wouldn't behave the same withe the (also stupid) MSR partition. :unsure:

 

:duff:

Wonko


  • Tokener likes this





Also tagged with one or more of these keywords: gpt, offset

0 user(s) are reading this topic

0 members, 0 guests, 0 anonymous users