@nrey said in i fail to install FOG Fnaf:

I fail to install FOG due to this problem. Can someone help!!!
)

It looks like you’re losing connection. Please make sure you are using a trusted Proxy ID!

@DBCountMan From my memory, yes, that is correct.

Another thing to consider which I have observed in my environment is network congestion. If you are imaging on your production network, especially if the subnets aren’t segmented, you may experience slower than normal imaging speed. If your FOG server is connected to the network at 1Gbps, keep in mind that if you are trying to image 10 workstations connected at 1Gbps, the server will only be able to send/receive at 1Gbps. The more imaging that happens at once, the slower they will all be. That is why I have been looking into getting my FOG server connected at 10Gbps so that it can handle at least 10x1Gbps connections without slowing down.

@mark29 said in PXE-E32: TFTP open timeout:

it screens PXE-E32: TFTP open timeout.

This can be (most commonly) caused by either

DHCP options for that subnet have dhcp options 66 set incorrectly. You have two or more dhcp servers on that subnet and both don’t have all of the setting needed to pxe boot. The tftp service is not running on your fog server.

I would setup a witness computer on the same subnet as the pxe booting computer that witness computer will run wireshark, with a capture filter of port 67 or port 68 or use a display filter of BOOTP. Start wireshark and then pxe boot the target computer until you get the error, then stop the wireshark capture.

Now review in wireshark the OFFER packet. This comes from the dhcp server to the client.

Look to see if you only have one OFFER packet. You should because the pxe error is “Open timeout”. Look at the OFFER packet in the ethernet header verify that both the {next-server} field has the IP address of the FOG server, and the {boot-file} has the proper FOG boot loader. Now look at the DHCP options under option 66 and 67 they should match whats in the ethernet header.

FWIW: I’ve seen soho routers that eventhough you properly configure them, they set themselves (the routers) as the pxe boot server and not what you put in dhcp option 66.

@cul3r0 The https redirect is actually only working for me if I go to the fqdn on http, i.e. http://fog-server.domain.tld will redirect to https but http://fog-server will not redirect.
I’m pretty sure it’s possible to adjust the rules to redirect everything to the fqdn on https. You can probably mess with the rules to make it rewrite anything to go the the fqdn on https

@r00s7a This is most likely an issue with your network infrastructure and not fog. The DHCP offers come from your primary dhcp server. If that DHCP server is not FOG Server then its not something you can solve on the fog server.

Where we have seen sometimes they pxe boot and sometimes not is if you have two dhcp servers on your network. Possibly in a primary / secondary configuration. Confirm that all dhcp servers have dhcp options 66 and 67 set because these settings are not replicated between windows dhcp servers.

@AlleneBrick @alexamore90
Lets clarify further first.

What DHCP server are you using and what is its ip?
What do you want the fog server ip to be?

@El-Fogito said in PXE Boot issue on second FOG-Server:

VLAN 10.20.88.0 and 10.20.82.0 (on which I configured port 66/67 from DHCP to server 10.20.10.38) finds NOTHING.

The first question is that is 10.20.88.0 fully routable to 10.20.10.38? i.e. can you ping 10.20.10.38 from the 10.20.88.0 subnet?

Do have any firewalls or screening routers that might stop udp port 67 and 68 from reaching 10.20.10.38? You can test this by using a computer on the remote subnet and trying to tftp one of the boot files from the fog server.

You are saying that you can change dhcp option 66 from 10.10.10.38 to 10.20.10.38 and the remote system can’t pxe boot. This eliminates dhcp server and possibly any router dhcp helper/relay settings from the problem.

If you have a witness computer (third computer on the remote subnet running wireshark) on the 10.20.88.0 you might setup a pcap to see what the remote pxe booting computers are being told what to load. This would ensure that the remote pxe booting computer was being told the proper values. If true then you can eliminate dhcp infrastructure issues and then deal with IP routing as the problem.

Is there any WAN links between 10.20.10.38 and 10.20.88.0/24 subnets? I have see WAN links that have a smaller MTU than the tftp block size cause a problem. I think the default block size for tftp is 1468 so if the link MTU is below that value it will case the tftp packet to fragment and then fail to download. From your error message it doesn’t sound like this is the issue, but its always good to ask.

Hello,

Someone have the problem ??

I’m lost and i have any solution for this topic …

@ksrvpvl Ok, I think I’m getting what you’re saying. I misunderstood earlier.

Is your custom menu option to boot to winPE working? Or are you asking for help with that part too? There is some very basic guidelines on creating a winpe boot option here https://docs.fogproject.org/en/latest/ipxe

The plugin system needs to be enabled in the fog settings, then you should see a plugin menu where you can activate and then install the tasktypeedit plugin. Some basic plugin system info is here https://docs.fogproject.org/en/latest/plugins but it looks like you got past that bit now.

I also found this post https://forums.fogproject.org/topic/10274/creating-task-with-tasktypemanagement?lang=en-US&page=1 where someone was doing the same thing. Perhaps it may offer some help.

@processor Yes you can !

@Tom-Elliott ok how do I set it to 192.168.11.1?

@baovipboy156

Thanks!

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