@JoeCT said:

I use Centos 6.5 and had a similar problem. This is what was wrong with my setup.

https://forums.fogproject.org/topic/5518/fog-ftp-login-fails-after-image-creation

As Wayne pointed out, you may want to look at the link he has posted, but more than likely, the issue is that fog via the UI thinks the fog user password is ‘x’. On your server, however, the fog user on Centos has a password set to ‘y’.

The way I fixed it is to cludge the passwd on either the UI side or on the Centos side to match. Stronger the password, the better if you are doing this as it can lead to outsiders who can mess with your images if you have an open network.

@Wolfbane8653 Exactly what I was looking for, a list! Thank you!

I had changed the virtual network on my xp virtual computer which caused the freeze up error. When I change it back to the intel virtual nic the virtual xp connected to fog and I created and restored an image with no issues.

Thank you everyone. Hopefully this will help someone else in future. My distribution was Centos 6.5 and FOG 1.20.

if it’s taking 5 hours to upload, it makes me wonder: did bitlocker somehow get enabled on the machine you’re trying to upload?

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.