@mbghost This error message baffles me. If its happening where I think its happening its not a pxe boot issue. This error happens after you pick an iPXE menu item or if you tell a computer to image.

So you can probably rule out ipxe.efi/snp.efi here.

This error message is generated with FOS linux is booting. The kernel has booted and when it goes to connect to init.xz the format of init.xz is corrupt for some reason.

What version of FOG are you running
What version of “the kernel” are you running?
What version of init.xz are you running (get this from a bios computer that boots. the version of the init will be under the fog logo)

What computer is this happening on (make and model)?
Is it all uefi systems or only from one manufacture?
How much ram does this computer have?
Are you seeing both bzImage and init.xz get transferred completely to the target machine. This will be visible just after you pick an item on the FOG iPXE menu.

To me this error is telling me something is wrong with init.xz or for some reason bzImage is not the right kernel for init.xz

@RAThomas said in UEFI is not booting with Windows DHCP:

The solution for my case was to add this to the client port configuration on my Cisco switch:

Yep, if you are not using port-fast, fast-ftp, mstp, or rstp (or whatever your switch mfg calls it) standard spanning tree takes 27 seconds to start forwarding packets. This timer restarts every time the network link winks, like as the PC starts, iPXE starts up, and then FOS linux starts. FOS linux boots so fast (< 16 seconds), its already given up trying to get an IP address before the ports starts to forward traffic.

@AngryITGuy First let me say I don’t use FOG for image deployment any more since I’ve moved to a different IT group, but if this situation hit my desk I would go through a similar process as below

I have more questions than answers for you. But the good thing here is FOG is imaging these systems and can deploy windows 10 to the hardware without issue. Right away we can rule out fog’s foundational support system being broken because it can deploy win10 and win11 to other hardware and win10 to this stone hardware.

When I debug something new or strange I try to build a truth table in my head of different experiments to see what works and what not works. Something like:

Deploy and boot win10 Dell laptop: Yes
Deploy and boot win11 Dell laptop: Yes
Deploy and boot win10 Stone laptop: Yes
Deploy and boot win11 Stone laptop: No (kind of)

So now to the unknown questions (and I assume these stone laptops are in uefi mode, you mentioned ‘bios’, but your boot loader is ipxe.efi.

On this stone laptops do you have pxe setup as the default boot source or is it the hard drive? This question is to see if the boot is failing if you are booting through ipxe.efi or if the firmware is having a problem finding the boot partition. If you are booting through iPXE see if changing the boot order to the hard drive solves the issue (for this test).

You will need to turn off secure boot for this next step. If you swap the hard drives between the dell and stone computer, does the stone computer boot normally repeated times? Does the dell computer reboot repeated times OK? This check is to see if the problem moves with the hard drive. The question is around if fog combined with the disk controller hardware on the stone doing something to damage the boot sector for win11 when it deploys. The dells works, can you get the stone computers working by deploying to a dell and then transplanting the hard drive to the stone?

If you deploy win10 and then upgrade to win11 on a stone laptop (verify its working 100%) and then capture and deploy to a same make and model computer. Does it boot correctly on the second computer? Can you deploy it to the same computer it was captured from and does it work? This will test if there is something wrong with your win11 image you are trying to deploy to the stone computer.

Lets see how the above goes before we plot the next test.

Just to recap

1. Test booting through iPXE vs firmware booting directly to hard drive
2. Swap the hard drives between the dells and stone computers see if the problem moves
3. Try to capture and deploy using the same hardware. First to like computer if no work, try to deploy to same computer image was captured from.

@chevengur I can tell you how I would go about figuring this this.

1. Take a computer that represents the finished design of how your disk are laid out.
2. Schedule a deployment to that computer, but before you hit the schedule task button, tick the debug checkbox then schedule the deployment. No worries as long as you pick debug mode since it will never get to the deployment phase.
3. Now pxe boot the target computer, it should boot into the FOS linux console. After a few screens of text you need to clear with the enter key you will be dropped to the FOS linux command prompt.
4. From there issue, the efibootmgr command with no parameters. It should print something similar to below (note this is from my laptop)

thunder@lightning:~$ efibootmgr
BootCurrent: 0005
Timeout: 2 seconds
BootOrder: 0005,0004,0000,0001,0002,0003
Boot0000* UEFI BC511 NVMe SK hynix 256GB SN9BN62231050BJ2H 1	HD(1,GPT,d00df89f-1edb-44f8-b325-245b607b2321,0x800,0x100000)/File(\EFI\Boot\BootX64.efi){auto_created_boot_option}
Boot0001* ONBOARD NIC (IPV4)	PciRoot(0x0)/Pci(0x1f,0x6)/MAC(b44,0)/IPv4(0.0.0.00.0.0.0,0,0){auto_created_boot_option}
Boot0002* ONBOARD NIC (IPV6)	PciRoot(0x0)/Pci(0x1f,0x6)/MAC(b440)/IPv6([::]:<->[::]:,0,0){auto_created_boot_option}
Boot0003* UEFI HTTPs Boot (MAC:B445065BDC4B)	PciRoot(0x0)/Pci(0x1f,0x6)/MAC(b445065bdc4b,0)/IPv4(0.0.0.00.0.0.0,0,0)/Uri(){auto_created_boot_option}
Boot0004* debian	HD(1,GPT,d00df89f-1edb-07b2321,0x800,0x100000)/File(\EFI\debian\shimx64.efi)
Boot0005* Ubuntu	HD(1,GPT,d00df89f-1edb-607b2321,0x800,0x100000)/File(\EFI\ubuntu\shimx64.efi)

You can see from this the default BootOrder is 5, 4, 0, 1, 2, 3 this lists the different boot managers found by the firmware.

So it will boot ubuntu first, then debian, the hard drive, onboard nic v4, onboard nic v6, http boot.

Now lets say I wanted debian to boot first I might issue the command.
efibootmgr -o 4,5, 0,1, 2, 3

Now reboot the computer with the reboot command see if it changes the boot order specific to your options.

After you get this worked out, you will need to clean up this deploy task on your fog server so it doesn’t do this moving forward. But for debugging as long as the fos engine doesn’t complete, every time you reboot the computer will enter the FOS debug console. This helps with debugging and tweaking your post install script.