UEFI deployment issues
I’m trying to restore/deploy a Windows 10 64 Bit UEFI / GPT image to a physical machine with Asus mainboard, Realtek NIC (IPv4) and Intel CPU.
I 1st didn’t find any further information beside the fact that you have to set your UEFI to legacy enabled and secure boot off to make UEFI work. If none legacy is active the system won’t even boot from fog so I enabled legacy option for the realtek nic and I checked that secure boot is disabled. dhcp option 066 is set to correct IP and option 067 is set to undionly.kpxe.
After I set the DHCP options specified in https://wiki.fogproject.org/wiki/index.php?title=BIOS_and_UEFI_Co-Existence (Using Windows Server 2012 (r1 and later) DHCP Policy) the NIC uses also UEFI to boot. SO option 67 is set to ipxe.efi
The issue I got now is that the system is doing (i)PXE boot from fog-server, wiping the disk but failing to restore the gpt /dev/sda1 no mater if I use legacy for UEFI boot mode for NIC. I didn’t get an detailed error why that step did not work.
I’m not sure what I’m doing wrong aka pebcak / which option is not proper set. So any help is welcome.
@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. :-)
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?
default: Windows Other
Multiple Partition Image - Single Disk (Not Resizable)
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.
what George said.
@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.
Why are we changing boot file?
@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.efiand 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
lsblkat the shell, what does it show?
@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.
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 Serial Chassis Serial Number
Chassis Asset Asset-1234567890
Please provide a screenshot of the failing deployment screen.
From what I gather George is on the right track with fixparts though.
I’m in the same state of mind as Tom (body here and brain a bit vacant).
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/sdacommand 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).
@Gunnar Is this a custom white box or is there a model for the problematic computer?
fog: Running Version: 8209 SVN Revision: 5732
OS: 3.19.0-61-generic #69~14.04.1-Ubuntu
What Version of FOG?
What OS is the FOG Server On?
I’m sure there’s more questions, but I’m not 100% here today.