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

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.

@Tom-Elliott latest pull resolved the issue. Appreciate your help on this!

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

@Tom-Elliott no stress, with so many posts it’s normal to miss some 😉

@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 🙂

@Tom-Elliott Thank you. Logging out with 1.5.10.1730 works properly.

@DanCan Hi This is currently a known issue on some motherboards. Honestly not sure what is causing this to happen. I am working on a fix to this issue just haven’t had too much time lately.

@sega said in FOG Multicast on different VLANs:

Is there something that I can look up, to see where the problem is?

Well your router supporting PIM is a good sign. Some routers have a service called igmp proxy or igmp relay, or even igmp snooping (you will find this more on switches, but check). This service typically has a number of interfaces to listen on and then a master interface where your multicast source lives. Its job is to relay the multicast requests to the proper interface.

PIM has two modes sparse and dense, that may be just for switches, I don’t remember. Sparse mode only sends the multicast traffic to the subscriber’s port, where dense just blasts out the muticast to all ports. You want sparse mode if possible, that way only the ports with a multcast receiver will see the traffic and not flood your network.

@george1421 Thanks, George.

@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.

@Tom-Elliott ah, that would work! Sorry, the documentation is such a mish-mash that it’s hard to find answers for some of this stuff!

@Tom-Elliott to note, this has been happening on all our Lenovo L14s laptops (with no LAN ports), tested with 3 different Lenovo USB-C LAN Adaptors

When booting back up, it brings the Blue screen error:

‘Recovery
Your PC couldn’t start properly
After multiple tries, the operating system on your PC failed to start, so it needs to be repaired.
Error code: 0xc0000001
You’ll need to use recovery tools. If you don’t have any installation media (like a disc or USB device), contact your PC administrator or PC/Device manufacturer.
Press Enter to try again
Press F1 to enter Recovery Environment
Press F8 for Startup Settings
Press Esc for UEFI Firmware Settings’

As John mentioned, we used the same LAN adaptor previously and managed to image via FOG successfully before.

i even tried changing the mac address to the default internal laptop mac address after the initial fog image completed (when it shutdowns the laptop) and booted the laptop back up to see if it helps but no luck

@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

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.