I tried reinstalling the Capone plugin, but that didn’t work.

I checked my other machines that show the fog.capone option and I manually added it in using the New iPXE Menu Entry option with the same values as my other machines. I haven’t tested if this is the solution yet. Here’s a screenshot of my values:
d4f5f292-a652-4796-ad66-2531d9920b01-image.png

@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

Test booting through iPXE vs firmware booting directly to hard drive Swap the hard drives between the dells and stone computers see if the problem moves 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.

@ecoele The fact that dev-branch is in 1700’s this informatino seems to indicate your’e still running the latest stable.

Once you switch to dev-branch you need to pull in the changes:

cd /your/path/to/fogproject git checkout dev-branch git pull cd bin sudo ./installfog.sh -y

Should get you installed.

You may also need to (from the browser) do a “CTRL + SHIFT + R” to do whats called a hard refresh in the browser to get all the latest/new javascript information.

I think I have the same problem and I want to be sure of exactly what I need to do (I don’t know if there is a step-by-step tutorial…).

I boot with a USB-C network adapter on an HP Elitebook. It finds FOG, I have the menu, I choose to deploy an image, and then I get this error message:

IMG_20251106_162705.jpg

Is this the problem in question?
If so, what exactly should I do? I see (link @FlorianLenz ) that I need to replace two files with the new ones, then run the .sh. But isn’t that dangerous for other network boots?

Thank you in advance for your help.

Finally found out why I couldn’t auth over 636, I needed to add my domain’s CA cert to the FOG server’s root cert store. Once I did that I can now use my AD creds over 636 on the web UI and iPXE menu items.

@88fingerslukee Thank you, I promise I will try your project and leave a feedback.

@youzersef What if your router providing next server is pfsense.

What needs to be changed in pfsense? My current settings are that of fog.

Pfsense : 10.22.24.1 : (controls DHCP, next server, etc)
Fog 10.22.24.5 : (Working flawless)
iVentoy : 10.22.24.13

Everything I try is sending client back to pfsense, and then errors because it’s getting the boot file for fog, when it’s expecting iventoy_loader_16000

Thanks ! Time to get this project wrapped up 🙂

@Sebastian-Roth while poking round in the BIOS on some new Dell machines I did find an option called “Force PXE on next Boot” - https://www.dell.com/support/manuals/en-uk/dell-cmnd-config-v3.0/dell_command_configure_cli-v3/-forcepxeonnextboot?guid=guid-85c17652-4a18-4538-8665-e6b3e777d649&lang=en-us

You have to have the dell tools installed, but this would be a possible option.

I know with my current machines when a BIOS update happens it keeps overwriting the boot order so my PXE boot doesn’t happen. Quite annoying!

I don’t know how I’d go about making the FOG Client execute this command before a task reboot though.

@george1421 said in Broken iPXE boot loader:

@Mightmar I wonder if the devs for iPXE has changed something in the ipxe source code to cause this error message about autoexec.ipxe not found. This should be supplied by the fog project add on files. I’ll take a look at the compiler to see if something has changed. You should not see this error.

Reinstalling 1.5.10 will fix the error of the latest build of iPXE. Also you mentioned about a later version of FOG. Yes you can install that over 1.5.10 without issue. It should also have updated (but not the newest version of iPXE).

This is the first post I found searching autoexec.ipxe so replying here for future searchers.

This was an addition in a recent ipxe version, and is meant to be a way to add ipxe based functionality without needing to recompile ipxe in order to edit an embedded script (https://github.com/ipxe/ipxe/discussions/1237#discussioncomment-9847219), I can’t find the post/doc again but I remember reading in one place that ipxe added it as part of the hopes of getting a signed ipxe shim so users could use the signed shim and then use this script to add what they can’t embed. While technically we can create a blank file in /tftpboot/ i.e. just

#!ipxe

which will remove the error during boot, this can then cause kernel panics when loading into FOS. Why it does this is a bit of a mystery at the moment, maybe it’s adding to or replacing another part of our pxe menu scripts that causes something in loading the kernels to lose access to ramdisk drivers. But adding it can break everything, so for the time being, just ignore the error.