@JeremyBrown Are you still having this issue?
The fog log is saying that the host has multiple macs

If it’s still happening I will gladly help you use the fogApi powershell module to find the duplicate macs and how to fix it from there.

Issue fixed with 1.5.10.15

@alexamore90 Did the installer finish all the way to the end? When running it there is a point where you need to open the browser and let it populate the database. If you skip this the installer will fail and needs to be run again.

The node offline sounds like the installer didn’t finish properly.

@tomynocker I have continued making changes with different init.xz files. I have gotten fog to detect the md126 raid, but I don’t know why it can’t capture or restore images.

@george1421 That’s what I am looking for… What guides do I need to follow and where is the script? It would stay DHCP so I can use it anywhere

@frobishant32 There is a couple of things going on here.

Your dnsmasq configuration is only setup for bios based computers. Look at this tutorial here to see how to configure dnsmasq for proxy dhcp. Understand this is not what you need, but look at the section with the pxe-service entries for the uefi settings : https://forums.fogproject.org/topic/12796/installing-dnsmasq-on-your-fog-server?_=1699482367667

The second issue you have is that when iPXE boots it once again does a dhcp query to find the IP address of the “what it assumes” is the fog server. So what ever dhcp has for options 66 and 67 will be used to find the fog server. This next part is a little complicated but let me explain. When iPXE boots it runs an internal script that the fog developers embedded in the FOG version of iPXE. The script is pretty much here: https://github.com/FOGProject/fogproject/blob/master/src/ipxe/src/ipxescript

#!ipxe isset ${net0/mac} && ifopen net0 && dhcp net0 || goto dhcpnet1 echo Received DHCP answer on interface net0 && goto proxycheck :dhcpnet1 isset ${net1/mac} && ifopen net1 && dhcp net1 || goto dhcpnet2 echo Received DHCP answer on interface net1 && goto proxycheck :dhcpnet2 isset ${net2/mac} && ifopen net2 && dhcp net2 || goto dhcpall echo Received DHCP answer on interface net2 && goto proxycheck :dhcpall dhcp && goto proxycheck || goto dhcperror :dhcperror prompt --key s --timeout 10000 DHCP failed, hit 's' for the iPXE shell; reboot in 10 seconds && shell || reboot :proxycheck isset ${proxydhcp/next-server} && set next-server ${proxydhcp/next-server} || goto nextservercheck :nextservercheck isset ${next-server} && goto netboot || goto setserv :setserv echo -n Please enter tftp server: && read next-server && goto netboot || goto setserv :chainloadfailed prompt --key s --timeout 10000 Chainloading failed, hit 's' for the iPXE shell; reboot in 10 seconds && shell || reboot :netboot chain tftp://${next-server}/default.ipxe || goto chainloadfailed

As I said this script looks to what dhcp settings are and then uses that to chain to load default.ipxe.

So you will need to adjust this script and rebuild ipxe if you want to change the behavior of ipxe as it boots from fog. Maybe something like this edit

#!ipxe isset ${net0/mac} && ifopen net0 && dhcp net0 || goto dhcpnet1 echo Received DHCP answer on interface net0 && goto proxycheck :dhcpnet1 isset ${net1/mac} && ifopen net1 && dhcp net1 || goto dhcpnet2 echo Received DHCP answer on interface net1 && goto proxycheck :dhcpnet2 isset ${net2/mac} && ifopen net2 && dhcp net2 || goto dhcpall echo Received DHCP answer on interface net2 && goto proxycheck :dhcpall dhcp && goto proxycheck || goto dhcperror :dhcperror prompt --key s --timeout 10000 DHCP failed, hit 's' for the iPXE shell; reboot in 10 seconds && shell || reboot :proxycheck isset ${proxydhcp/next-server} && set next-server ${proxydhcp/next-server} || goto nextservercheck :nextservercheck isset ${next-server} && goto netboot || goto setserv :setserv echo -n Please enter tftp server: && read next-server && goto netboot || goto setserv :chainloadfailed prompt --key s --timeout 10000 Chainloading failed, hit 's' for the iPXE shell; reboot in 10 seconds && shell || reboot :netboot chain tftp://192.168.21.82/default.ipxe || goto chainloadfailed

That chain update will then ignore what dhcp is telling ipxe and it will load always from the 21.82 address.

Here is a tutorial on rebuilding ipxe. https://forums.fogproject.org/topic/15826/updating-compiling-the-latest-version-of-ipxe

I’m pretty sure you can get to what you need with the above info. I would try the dnsmasq settings first before going down the ipxe edit route.

@george1421: I cannot launch the FOS Linux engine.

I was using the Factory image that came on the device from Lenovo. It was Win 10 and I updated it to Win 11 and we were getting the issues.

I wiped it clean, and loaded a new instance of Win 11, and everything worked fine afterwards. Looks like after disabling Secure Boot, all other issue were with the device. We now have a working images. Thank you for all the help.

@george1421 I updated the FOG Linux Kernel to the newest one and tried using an unmanaged switch but the problem still remains.

@luisgmarinr What you are telling me and what I see on the screen is not the same. Some of my confusion is that I don’t use virtual box so it may be something unique to VB.

You tell me the FOG server is at 10.0.2.15, but from your initial screen shot that is the IP address being given to the pxe booting computer.

The firmware is being told the next server (pxe boot server) is at 10.0.2.4. The next server field should point to the fog server IP address. Its also being told to boot win.pxe and that is not a FOG boot loader.

So lets start to debug this by identifying what device is 10.0.2.4.

Also what device is the dhcp server for your network? That device appears to be giving out bad information.

Awesome. Thanks for the help!

@Tauric said in TFTP Timeout:

(and took less than 10 minutes lol)

Well I was taking into account for slow speeds between keyboard and chair…
Glad you have it worked out. DNSMASQ should work flawlessly in your environment.

@ludlud Do all the machines come back on or just some of them?

Check the log in /var/log/fog/fogscheduler.log to see if jobs are somehow scheduled - like a plain WOL type job.

@george1421 Just thinking outside the box as it makes 0 sense for it to be “just these network cards”

I suppose the “real” test would be seeing if outside of this room if the same problem happens?

I know not simple, but if you can move the whole room to an area where we know this issue doesn’t currently exist, and it shows, then it’s likely specific to this equipment. If it doesnt’ show up, it’s likely something specific to that particular room.

@Tom-Elliott
Habit, simply habit. I looked back at the wiki documentation and it definitely does not say to use sh. I do apologize for the confusion and hopefully this helps someone in the future.

@boros

I want to transfer the “Gold” Images from the server in the other site. Can I just copy and paste the Images Folder from from the other Linux Machine?

The short answer is yes, but there is something you need to know.

FOG Images are made up of two components. The first is the raw data files that are kept in /images directory on your fog server. The second part is the metadata kept in the database. You need both to make the image functional. You can copy the files over by hand, but you will need to either recreate the metadata on the target system by hand (not a difficult task) or export the the image definitions from the source computer and import them on the destination computer

Now one other tidbit that is not supported by the developers, but it works. If on your master server you add the remote fog server as a storage node. The main fog server will be a master node and the remote server is a storage node (just in the context of this configuration), the master node will copy any image marked as exportable all storage nodes in its storage group. This will get the raw images over to the target system using the standard fog image replication. But the thing it doesn’t do is copy over the image definitions. You will need to do this using the export and import method, or by manually creating the image definitions by hand. Using this method you can have golden images pushed out by HQ and each site will still be able to create their own golden images too.