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

@FRG You can specify the disk to image to in the host settings screen with the host primary disk field
96cfd435-a76b-4776-84ac-507d7b65da1d-image.png

By default Fog will use the first disk it finds (I believe) or you can specify per host.
i.e. if you wanted it to image to a second disk you could specify /dev/sda2 or /dev/nvmen1n1

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