Error deploying image to SSD
-
I have an image that was built and captured on a mechanical drive. I swapped out the drive for an SSD and tried to redeploy the image. The deploy failed while restoring partition tables GPT. The Exit Return Code was 4.
I tested the image on a different laptop with a mechanical drive and it deployed without issue.
The computer is an HP Zbook 15U G3. The drive is recognized in bios as I’m able to perform a hard drive error check on it.
-
I experienced the same issue last year but was able to resolve it.
Check your BIOS settings. Make sure that it’s set correctly for the new SSD drive. I had an issue with that.
What’s the OS on the HOST you are trying to re-image?
What version of FOG are you using?
What version of FOG Server are you on?
Did you use sysprep before you captured the original image? -
I just remembered the issue we had dealt with the the setting for the SATA operation in the BIOS. If that doesn’t match from machine to machine it will fail.
You might check those things out.
It definitely sounds like the drive is functioning correctly and that it is a setting issue. I have been able to push SSD images to mechanical and vice versa with Windows 10.
-
The OS is Windows 10 x64.
My FOG version is 1.5.4
I did not use sysprep. This image was created with on the mechanical drive.
The image is set to: Windows 10. Single Disk - Resizeable. Partition - Everything.I tried installing Windows 10 on the blank SSD just to format and add some partitions but the deploy still failed with the same error.
The laptop does not give me any ACHI options in BIOS on the drive. When I try to boot with UEFI devices only FOG will not load so I have to set it to Legacy boot.
-
I ran into the same issue with FOG version 1.5.4. But I believe it was due to the BIOS setting and not FOG specifically. We have several HP laptops in our district that have SSD drives and or mechanical drives. I use the same image on all of them. The only thing I do differently is I sysprep them first.
My procedure is to sysprep all of my machines before I capture the HOST image. Sysprepping certainly has helped insure that you don’t have any issues with deploying images to host machines with unlike hardware. I know sysprepping or not will get into a huge debate. But it hasn’t hurt any of my images.
If you are able to deploy just fine to another host, I would think FOG is working just fine and it’s a setting issue within your BIOS.
@Wayne-Workman Any thoughts?
-
Additional update. I installed Windows 10 off a USB. Captured image successfully. Tried to deploy back to itself and Windows will not start. It comes up with the Automatic Repair screen.
For image settings I used: Multiple Partition, Single Disk not resizable, Partclone Compressed -
I have had this happen before. Usually it’s a setting issue within Windows 10 that has to be addressed. I had a lot of issues imaging the latest version of the Windows 10 kernel. I ended up having to run sysprep and make some modifications to my unattend.xml file. Once I did that it worked well.
I’m sure @Wayne-Workman will have some ideas.
-
@phishphan Please post a picture of the first error you encountered. As well post the contents of the three text files you find in the image directory on your Server:
d1.partitions,d1.minimum.partitions, andd1.fixed_size_partitions -
https://drive.google.com/file/d/1613JgCnNn_mqkwHHFt7T-7kA7e298BF-/view?usp=sharing
d1.partitions:
label: gpt label-id: 56CE61A2-3D37-4F14-8AE0-A0084F00A7A5 device: /dev/sda unit: sectors first-lba: 34 last-lba: 976773134 /dev/sda1 : start= 2048, size= 921600, type=DE94BBA4-06D1-4D40-A16A-BFD50179D6AC, uuid=F2461728-72A6-4200-93E7-B1159265B72C, name="Basic data partition" /dev/sda2 : start= 923648, size= 204800, type=C12A7328-F81F-11D2-BA4B-00A0C93EC93B, uuid=2104822C-DD09-4840-B543-67340B8E099B, name="EFI system partition" /dev/sda3 : start= 1128448, size= 32768, type=E3C9E316-0B5C-4DB8-817D-F92DF00215AE, uuid=5AEC1D8F-C565-4809-8EAC-A996FCA88367, name="Microsoft reserved partition" /dev/sda4 : start= 1161216, size= 973700027, type=EBD0A0A2-B9E5-4433-87C0-68B6B72699C7, uuid=9A8688F9-4EF1-4550-B220-00E1FE21B447, name="Basic data partition" /dev/sda5 : start= 974862336, size= 1908736, type=DE94BBA4-06D1-4D40-A16A-BFD50179D6AC, uuid=CAEE35CD-7BE7-4432-9B68-DE060AF1A69E, attrs="RequiredPartition GUID:63"d1.minimum partitions
label: gpt label-id: 56CE61A2-3D37-4F14-8AE0-A0084F00A7A5 device: /dev/sda unit: sectors first-lba: 34 last-lba: 976773134 /dev/sda1 : start= 2048, size= 921600, type=DE94BBA4-06D1-4D40-A16A-BFD50179D6AC, uuid=F2461728-72A6-4200-93E7-B1159265B72C, name="Basic data partition" /dev/sda2 : start= 923648, size= 204800, type=C12A7328-F81F-11D2-BA4B-00A0C93EC93B, uuid=2104822C-DD09-4840-B543-67340B8E099B, name="EFI system partition" /dev/sda3 : start= 1128448, size= 32768, type=E3C9E316-0B5C-4DB8-817D-F92DF00215AE, uuid=5AEC1D8F-C565-4809-8EAC-A996FCA88367, name="Microsoft reserved partition" /dev/sda4 : start= 1161216, size= 330329656, type=EBD0A0A2-B9E5-4433-87C0-68B6B72699C7, uuid=9A8688F9-4EF1-4550-B220-00E1FE21B447, name="Basic data partition" /dev/sda5 : start= 974862336, size= 1908736, type=DE94BBA4-06D1-4D40-A16A-BFD50179D6AC, uuid=CAEE35CD-7BE7-4432-9B68-DE060AF1A69E, name="attrs="RequiredPartition GUID:63"d1.fixed size partitions
:2:3:1 -
@phishphan Issue here is that you have a second recovery partition (
type=DE94BBA4-06D1-4D40-A16A-BFD50179D6AC) as fifth partition. FOG is not able to move that partition around and therefore cannot actually shrink your layout to fit on the smaller disk.Let’s do the maths. sda5 starts at sector 974862336 and is at least 1908736 sectors in size: (974862336 sectors + 1908736 sectors) * 512 bytes sector size = 500106788864 bytes ~ 465.76 GBytes
That’s about the size of disk you need to be able to deploy this particular disk layout to it. In case you would remove the fifth partition (not saying you should as I don’t know your setup enough) the maths would be: (1161216 + 330329656) * 512 ~ 158.07 GBytes