Skipping partition restore (MBR Only)

[kkptrck]

Hello!

I wanted to clone a legacy Windows 10 (2 partititons: one recovery + one OS). The capture process finished fine and I got the image on FOG (single disk - resizable). When I wanted to deploy it to a host (Dell Optiplex 745) everything went fine, even the partition resizing after I edited the d1.fixed.size.partitions from “:2:2” to “:1” (without the quatations) but after that the following line came up:
Skipping partition restore (MBR Only), please see picture attached.
The system reboots, but then a dash flashes and nothing happens. I suppose somehow the MBR won’t restore to the host from the image.
I’m stuck, so I need a pro’s help. What could cause the problem?

I am running the latest kernel and version of FOG on Debian 9 as of 2019.08.15.
Credentials and rights are set correctly. Everything works fine except for this MBR issue.

[Sebastian Roth]

@kkptrck While the message “Skipping partition restore (MBR Only)” is somehow confusing and shouldn’t be printed in your case I don’t think it’s actually causing your system to fail to boot after deploy.

What is the source? Are source and destination machine similar or same? Legacy BIOS vs. UEFI? SATA / SSD vs. NVMe? Other hardware components? Is the image syspreped?

[kkptrck]

@Sebastian-Roth Thank you for the quick reply! The source host is a completely different UEFI machine but used with CSM support, “legacy only” mode. Captured OS was installed on a regular SATA SSD, no nvme. What do you mean by other hardware components? The image is not syspreped.

I can provide you with these lines from the image’s d1.partitions file, if it helps something:

label: dos
label-id: 0x968b3872
device: /dev/sda
unit: sectors

/dev/sda1 : start=          64, size=     1076291, type=27
/dev/sda2 : start=     1077248, size=   209715713, type=7, bootable

[Sebastian Roth]

@kkptrck Are you sure the source and destination machine are compatible enough to have the same Windows installation (not sysprepped) running on them??

By the way, which version of FOG are you running?

[kkptrck]

@Sebastian-Roth Yes, I am sure, that they are compatible. After deployment to the Dell host I was able to repair the MBR manually and the OS starts up fine. I captured that Dell host, that has been imaged with the bad MBR (and then manually repaired) and even then, the newly deployed same type host could not boot, the dash flashes.

I am running the latest version of FOG as for which is the 1.5.7 version with kernel 4.19.64. I tried both arm and not arm version without success. I will try using older kernel soon.

[Sebastian Roth]

@kkptrck said in Skipping partition restore (MBR Only):

I tried both arm and not arm version without success.

What do you mean by that??

[kkptrck]

@Sebastian-Roth I mean the kernels.

[Sebastian Roth]

@kkptrck Why ARM kernels?!? Dell doesn’t produce ARM platforms right?!?

[kkptrck]

@Sebastian-Roth I was not sure which one to use. I am not such an expert yet in this whole topic…

[Sebastian Roth]

@kkptrck said in Skipping partition restore (MBR Only):

/dev/sda1 : start= 64, size= 1076291, type=27

I have missed one important thing here when you first posted this. The start sector 64 is quite unusual (usually it’s 63 or some other sector but I have not seen 64 yet) and I can imagine this being the cause of your issue. Did you manually do the partitioning?