Skip to main content

Cannot select 1MB offset ATI WinPE

Thread needs solution

Hi there,

Today I moved a spinning disk to an SSD, using the Mustang WinPE solution. As usual, I tried to restore the first partition (A GPT system reserved partition) with an offset of exactly 1MB, but I couldn't. Whether for a restore, or when I attempted to create a partition with the Add new disk tool, the tool wouldn't accept 1MB. It would convert it to something like 0.998 or about. It was doing the same thing until 100MB (which it would convert to 99.998 or something like that). I ended up using 102MB which it kept as is finally. So I was able to be confident my first partition would be aligned.

Has anybody observed this?

0 Users found this helpful

On GPT systems, you will need to prepare the disk with a Windows recovery drive or installation disk before performing the recovery with Acronis. Otherwise you end up with a nonstandard partition layout, possible boot issues, and lose access to Windows repair tools when booting Windows.

If your using the MustangPEBuilder 2 ADK 64, replace the following line in winpeshl.ini

"%SYSTEMDRIVE%\Program Files\A43\a43.exe"

with

"%SYSTEMDRIVE%\Program Files\Acronis\TrueImageHome\TrueImage_starter.exe"
cmd.exe

and rebuild your WinPE. This will automatically launch True Image and a Command prompt when you boot your WinPE.

Connect the SSD to your system.
Open an administrator command prompt and type the following commands.

diskpart
list disk
select disk 0 (Replace 0 with the number that corresponds to the SSD disk)
clean
convert gpt
create partition primary size=450 (Enter the size of original Winre in MB)
create partition efi size=260 (Enter the size of original ESP in MB)
create partition msr size=128
exit

Windows will automatically set an offset of 1024KB when the partitions are created.

Reboot into the Acronis rescue environment and restore each partition to its corresponding location.
Performing a disk mode restore or using the "Add New Disk" function will result in the MSR partition being incorrectly placed as the first partition on the disk.

Attachment Size
188954-114535.png 134.03 KB
188954-114538.png 53.33 KB
188954-114541.png 80.1 KB
188954-114544.png 110.05 KB
188954-114547.png 128.65 KB
188954-114550.png 129.72 KB
Joey wrote:
On GPT systems, you will need to prepare the disk with a Windows recovery drive or installation disk before performing the recovery with Acronis. Otherwise you end up with a nonstandard partition layout, possible boot issues, and lose access to Windows repair tools when booting Windows.

It actually worked out fine. With a 102MB offset, the restore went well. Upon reboot, the computer detected some startup issues but repaired it by itself without the Windows installation DVD. I suspect that the change of layout and/or the fact I suppressed the original recovery partitions created an issue with the boot records and the computer had to repair them.

Open an administrator command prompt and type the following commands.

diskpart
list disk
select disk 0 (Replace 0 with the number that corresponds to the SSD disk)
clean
convert gpt
create partition primary size=450 (Enter the size of original Winre in MB)
create partition efi size=260 (Enter the size of original ESP in MB)
create partition msr size=128
exit

Yeah I am aware of this workaround, thanks... but Acronis should let you specify the offset without problem. At least, it lets you do this perfectly on an MBR disk.

Performing a disk mode restore or using the "Add New Disk" function will result in the MSR partition being incorrectly placed as the first partition on the disk.

Ah, I see. This would explain that. Well, again the restore went well with a 102MB offset (go figure), and I didn't lose the Windows startup auto-repair.

Thanks for the guide!

Ok.
But your partitions would have been aligned without changing your offset to 102MB. Acronis is taking into account the 17KB offset it places before the MSR partition.
1024-17=1007
1007/1024=0.983 offset visible from Acronis rescue media.

I included the other steps because I have had mixed results and unexpected behavior after recovery on different systems. Preparing the disk beforehand eliminated all those issues.

I understand the calculation: 17KB used for the Protective MBR (1 sector for legacy compatibility) plus the GPT header (33 sectors) http://en.wikipedia.org/wiki/GUID_Partition_Table ). That makes a total of 34 sectors of 4096 bytes or 17KB...

I don't understand how would the disk be aligned with a .983 offset? 1007x1024=1031168 which is not a multiple of 4096 unless ATI calculates the offset starting from the end of the partition table (end of the 34th sector). But then why would ATI calculate the offset that way?

Also, why would this adjustment be made until 101MB (or 100MB I don't remember now), but then would switch to whole MB number starting at 102MB...

Note that I was restoring to an unallocated disk (it was not partitioned by "add new disk"), so in theory there was no MSR partition yet.
When the disk is completely unallocated, there is no partition, and no MSR.

I think the behavior of the recovery CD offset calculated UI is very confusing...

I agree 100% that the representation from the recovery media is confusing. It just has something to do with the way it perceives and accounts for the 17KB protective member.

The following screen shot shows the results of a recovery to an unallocated GPT disk (No MSR).

After recovery the partition is aligned with a 1024KB offset.

Attachment Size
189128-114556.png 92.13 KB

Ah right! These screenshots are really helping!

The UI is talking about "free space before", not about "offset" ... I interpreted this to mean "offset" but clearly it is not the same thing! So since there are already 17KB occupied, add 1007KB of "free space" and you get an *offset* of 1MB. Gee, Acronis! There should be a better way to show this for people anxious to get the well known and documented 1MB offset right!

Oh well, I lost a few MB in this, not a bit deal!

Thank you for the follow up! Good to know for next time!

As a new user about to go through the same migration to a new, smaller SSD I had a quick question while reading through the thread:

My HDD has a C: and D: (data drive) partition on it in addition to the other UEFI/MSR structure. The D: drive is completely empty at this point and do not want to migrate this to the new drive. Can I simply just leave this out when pre-provisioning the drive and then skip it during the restore? Will it cause any boot issues and if so will windows 10 be able to resolve the issue automatically like Pat seems to have experienced?

Great information here guys!