"Checking Queue .... Done" but image doesn't deploy

[hackernun]

So, first post, first trophy!

I’m on CentOS 6.2 with Fog 0.32. I’m trying to migrate from an unknown level of Fedora (kernel is 2.6.29.6-213.fc11.i686.PAE) and Fog 0.26.

The problem I’m experiencing is that when I try to deploy an image, the client gets stuck at:

• Checking Queue …Done
• (0 sec)
• (5 sec)
  … and so on. The task is “queued” on the task management page. I’ve also tried force starting the task.

Following the instructions here resulted in a successful image deployment:
[url]http://fogproject.org/forum/threads/wiki-troubleshooting-an-image-deploy.20/[/url]

The initial install on CentOS went just fine after following instructions here:
[url]http://www.fogproject.org/wiki/index.php?title=Installation_on_CentOS_5.3[/url]

Then tested with success:
[LIST=1]
[]Create image.
[]Register host.
[]Upload image.
[]Debug and delete partitions.
[*]Download image.
[/LIST]
Then I needed to migrate the database. I feel silly admitting it but I painstakingly ran the ‘installfog.sh’ script on the old Fedora server for every in-between level of fog. I opened the web page to update the database schema each time and checked to see that things looked copasetic, then backed up the fog directories and the database each step of the way.

After getting the database schema to 0.32, I backed it up and restored it on the new server. I went through all the painful errors and debugging of passwords and folder permissions, etc, only to get stuck here.

One other possibly important piece of info … Both servers have two NICs, one on the Windows domain and one on a private network for imaging. The private networks are different (192.168.0.0/24 vs. 192.168.122.0/24). I mention this because it has caused other problems (mounting NFS volumes, for example) but all the IP’s on the Fog Settings web page are now correct, as are the logins and passwords.

Lastly, I’ve tried both deploying an old image migrated from the Fedora server as well as creating a new image to deploy. I also experienced problems creating the new image. The files were created but the client hung after “Task Complete” and the files were not copied from the /images/dev/macaddress directory to the /images/imagename directory. I crashed the client and manually copied the images and still don’t know that that process will work. It seems both problems might be related to permissions on the /image/ directory but the debug manual imaging works just fine.

TIA for any help. Despite my difficulties, I think Fog is a terrific product and certainly a great service to schools!

[hackernun]

Forgot to mention that the private imaging network IP was corrected on the Storage Management/Storage Node web page as well.

[hackernun]

Same failure on the old fog server. This is the one that I painstakingly updated one release at a time. I decided to plug in a laptop and see if I could image it but … no. Same symptoms. There have been no other changes to that system and it was working fine at .26 before the upgrades.

So, it seems there must be a bug in .32 or in the upgrade path thereto. Any help would be much appreciated.

[hackernun]

OK, I haven’t figured out what caused this, but I have found a way around it. I ripped fog out by the roots and reinstalled. I opened the web page to create the database and when I migrated the old database to the new, I only migrated the tables relevant to the systems. That is, I deleted the SQL regarding the table ‘globalSettings’ and reset all the settings by hand on the ‘Fog Settings’ page. Now, everything is working.