HP UEFI-only machines pxe boot fine, but after deploy, will not boot from HD

[nickscratch]

Hello folks,

I have an issue that started out looking like the UEFI boot issues a bunch of people were having, but I think it might be something different.

We recently got some new HP laptops (very generically called HP Laptop 15z) that do not have legacy boot options. I was able to find info and reconfigure my FOG to boot consistently into PXE, and both capture and deploy tasks seem to complete successfully, but after a deploy, if I let it chain load, rEFInd goes to it’s “about” screen. If I disable netboot and force it to boot from HD, it complains that there is no OS.

I’ve tried all the other exit types as well and none will boot the HD.

I’ve tried this with both old images (Win 10 1809) that have worked flawlessly and new ones (W10 20H2) created on the new hardware.

Specs:

• FOG 1.5.8
• DHCP is a Win2008 server with 66 pointing to FOG IP and 67 set to snponly.efi
• I’m using persistent groups plugin
• I have a custom init but it’s just replacing the register script with a simpler one that only asks the questions we need

I dunno if those last two are even useful or relevant but I’m grasping at straws here. I don’t know what I did to have the system just completely unable to find the OS.

Any insight is appreciated.

[george1421]

@nickscratch I’m going to say if the image makes it to the target computer without an error then FOG isn’t the problem. Understand that is a realtive term because with FOG 1.5.8 (and 1.5.9) there are certain disk configurations that do cause a problem, but it would be apparent during a deploy.

So I have to ask, is the image you are deploying UEFI based or is it BIOS based. The two disk structures are different and not interchangeable. If this is your first uefi image on your campus and you are trying to deploy a standard BIOS image to it I can understand why it won’t boot.

Beyond that if you boot into the Win recovery partition can the recovery tools fix the system so it boots?

[nickscratch]

@george1421 Hi George, Thanks for the reply!

The first images I deployed were BIOS based, but then I realized my mistake and built & captured an image from the offending laptop directly (which is UEFI only) and that also does not boot. I did try the Windows recovery and the tools could not fix the boot problem.

Is there something I need to set on the FOG end to force it into UEFI-based capture? I couldn’t find anything to do that and from what I read elsewhere on the forum here it seemed like FOG figures it out automatically.

Is this a function of incorrect partition format (MBR vs GPT) or is there more going on that differentiates BIOS vs UEFI images where FOG is concerned?

[george1421]

@nickscratch That is interesting if you captured from specific computer and it was efi mode, and then restored to the same model it should work just fine as long as both are in efi mode.

Did you watch the deployment, especially the blue partclone screens to ensure there wasn’t an error deploying?

FOG automatically detects uefi vs bios. It will create the correct disk format based on the captured image.

I see that you are on 1.5.8 with a custom init. The developers will ask you to upgrade to 1.5.9 (probably the dev branch to get the latest patches). If you use the git method its pretty easy to upgrade. Just be mindful before you upgrade if you have a custom init.xz file and its names init.xz that the FOG upgrade/installer will replace that file with the standard init. You really want the inits for 1.5.9.102 (or what ever its called in the dev branch) to address an issue with Win10 20H2 before you go and tweak the inits. If you are just patching the inits with a post init script then you are safe since what ever init you are using will be patched with your fog.man.reg script you have patched.

If you are capturing and deploying to the same hardware model you shouldn’t need to sysprep. If you are deploying this efi image to different hardware models you will need to sysprep the image before capture. Make sure the firmware settings for both the hard drive and secure boot are the same between the two systems. Lastly make sure your source image isn’t protected by bitlocker. Bitlocker will make the cloned system fail to boot.

[nickscratch]

@george1421 So, I am an idiot.

What was happening here is I deployed the old BIOS image, which blew away the GPT designation, and then when I created and captured the new image, the Windows installer never re-applied the GPT. I manually went in with diskpart, wiped the drive, applied GPT, rebuilt the image, captured, deployed, and voila! It boots now.

Jokes on me for trusting the Windows installer I guess.

Thanks for your input George! It actually helped a lot.