UEFI deployment issues

[Gunnar]

fog: Running Version: 8209 SVN Revision: 5732
OS: 3.19.0-61-generic #69~14.04.1-Ubuntu

[Wayne Workman]

@Gunnar Is this a custom white box or is there a model for the problematic computer?

[george1421]

I’m in the same state of mind as Tom (body here and brain a bit vacant).

Let see…

You can pxe boot in uefi mode into the FOG menu and then get the FOS engine to run on the target computer. You can get this far for both uefi and bios modes, right?

If that is the case, I would schedule another capture/deploy again, but pick the debug option. Then pxe boot the client computer. After a few presses of enter you should be dropped to a command prompt on the target computer. Then run the fixpart /dev/sda command to reset the disk information. If you did pick a debug deploy command then just key in fog on console to start the deployment. You will have to press enter after every step, but it should deploy, or simply reboot the FOS engine (target computer).

[Quazz]

Please provide a screenshot of the failing deployment screen.

From what I gather George is on the right track with fixparts though.

[Gunnar]

The target computer is a custom build system.
Host Hardware Inventory:
System Manufacturer ASUS
System Product All Series
System Version System Version
System Serial Number System Serial Number
System Type Type: Desktop
BIOS Vendor American Megatrends Inc.
BIOS Version 2205
BIOS Date 05/26/2015
Motherboard Manufacturer ASUSTeK COMPUTER INC.
Motherboard Product Name H81M-PLUS
Motherboard Version Rev X.0x
Motherboard Serial Number 151159713501022
Motherboard Asset Tag To be filled by O.E.M.
CPU Manufacturer Intel
CPU Version Intel Pentium CPU G3240 @ 3.10GHz
CPU Normal Speed Current Speed: 3110 MHz
CPU Max Speed Max Speed: 3900 MHz
Memory 7.65 GiB
Hard Disk Model SPCC Solid State Disk
Hard Disk Firmware SAFM12.2
Hard Disk Serial Number 8EFA076309E703894010
Chassis Manufacturer Chassis Manufacture
Chassis Version
Chassis Serial Chassis Serial Number
Chassis Asset Asset-1234567890

[Gunnar]

@george1421 fixpart doesn’t exist but fixparts /dev/sda returns error mbr not found, wich is quiet normal as i’m trying to restore GPT based partition.

@Quazz https://imgur.com/izQ0u3k )

[Wayne Workman]

@Gunnar You’re correct, you don’t need fixparts because it’s a GPT type disk.

Try to set your additional UEFI dhcp policy’s 067 option to realtek.efi and see if you fair better or not.

Also, tell us more about the HDD and the source image. Is the image resizable? How big is the image on the source machine? Is the destination drive a hybrid or completely solid-state?

If you do a debug-deploy on that computer, and type lsblk at the shell, what does it show?

[Tom Elliott]

I’m confused.

Why are we changing boot file?

[george1421]

@Wayne-Workman Just for clarity if the OP is able to run fixparts then PXE booting is not an issue (unless I missed something). Fixparts requires the FOS engine to be running on the target computer.

What is the real issue here?

Sorry for putting it this way, but there is a lot of noise (unimportant information) in the OP. For the OP a screen shot of the exact error is what is needed here. Pictures speak better than words when trying to pinpoint the error.

[Wayne Workman]

what George said.

Screen shot.

[Gunnar]

the image:
Windows10UEFI64bit
default: Windows Other
Multiple Partition Image - Single Disk (Not Resizable)
Everything
39.45 GiB

the target:
SSD as posted below. size about 110 GB so larger then the image.

p.s. I didn’t change the iPXE kernel as the system is already done with boot else I could have executed any of the requested commands.

[Quazz]

Given that it has issues putting back the partition tables, I’m guessing something went wrong in the capture process. Is it possible to recapture the image?

[Gunnar]

@Quazz sometimes the simple ideas are the best ideas. The image seemed to be not OK so that was the reason for all the problem.

I created a new image which I successfully deployed on the machine. Problem solved.