Installed 12.04 but ran into the same problem. I had thought that after physical machine restart, restarting tftpd-hpa, portmap and nfs-kernel-server had fixed the problem, but I came in today and ran into the problem again.

When you choose not to install the dhcp service while installing fog, you are choosing not to broadcast DHCP to other computers. DHCP restart, restarts the dhcp reception AND push commands so if you are not set to push dhcp addresses, you STILL WON’T do so. You are not pushing DHCP addresses from your fog machine, given what you have said.

Your network is a windows network with multiple buildings?
Thus I can assume that each building has a scope to itself? or is is one massive superscope with routers/gateways connecting each building?

IF you have authority to image machines and work with the settings of the dhcp server, go to your core server and evaluate your network topology (how its set up) you want a different scope for each building as it allows you to micromanage your scope options per building and thus run fog in one building but not another. This also cuts down on the overhead in the server.

So it should look like this :
CORE DHCP SERVER
| | |
a b c
| | |
1 2 3

Where a, b and c are scopes with options set per scope and 1,2 and 3 are the buildings.
This way you can have your cake and eat it too.

IF you do not have the authority to mess with the dhcp core you can try an experiment in setting up multiple pxe boot addresses, when the first one connects it will go from there. In doing so you can disconnect the first address for a time and allow the machine to fail at the first address and move to the second. (this is theoretically possible in win serv dhcp but I’ve never tried it)

Alternatively, and probably the best suggestion I could offer is to move to one imaging solution as this will resolve a host of headaches.

Hope this helps
ICA SDG

the sub files of the /images/{specific.image} folder were not claimed. Upon claiming these and restarting the computers to be imaged, the imaging process went off without a hitch.

I did have to manually restart nfs-kernel-server and tftpd-hpa.

Not sure exactly what fixed it, because each individually has been unsuccessful but restarting both and claiming by chown succeeded.

[quote=“Kyle Myhre, post: 11503, member: 3584”]Is this with an upload or deployment?[/quote]

Deployment. I just successfully uploaded an image on Tuesday which I am now attempting to deploy.
I will test an upload Now and reply.

Similar Issue in Ubuntu 12.10 (desktop not server)/Fog 0.32
The server installation went as expected after modification of installation files to specify the directories fully (eliminated …/ and replaced it with correct string).
After installation our former image files were dropped back into the /images directory.

All the passwords were syncronize on the webgui with the config file at /var/www/fog/commons/config.php.
I then tested registering a host via full registration followed by imaging. Registration worked.

At the imaging stage the pxeboot file loads and the computer attempts to connect for the files and I get:
[I]“Unable to determine best node for transfer!”[/I]

After a moment it follows with another attempt saying :

[I]Storage Node: “Defaultmember is open but has recently failed.” (#TIME)[/I]
[I] * Unable to determine best node for transfer!"[/I]
This continues ad nauseum or until I shut down the machine and cancel the task.

After several attempts I tried to reset the nfs server and export settings. At /etc/exports, I checked the values to be my directories and I seized the directories with sudo chown and sudo touch for /images and all within but still I have the same errors.
Don’t know what to do so I am going to try a fresh install of ubuntu server 12.04 64 bit and try again. The current fog server will be left alone for now but I need to get fog working soon.

Never had this problem until ubuntu 12… 11.04+11.10 worked great. For some reason I skipped 12.04 right to 12.10 if that makes a difference.
Last notes, I checked the firewall within our gateway and everything is opened for fog within site so that isn’t part of the problem.