I would hazard a guess that you’re sites are far enough away from the TFTP server that they’re timing out. I’m not sure where the documentation exists at this point, as it was just a user modification that did this and not something official, but you can set up remote TFTP servers (generally just add the TFTP service to a remote FOG node) and then use NFS to share the /tftpboot/pxelinux.cfg/ directory from the main site’s TFTP server to the node sites’ TFTP servers. If your issue is TFTP timeouts then that would take care of it.

What about swapping the order they’re listed?

It’s been a while since I last spent much time dealing with the rules of NFS; but I seem to recall there being a thing about subdirectory rules being inherited, and some searching around the web points to swapping your fsid’s for /images and /images/dev so that /images/dev is processed first.

Not really sure if that will solve anything, and I don’t have a linux box on hand to test with, but it looks plausible.

Did you check /etc/exports on 10.0.0.3 to make sure that it has write permissions?

Two things come to mind:

1. Is PortFast enabled on the switch ports feeding those computers?
   PortFast being disabled can cause issues when PXE booting because the link takes too long to establish, which shows up as PXE/TFTP timing out.

2. Is the Windows Firewall allowing the TFTP application?
   TFTP connections are established over UDP port 69, but the actual file transfer happens over a random UDP port. So just opening UDP port 69 probably isn’t going to work and it’s generally easier to just allow the TFTP application through the firewall.

As far as I’m aware… most VOIP phone are actually PXE booted, so it might be that somebody has replaced the global DHCP options 66 and 67 to point at the VOIP system.

OK, so you have another program creating the FOG tasks? If that’s the case then it sounds like it’s creating the files just fine but the database entries aren’t being added for the tasks.

Apart from the logs in the log viewer there are no central “FOG logs”; this issue would most likely appear in either your apache logs or your vsftpd logs, so I would check you configs on those two services to make sure they are logging properly, and then start digging.

Here is the wiki article on what an in place upgrade will change: [url]http://www.fogproject.org/wiki/index.php/Upgrading_the_FOG_Server[/url]

Are you getting any error messages after successfully deploying an image? What are the file permissions on /tftpboot/pxelinux.cfg/ and the files inside?

I’ve encountered this issue a few times, and it seems like it’s generally due to the web server or FTP server being unavailable when the task completes. However, I’ve never had time to dig into the cause of their unavailability when it happens, so it’s hard to be sure. There was at least one time that I came across this where tasks had been created and then the ftp user account had it’s password changed but not updated in FOG. There was also a time when permissions on the directory were modified so that root was the only user allowed to modify files.

I’ve never found any systemic issues with FOG that would indicate a bug, but I’ve found plenty of these little scenarios where for one reason or another the files are created but not deleted. If this is a consistent issue that is easily reproducible then I’d be very curious about your configs/permissions.

Quick update: Yes, 0.33 is still under development. Work has been stuck for a while due to the schedule of the developers and the fact that the one big remaining issue is UEFI. If anyone out there is interested in pushing things forward and has the time to spare, the devs could really use some help working out the whole UEFI booting.

Other than that, the rest is just fixing little things throughout the UI. FOG 0.33 didn’t start with a solid bug tracker, and the dev that did most of the rewrite has had to step back from the project, so there are pages that didn’t get finished but they’re not all documented in one place. So if anyone wants to systematically go through each page and track down all the little pieces that don’t load properly it would help a lot.

If I get some time today I’ll try to read back through these posts and answer individual questions that I know the answers to; like Stephen DiCato’s question about GitHub: they’re waiting for 0.33 to finish before migrating to GitHub.