@JJ-Fullmer ciao, ho esportato le impostazioni di una nebbia e ho ripristinato il file su un altro PC, il punto è che quando provo a distribuire da un PC rimane su dhcp e non lo raggiunge, mi sono reso conto che il dhcp è impostato sull’altro pc con nebbia che funziona su 192.168.122.1 mentre il nuovo PC ha 192.168.11.1, forse questo è il motivo per cui i client non lo raggiungono?
should I redo the installation and set the dhcp to 192.168.122.1? Right? so the settings that I will then import from the file will be the same and will it work?

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

@cul3r0 It does not, that configuration is elsewhere. If you enabled https support at install then you have to do something special to get that disabled for pxe because it embeds the self-signed cert made at install into the on-the-fly pxe compilation process.

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

@matthewadams12 Why do you need the Fog Server to be offline?
Maybe there’s a solution where we can isolate just the part you want to isolate. i.e. if you are trying to remove internet access where images are stored you could setup a storage node and keep that offline after initial install. The storage node would also need packages and updates to fog, but you could capture them during updates on the main server and then sneakernet them to the storage node.

Storage nodes are just what I’m using as an example. If it’s not the images stored on the server you’re trying to isolate, then there could still be another solution. You could also firewall the server with your external firewall or the os firewall to only allow access to the fog github page for update downloads and then the repo sites that download the package updates?

Just thought I’d throw out some other possibilities.

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

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

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

@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 I updated the FOG Linux Kernel to the newest one and tried using an unmanaged switch but the problem still remains.

@george1421: I cannot launch the FOS Linux engine.

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

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