@jenesis Assuming you’ve tried every file that might work inside of /tftpboot and have tried several different kernels, then I would direct you to build a boot file with debugging turned on, and then try with that. This is not a fix, but it will provide you with more information that will hopefully lead you in the right direction.

https://wiki.fogproject.org/wiki/index.php/Building_undionly.kpxe

This may be a year old, but it helped me out a ton. Suddenly a bunch of hosts entries have stopped loading.

It depends on where and how you want to focus your effort.

I already have extensive scripting and sysprep solutions for our deployments, much of which FOG can’t touch or isn’t built for, so it’s easier for me to use Microsoft’s existing tools then it is to look for a solution elsewhere.

Thanks for posting, saved me lots of time 🙂

The published 4.1.4 and your special 4.1.4 64bit at the http link above both work without dumping pre-emptible bugs now.

@FlareImp In the article I linked, there are some testing commands at the top. Can you try those FROM the storage nodes that are not masters TO the master storage node ?

We will go from there.

If you can even log in, generally, that means that the FTP pathway between the two are clear and it’s likely a config issue somewhere.

Hello,
we found that the problem was in HP Switch (A8800 if I remember correctly) in which, it was impossible to apply the settings given in WIKI because the model that we use does not allow use command lines.
On the Settings page, only we enable IGMP Snooping option for VLAN we needed.
Thanks by support.

Just sorted it.

Cleared all the tasks off from the mysql.

delete from tasks where taskStateID = x``` x being the number. i just did them all 0 -5.

Thank you, I’ll give this a shot first thing tomorrow.

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 %','');