You need to use FOGCrypt to encrypt your AD password.

Install the client onto your golden machine, reboot a few times. When you see “hello fog client” in the C:\fog.log then you’re good to upload your image.

For clients to join, the AD stuff for the hosts need populated by checking the “join domain” check-mark for the target hosts. You also need pretty much all the service settings turned on as well for those hosts.

If you’ve already done these things, we need to see your log.

I think so but I imagine that if you re-run the fog installer, it may help work out its own kinks?

@JBailey When we talk about revision numbers, we are referring to the number in the cloud, in the top left of any fog page. Tom has coded the current Trunk versions to display the number in the cloud correctly.

It’s confusing when you don’t specify “git” or “svn” or “the number in the cloud”.

Glad it’s cleared up though. It’s important to indicate things like this in the threads because they serve as help for who knows how many other fog users - people of varying skill level - fog knowledge - English reading ability and comprehension - etc.

Correctness and clarity are important. Remember, when we are helping you in the forums, we’re actually helping you and others too. 🙂

I’m going to claim this as solved.

Paul and I Teamviewered and I was able to find a couple bugs in the dhcp config creation.

It should now, properly, create the dhcpd.conf file

Part of the issue with the functions error was the interface fog was setup for was incorrect. It seems the OS decided to flop the nics arrangement. Other issues were the config was missing a semicolon, and the bootfilename argument wasn’t being populated. It is now created properly, stored in the fog settings, and can be set by an installer argument of either -b <filename> or --bootfile <filename>.

Hopefully this helps.

My only guess is the partition sets are setup in GPT, and 0.32 can’t recognize the GPT structures. Because of this, it can’t recognize the partition as ntfs and tries to upload as RAW.

While 0.32 is Old and reliable, it’s obviously not working for your needs right now correct?

I am a fan of 0.32 and understand hesitation is moving to a newer version. I would take a look at the image definition and make sure it’s not set to DD or Raw image type. I don’t think you can do Resizable without sysprep on 0.32, so if you’re not trying to do sysprep, make sure the image type os Multi-Part Nonresizable. If it’s still uploading in raw, then there’s likely something else the matter.

@Wayne-Workman said:

I’ve had this issue on both Dell 7010s and on some older Lenovos. Every now and again I’ll find a machine that just won’t image.

Sometimes, pulling the network cable and power cable and then hitting the power button a few times, then hooking everything back up will fix it. 😕 It’s just strange.

WORKED for my one Dell E6400. Very odd. That trick is used for clearing corrupt RAM and I did a swap so it doesn’t exactly make sense. Whatever…it works now.

Still working on the D630 image will be done with it shortly.

GREAT NEWS!! The re sizable image is working!! Thank you everyone for your help, and although it seems like I should of thought of that, I appreciate your time and patience with me!!
Your guys are the BEST and we LOVE your program! Thanks for sharing!
Have a great day!!

@Wayne-Workman I can also confirm that it worked for myself too. That’s how I knew about the post and I wanted to make sure to share it.

@cadyfish Thank you for your answer greatly. This post has been added to the WiKi here: https://wiki.fogproject.org/wiki/index.php/Troubleshoot_MySQL

Since sourceforge’s issues, I decided to use git’s versioning system. This is expected.

As a failsafe, I added the same version checking to check, latest stable, svn, and git.

Maybe the syntax:

UPDATE hosts SET hostDesc=REPLACE(hostDesc,'Uploaded by batch import on %','');

i’ve only seen the “garbage” when viewing the web interface on a mobile device. never impacted functionality. i don’t think they show up on anything newer than the past year in trunk versions of fog

Just tried that and it won’t boot into debug either.

Your issue sound similar to one that I had and one that someone else posted on here. Is the hard drive size that you created the image on the exact same size? Also is the image type you are using one that is not resizable? If so, either try shrinking the partition and reupload the image so that way there is about 1-2gb of unallocated space on the drive or simply try imaging a computer with a hard drive that you for sure know is larger (not same, larger) than the one used to make the image. Hope this helps.

@rvieira said:

port=0
log-dhcp
tftp-root=/tftpboot
dhcp-boot=undionly.kpxe,fog,192.168.56.128
dhcp-option=17,/images
dhcp-option=vendor:PXEClient,6,2b
dhcp-no-override
pxe-service=X86PC, “Booting into FOG!”, undionly
dhcp-range=192.168.56.128,proxy

Try this for your configuration:

port=0 log-dhcp tftp-root=/tftpboot dhcp-boot=undionly.kkpxe,fog,192.168,56.128 dhcp-option=17,/images dhcp-options=vendor:PXEClient,6,2b dhcp-no-override pxe-service=X86PC,"Booting into FOG",undionly.kkpxe dhcp-range=192.168.56.128,proxy

Then link the undionly.kkpxe as suggested earlier.
ln -s /tftpboot/undionly.kkpxe /tftpboot/undionly.kkpxe.0

@Wayne-Workman Based on the messages from the log, I’d say this is the old client, if it’s any help.

I solved this by doing chmod777 <folder> on the directory where i put all the trunk install files and then i re-ran the installer and realized last time i ran through i didnt update the database via the WebUI When it asked…

Group ad field settings do not maintain the settings. This is because, it updates all the hosts all at once. I don’t have a performance friendly option to do this checking.

So this setting in the group field is designed to blank out after it’s been updated. The hosts within the group, however, should be updated. Is this not happening?

@skotteru What operating system?

@rvieira That’s strange, isn’t it? 🙂 Glad it works though.