That is actually not enabled. I guess I should have specified rebooting when there is a task, like changing the host name, or something. The reason I ask is that I logged in to some of my lab machines today to install some software that couldn’t be deployed. The machines all rebooted within a few minutes of logging in. The local Fog log showed that Fog was attempting to join the machines to the domain, but they had all been imaged 2 days ago.

Is it possible for a Fog task to get “stuck” in a queue? I read this thread: [url]http://fogproject.org/forum/threads/fog-client-weirdness.11942/#post-38669[/url] that seems to point in that direction. There have been many task false starts in the past week or two, where the task was cancelled before being completed.

Where does the actual mysql db for Fog reside?

No problem, it’s what I’m here for…I think. 😉

Is it possible to roll my own using the kernel that is working for me now?

@tnunn

In my own experience, the image process completing without doing anything happened due to a weird MBR size that is made custom for some brands…

Can you tell us what the output is of these commands:

cat /images/<image name here>/d1.fixed_size_partitions cat /images/<image name here>/d1.minimum.partitions

I started from scratch this morning, paying extra attention to the proxy dhcp setup process, and it now seems to be working as it should. Have successfully uploaded and multicasted an image. Thanks for your help.

You have to boot from network using PXE. Usually you can press F12, while the machine boots up. Then you see the FOG menu. You might have the timeout set to 3 seconds or so. Log into the FOG webinterface > Other information > PXE boot menu. There you can increase the timeout.

Thanks for the reply. We have chainloading implemented. The problem turned out to be a missing file or files that weren’t copied correctly during the setup phase. Re-copying the files fixed the issue. Thanks again.