Yes, that worked, thank you very much!

@Almeida

The problem is solved.
tftp was closed

Thanks.

@robert70569 This is interesting. I think it would fail earlier when trying to NFS mount the images share on the FOG server in that case. Strange.

@jouni-jokelainen said in Fog and Pfsense 2.7:

Adjusted Pfsense settings for fog (Thanks for these george) :

I guess this topic is solved then. Please open a new issue if you have more questions (not related to pfSense).

@davidgoncalves Also please run the following commands on your FOG server shell and post output here:

mount df -h ls -al /images/dev

@george1421 The campus has it’s own subnet, im changing the problem with it. When I used a VM to test it, desktops in the lab have a hard time trying to connect to the FOG server via pxe boot. It times out after it tries to bring the gui up. So I’m trying to figure out why it keeps timing out. VMs will boot to it fine, but any physical systems either time out or boot fine with it.

This problem is solved after reinstalling new keys.
Running ‘installfog.sh -K’ solved my problem.
Now all images can be used again and no matter what client is installed they all work fine.

🙂

@george1421 If I give you access to any desk on a PC that reaches the 2 servers, would you be able to understand if there is something wrong?

@Wayne-Workman said in How to configure a DNS server？:

I would recommend dnsmasq. Here’s a good simple tutorial. https://stevessmarthomeguide.com/home-network-dns-dnsmasq/Minesweeper

I have never tried dnsmasq. Can you give detailed instructions on how to use it?

@jjurak Is this something you are actively looking to do?

If yes, do you use the fog client program? If yes that will be the problem. The fog client is hard coded to use port 80. I’ve been asking for a few years to decouple the fog client communication port from the management ui. But there has been other issues that have taken priority.

If you are interested in doing this I can probably give you a few areas to look.

Oops!
I deleted from CLI. But I just did that again and the image did not appear in the list and the storage number increased accordingly.

-Jim

@george1421
For the 7080 it doesn’t have CSM mode unlike other Dell hardware I’ve had to image. I’ll give the latest 6.x kernel a shot and see how it works with one of them when I’m back in the office tomorrow.

@FGeyer

I know this is an old topic, but it looks like you don’t have a solution. I have this exact problem. It looks like @Tom-Elliott may consider this unnecessary (which may very well be true for other use cases), but for the sake of using @george1421 's awesome driver injection solution, it would be really nice to have. My workaround was to utilize OS type 4 for Windows 11 as I am not using it for anything. I updated the following line in “fog.custominstall”

case $osid in
5|6|7|9)

to

case $osid in
4|5|6|7|9)

Then I updated the following line in “fog.copydrivers”

case $osid in
5) osn=“win7” ;;
6) osn=“win8” ;;
7) osn=“win8.1” ;;
9) osn=“win10” ;;

to

case $osid in
4) osn=“win11” ;;
5) osn=“win7” ;;
6) osn=“win8” ;;
7) osn=“win8.1” ;;
9) osn=“win10” ;;

Mark you image as OS type 4 and it works as it should. Hope this helps.

@DBCountMan I suggest to verify the checksum (sha256 file on github). If the checksum is wrong, then re-download init.xz. But if it’s right then try another init.xz version, e.g. https://github.com/FOGProject/fos/releases/download/1.5.10/init.xz