We leave the ip address field blank. The installer looks for fogserver by default. Regardless of the actual server name I put an A Host record in my dns server to point to fog. This has solved tons of problems for us.
For my tests I installed a new one on a physical machine to go on simple bases.
So I now myIP:69 with a netstat but it still gives me the same error on the boot PXE…
I ping the machine well, I have access to the web interface of FOG, only the “PXE” does not work and returns the error message I mentioned in my previous post.
I found this patch on the source forge page, it says it is for .29, but not sure if it was implemented into the newer versions. But figured it was worth a shot
i compiled my own kernel 3.9.2-4 and two of the machines work now instead that one tells me now hdd not found instead of kernel panic but this is only one missing driver.
I removed the snapin and added it again. Remade the snapin and added it again. There are 2 snapins that I was having trouble with and neither are downloading. I don’t know what the deal is. I made a work around that might work. I just made a script that maps the network share that the AI’s are located on and then runs them. Do you have any more ideas to get the regular snapin install to work?
When I created the image on fog gui I usually select “Multiple partition image - single disk” But I will try using “Multi Disk - All partitions (no resize)” James suggested. Also, I did install fresh win7 just.
[B]Here is the solution for people like me who are bothered [/B]:
gksu gedit /var/www/fog/management/includes/tasks.confirm.include.php
Search Menu > Replace
Search for: &$tmp
Replace with: $tmp
Replace All (there were somewhere around twenty instances)
Save
Close
Then try to schedule your upload task again.
For other users with this issue, here is specifically what I did. I can’t guarantee it will work for everyone, but it seems to have corrected it for me at least:
gksu gedit /var/www/fog/management/includes/tasks.confirm.include.php
Search Menu > Replace
Search for: &$tmp
Replace with: $tmp
Replace All (there were somewhere around twenty instances)
Save
Close
Then try to schedule your upload task again.
The way groups work in FOG is it’s a just a label for applying settings to multiple devices, or to start actions on multiple hosts at the same time. It does not store any settings related to the group other than group membership. If you set a property on a group, it updates all the host records. It does not store the settings in the group. This behavior is under review and may change in future versions of FOG.
Have you made sure that all mysql components are uninstalled before you try to rerun the FOG setup? Maybe there is a pid file blocking you? I’m not sure what logs you might look at, but /var/log/syslog would be a start. Tail the log file in another terminal or console session while you try to run the installer. You can check all the mysql components installed using dpkg and grep.
What version of FOG on what Linux? After you schedule a deploy task to the second computer and reboot that computer, what do you see on the screen? Do you get the FOG menu or does it load bzImage and init.gz and stop?
Ajay, please start a new thread and give as much information as possible. If you would like, reference this thread if it contains relevant information.
Generally, we need to know what version of FOG on what OS. Is it a (N)ormal server or a (S)torage node?
