@george1421 Idiot moment. Sorry for all of the trouble but I had the 66/67 settings done in the server options and didn’t realize that the old FOG server settings were done in the scope options. That’s why is was overriding and sending pxelinux instead of undionly. Again, sorry for the trouble and thanks for your help. Issue is resolved and registration works great now.

Looking at your pcap file I would say you have 2 dhcp servers on your network (not a good option).

One is 192.168.5.1 and one is 192.168.5.200.

192.168.5.1 appears to be a router that is passing out an IP address but no pxe boot information. 192.168.5.1 is passing out a client address of 192.168.5.80 to the client.

192.168.5.200 appears to be (maybe) a fog server running either dnsmasq or isc-dhcp server (probably). 192.168.5.200 is passing out a client address of 192.168.5.10 to the client. 192.168.5.200 is sending out a boot file of undionly.kkpxe with a next server of 192.168.5.200.

This seems to be confusing the clients because one time they accept the IP address of the router and sometimes they accept the ip address from fog (which is not providing enough information, but does provide pxe booting information).

Course of action:

Disable the isc dhcp server on the FOG server. Install DNSMASQ to provide the pxe boot information without providing a ip address to the client.

@John-L-Clark if an entry is made properly in /etc/fstab it will mount on boot, else it wont. Reboot and see. This is something that needs dealt with immediately - don’t wait.

@cnkpadobi well that is sure one way to fix the issue!! Thank you for the clarity.

@royg706 I would verify the credentials - them seeming to appear correct isn’t good enough, they need tested. Here are two articles that explain how to test the FTP credentials and remote MySQL credentials properly - if there are problems with any of this, you’ll find them during testing.
https://wiki.fogproject.org/wiki/index.php?title=Troubleshoot_FTP
https://wiki.fogproject.org/wiki/index.php?title=Troubleshoot_MySQL

@Tom-Elliott

Hi Tom

Running the installation again with sudo-i worked

Thanks for your help

Kind Regards

Lawrence

@Tom-Elliott
ok.

thank you

Thank You!

Sometimes you just feel a little slow on the uptake. I put the pieces together and realized something. In the wiki entry on using FOG with FreeNAS, the instruction is to create 2 separate datasets --> images and images/dev. This is what sets up the different mount points that gives a problem with ftp in FreeNAS.

I deleted the 2nd dataset from FreeNAS and then went into the shell in FreeNAS to recreate the dev directory under images. I recreated the .mntcheck file and set the permissions for the FOG user. The rename of a directory from the windows ftp client now works to rename from images/dev/test to images/test so now the FOG image should work.

Would someone please update the wiki to not create 2 datasets, please?

Yeah, sorry about that.

I meant to merge into a different branch, accidentally switched to dev-branch, it was late sorry.

@Frank said in Unable to join to domain - build 3331:

I guess public key is at “/var/www/fog/management/other/ssl/srvpublic.key”

Just dropping a friendly moderator line here - in FOG 1.4 the public key is here on the main fog server:
/var/www/fog/management/other/ssl/srvpublic.crt
You should be able to view the public certificate via the below URL, replacing x.x.x.x with your FOG Server’s IP address or FQDN.
http://x.x.x.x/fog/management/other/ssl/srvpublic.crt

@Wayne-Workman We move away from using preset names because it left room for error.

@JGallo YEs, that is correct. rc-3 has the fix too and so it will remain going forward.

One server can be the master of several groups. This is how I setup exactly what you’re doing at my old job.

So say you have servers A, B, C, and D, each one geographically separated at their own site. Say that A is the master and has uber amounts of space. Say that B, C, and D have limited space.

Site A’s fog server would be the main server & the master of four groups.

Group 1 - has all images in it and would be the primary group for all images. The master of group 1 is server A, and Server A is the only member of this group.

Group 2 would be for site B. You’d create another ‘storage node’ using FOG’s web interface. You’d use the same IP address, same user & pass, same /images directory. All this would be all the same - but you would name it something like Site B Master. Then you’d configure Site B’s storage node out at the remote location to be a non-master and a member of Group 2. With this setup, only images shared with Group 2 would replicate to site B.

You would repeat this sort of setup for C and for D.

Make sure the main server has plenty of space and compute power. At my old job, with most locations using the same image - and with the shear number of images we had - we burned through 400GB in a flash. I’d suggest you shoot for 1TB or larger - even 2 or 4TB - because you’ll eventually get that one model where no image type works except for RAW and you wind up with a 500GB image file just to support that one dumb model.

Fog was listed as DNS server. We figured out the problem. Someone had entered the address of the Fog machine as a DNS server in IPv4 properties on the workstation. User error, totally unrelated to Fog. Please close or delete this topic. Thanks!

@irishfoguser

not sysprepped

This is possibly the problem. Not everyone syspreps here, but I recommend trying it and see if that alleviates the issue.

@Joe-Schmitt said in SmartInstaller on mac ERROR !:

https://download.mono-project.com/archive/4.3.2/macos-10-universal/MonoFramework-MDK-4.3.2.macos10.xamarin.universal.pkg

Waho… it’s work ! Realy Thank’s !

If you followed this you wouldn’t have the problem: https://wiki.fogproject.org/wiki/index.php?title=Migrate_FOG

George is right. Without these things we can’t help much.