Get the service config file [CODE]cat /opt/fog/service/common/etc/config.php[/CODE] and do [CODE]service FOGMulticastManager status[/CODE] to make sure the manager is actually running.

As far as I understand it, it’s really a matter of how your system is configured and used. 64 bit gives you access to RAM above 4GB (3.something if you want to get really technical), which is useful when you’re decompressing images, which only happens on the server when you’re multicasting from that server. But multicasting is generally bottlenecked by the write speed on the disks of the hosts you’re multicasting to or the network speed. So overall it’s really specific to your configuration and how you use it; is your server doing things that require a lot of memory? Personally I haven’t noticed a difference in the performance of FOG, but I also haven’t been looking for it.

It sounds like the file for that computer still exists in /tftpboot/pxelinux.cfg/01-<MAC ADDRESS> on the FOG server. Deleting this file will stop it from booting into this task.

I hate to suggest this, as it’s rarely desirable but, have you tried rebooting your FOG server?

Perhaps you know more about this, but a quick look at their site and their 3rd part app integration, it looks like the developers would need access to a Synology system to make this happen. The developers are busy at the moment working on FOG 0.33, and I know that there have been requests to integrate FOG with other tools, such as Spiceworks, but their main focus is on making FOG work well on it’s own. This is an open source project, so feel free to grab a copy of FOG and try your hand at making this into a reality, there might be others on the forums who would be interested in seeing this happen and might be able to help as well. Oh, and if you do decide to go ahead with this we’d love to hear updates on your progress.

FOG doesn’t use the standard ping (something about execution overhead being too costly), instead it uses UDP echo port (port 7) to get a response from the client. So if you’re making firewall exceptions for FOG to ping your clients you’ll want to check UDP 7.

I’ve seen this before a couple times but I don’t know if anyone has actually tracked it down to a cause. One thing that seems to work (for some people), is to wait until every client is at that stage “No job found…” and then recreate the task. The clients will check into the task and start imaging. Sometimes the task will disappear a second time, but since they’ve all started the process they’ll finish out the imaging, though they may hang at the end of the imaging and complain that there is no TFTP file to remove, at which point you can just reboot them.

Hmmm… I’ve never encountered this issue before, and without actually seeing it in person I’m not sure what other steps to take. I’ve installed 0.32 on multiple versions of Ubuntu and CentOS from scratch, and this one is new to me. Perhaps somebody else on the forums has some suggestions.

Congrats on getting it working; if you ever want to check on a linux firewall (iptables) just run [CODE]/etc/init.d/iptables status[/CODE]

SSH into fogserver and try
[CODE]mkdir /tmp/images
mount -t nfs fogserver:/images/ /tmp/images/[/CODE]
If you can’t mount it locally then you’ve got a problem with NFS. If you can mount it locally then it must be a networking issue, perhaps a wrong ip address or dns record for your fog server, or maybe a firewall.

Web Console->Storage->All Storage Nodes and then edit the storage node in question, most likely Default.

try [CODE]sudo service nfs-kernel-server service[/CODE] to make sure that it’s actually running, and then [CODE]cat /etc/exports[/CODE] to get the config file. I’d also check the permissions on /images/ and /images/dev/ to make sure they’re correct.

There are multiple locations that need to be changed when migrating to a new IP. In this case I’d say check to make sure your storage node IP address in the web console.

Try running [CODE]sudo service nfs-kernel-server restart[/CODE]

I’m not deeply familiar with the FOG client service, as I haven’t used it for a while and I never really examined all the code, so perhaps there is somebody else who might better understand how it works and help you with these issues, but I’ll take a shot at explaining it as best as I understand it.

All these various MAC addresses are used to identify the host. I’m pretty sure that the first MAC listed needs to be the addresses of the NIC that the host will be PXE booting from, as that is the address used for creating tasks. The additional MAC addresses are alternate ways of identifying the host to handle situations with the FOG client service seeing other addresses than that of the NIC used for PXE booting.

Example: The host boots into Windows and the FOG client service starts; the first thing the service does is attempt to contact the server and check for tasks (reboot for an image task, pull down snapins, etc.) and provides the first MAC address it finds. While the MAC address provided to the server by the client may not be the address used to create the tasks, the server will check against all known MAC addresses to discover the host ID, and then check against that host ID to discover any tasks associated with that host. I’m not sure how the service is grabbing a MAC address, and it appears to have trouble occasionally with grabbing the wrong one, which is why its a good idea to add all of them.

Hmmmm… what do you get from running ipconfig /all? I wouldn’t be surprised if it was something like a bluetooth adapter or VPN tunnel adapter being used instead of the NIC.

SYSLINUX 4.05 did make some adjustments to chain.c32, so it is possible that a bug was introduced, and using 4.04 might help. Another thing to check; what happens when you don’t PXE boot? Does it boot normally to the hard drive? Also, append hd0 tries to load the first disk drive detected by SYSLINUX, so is it possible that it’s seeing another non-bootable drive on this system?

Of course it doesn’t work, because I wasn’t thinking and linked to an image on a secured site. I’ve attached a copy of the image to this post.

[url=“/_imported_xf_attachments/0/116_Screenshot_01.png?:”]Screenshot_01.png[/url]

This is the default graphical menu:
[IMG]https://carmenwiki.osu.edu/download/attachments/26522106/Screenshot_01.png?version=2&modificationDate=1302028112087[/IMG]

I’d hazard a guess that it has something to do with your wireless card. Did you add the wireless card’s MAC address as an additional MAC on the host page in FOG?