@Tom-Elliott The quick image menu item for non-registered hosts that you’re seeing there does not look proper. That was NOT, from what I can tell, a 1.0 install. I’ll verify just to be sure, but quick image has not been a part of the host natively.

Just verified that this is not the default behaviour. Either you guys were running a development verison, and somebody put the version number as 1.0 in the system file, or somebody else customized your 1.0 boot menu to have the quickimage option on non-registered hosts.

I assure you, this was not something I did.

WiKi’d here, briefly: https://wiki.fogproject.org/wiki/index.php/Managing_FOG#Storage_Management

However that article already explains this… I just summed it all up.

I have seen brown out’s freak out switches and routers… Messes up nvram in some cases, I would have to reprogram routers even when settings look fine. And yes, full clear and setup.

If the switch did that again I would think about ditching it. Bad switches do crazy things.

@Cire3 said:

What I was shocked at was the speed… I would have done this a long time ago if I knew how freakishly fast this was going to be !

I hit on this point all the time. People never believe just how large of an improvement there is.

I’m happy that you got it going, and pleased that I helped make that happen. 🙂

-----OP reported success - thread solved.

Also, it’d be good to know what version of FOG you’re running which should be in the “cloud” logo at the top of the page. Also remember, we’re not creating normal cron tasks the way most others may think. So there’s bound to be a difference or two. I know the current setup is as close as I could make it. If you can think of a better way of handing the representation of the next run times and proper implementation through a PHP and GUI friendly interface, I’d love to see it. I’m all about trying to better things.

@almontschools said:

We changed the TFTP setting in our firewall

Does this mean your FOG server failed the TFTP tests in the article?

@Tom-Elliott
The issues is resolved.
Now I can edit group properties.
Thanks

https://forums.fogproject.org/topic/5398/upgraded-ubuntu-from-13-04-to-14-04-now-web-console-will-not-come-up

This helped me. I changed the bind-address from my IP to 0.0.0.0

Significantly less secure I think, but it worked.

I was on 3396. Looked it up in my records.

@wayne-workman No, we do not need any more help with this problem. We do, however, have another thread opened for a different issue.
@tom-elliott Attached is an image of the device configuration section of the machine’s BIOS.
IMG_20150817_1336172.jpg

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