thank you wayne.

So worked with Tom and being on Trunk 3475 and up, the multicast task creation issue has been resolved. Testing the new trunk version has been fairly consistent in creating single multicast tasks versus multiple multicast tasks with single clients.

Found the http://${boot-url} was incorrect as I already create the boot-url with the http in it. So it was essentially calling: http://http://IP/fog/service/ipxe which won’t work EVER.

Also found issue with the way sanitized strings are stored in db. This, by itself, isn’t problematic, but as we return the ipxe code in pure text, the string was printed exactly.

This is fixed now in trunk. Basically double quotes was the boot param issue. As grub has “rootnoverify…blahblahblah”, it was printing the string from DB as

&rootnoverify...blahblahblah&

It’s not a pain at all.

If anything it points out a potential issue, though why it didn’t send the image down I don’t know. My guess, ftp user/pass incorrect for those three problematic nodes.

In FOG Trunk (fog 1.3.0), you just click on the image in the web console and it says it right there at the bottom.

In 1.2.0, I think it might be somewhere in FOG Configuration -> FOG Settings

I found out what the issue was. Somebody on my team removed option 66 and 67 from our dhcp servers. So the network boot didn’t know where to look for any files.

@Wayne-Workman I wasn’t questioning the use of Ubuntu 12.04. I actually still use it on my fog servers. my question was mostly regarding the rational behind the older-OS on VM inside newer-OS arrangement.

@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.