Check your windows network configuration on the clients. If you use DHCP, make sure they are set for that. If not, check with your network administrator to make sure your TCP/IP settings are correct.

Thanks! I had done the mysql pwd change, and rebooted the computer, but maybe the password was still cached somewhere. After another reboot I was able to get back in. Everything’s copacetic now.

Hmm, I guess everything’s forwarded correctly considering I was able to mount it using a random fedora live-cd:
[LEFT][IMG]http://i.imgur.com/RgdIyzp.png[/IMG][/LEFT]

Maybe an issue with the kernel? with the debug option when pxebooting, can you manually mount NFS for testing?

search the forums. there are at least 4 posts describing in detail the changes that need to be made.

Understood, thank you very much for your help.

Hello,
thanks for the answer.
Unfortunally, this parameter was already set to off.

I have Ubuntu 12.04.1 LTS

Hello,

I’ve some good news here, I’ve solved my problem with this solution :

Disable Secureboot Enable Legacy Bios Erase the table partition Reinstall your OS (Win8 or Win7)

This solution work on Win8 and Win7 for Fog .33 and Fog .32.

Additional informations : I tried to change kernel loaded on PXE boot for clients with no change.

Finally, and last try before complete reinstallation, I run the FOG install/update script. After that, everything seems to work fine ! The problem is somewhere in a configuration file used by FOG, but I don’t know what file precisely.

I encountered quite a few problems that were related to some of everything in this thread.

Here’s what I did to resolve my issue:
[LIST=1]
[]Started with a fresh machine.
[]Booted to FOG PXE and went to Debug Mode.
[]DD’d the drive for a minute to destroy any partition data.
[]Created a fresh image from install.
[]Sysprep’d machine.
[]Uploaded image as Single Partition (NTFS Only, Resizable)
[/LIST]
After deploying images using this method, I was able to deploy several images without any problems.

hi,

i took 10-15minutes to got away from this prompt (see attached file) what could be the reason?

fogserver is a virtual machine from vpshere connected to 1gb switch port fog client is a phyiscal machine connected to 1gb switch port

Though my imaging is sucessful, everything is fine except that it takes time on that mtftp connection…

Thanks

[url=“/_imported_xf_attachments/0/293_mtftp.jpg?:”]mtftp.jpg[/url]

[quote]I started getting this when I restarted dnsmasq:

[SIZE=5][B][COLOR=#000000][FONT=Ubuntubeta][SIZE=14px]dnsmasq: failed to create listening socket: Address already in use[/SIZE][/FONT][/COLOR][/B][/SIZE][/quote][SIZE=5][B][COLOR=#000000][FONT=Ubuntubeta][SIZE=14px][/SIZE][/FONT][/COLOR][/B][/SIZE]

[SIZE=14px]I received this error right after I installed proxyDHCP, and set up my config file, every time I tried to restart the service it gave me this error. I rebooted and it went away hope this helps you.[/SIZE]

Welcome to the forums! Glad you found the issue!

Thanks for the quick reply. The wired / wireless was the initial problem until I approved the pending MAC. After approving the pending MAC I did get a couple of entries written to the database for the laptop over the wireless connection. I can see in the fog.log that it is using the MAC of the wireless adapter and finding the host entry. The problem is in the login history that is supposed to be kept for upload if the computer is offline.

From [url]http://www.fogproject.org/wiki/index.php/Managing_FOG#Functions_and_Operation[/url]
[QUOTE]User Tracker
This module attempts to track user access to the host computer by the Windows user name. It attempts to track logins and logoffs as well as well as the state of the computer at service startup. The service will even attempt to track users when they are not on the network by writing all entries to a journal file, then replying the journal the next time the client is on the network.
There are no configuration settings for this module.[/QUOTE]

Where is the journal file kept? If it is not being created, how do I troubleshoot? Why did it not upload when I did connect since I now know that other entries were created once I was online?

KK20, thank you VERY much for this! I saw this answer in other places, but I wasn’t sure if it applied to my FOG issue. I was having this issue imaging some Optiplex 9010 all-in-one units…

That is most likely a problem with permissions. Please search the forums, the Wiki or Google. There should be a lot of threads regarding this problem.

OK, so the lack of response on this thread leads me to believe there is nobody else out there that is having this problem and nobody who has a clue how to fix it. However, this problem still persists for me but I have had a bit of a break-through today (!) and thought I would share it with the community on the off chance that it’ll be useful to somebody one day, and if not that then just for bragging rights! 😛
So I had another biggish order to process today (10 machines) and they were all Dell GX620s, PDs, 2GB and Win 7 Pro. I set up the fist machine, registered it on Fog and renamed the Host to “Gems 1”. (I always rename the Host name from the mac address to a reference of the customer) Selected the image I wanted to deploy and clicked update. Decided to do a quick image as I will probably just use this one machine to load all of the HDDs for the order so I didn’t create a task for it. Selected Quick Image from the PXE boot menu and I got an error saying “Quick Image Failed… Invalid Host Information”. So went back onto Fog Management and created a task for it instead. I get the DREADED HASH AGAIN! :mad:

Getting a bit fed up of this now I went back to the host information on Fog Management and decided to tweak it a little. First thing I did was rename the host from “Gems 1” to “Gems0”. Then I deleted all of the “Host Description” (Usually Fog will put in the date and time the host was created by default) so it was completely blank. Then in the Host Kernel, I pointed it to an old Kernel that we used on an old Fog server that never had this problem (Kitchen Sink 2.6.31.1) and finally in Host Arguments I typed in “nomodeset”.
Now, the last two things I mentioned (Alternative Kernel and nomodeset) I have tried many times before and it got me nowhere but I thought I’d try them with the other things I did just for good measure. Clicked update on the Host, killed the previous task for it and then created another one. PXE booted the machine and it imaged fine!! 😄

YES!!!

Now I’m not completely sure which variable actually did the trick but it worked. It could have been the name change, deleting the Host Description, or it could have been a combination of the whole lot. The next time I get this problem with a machine though I will try one method at a time and try to figure out what is actually causing this.

Will post as soon as I get answers!