@Tom-Elliott For future readers, I’ll add that if you HAVE to do an export in this fashion - you probably have much larger issues…

FOG has a built in DB export tool; this is how you get to it:
FOG Configuration -> Configuration Save -> Export
That copies everything from the DB - literally everything.

The Import tool is in the same spot and it does work.

If for some reason the FOG front-end is broke and you can’t use it to import/export - you can do the same thing manually. Examples are here in the WiKi: https://wiki.fogproject.org/wiki/index.php/Troubleshoot_MySQL

@TRex You might not be permanently up though.

There’s a known issue with FOG 1.2.0 on Ubuntu 14 and higher - and you just experienced it.

This issue is solved in FOG Trunk.

@Tom-Elliott Yeah, will try to make a video tomorrow or on Friday. So far I have an Acer Laptop and a bunch of PCs based on Asus P5G41T-M which have the same behavior.

@Wayne-Workman I did end up figuring it out. It turns out that our data had left over data from a previous export/import. So that’s why not all of our entries in the both tables had corresponding entry’s while some did.

@Wayne-Workman Not to worried about it now… I am pretty sure even on the 4425 trunk version, the web ui did prompt me to do this and I let it go. In some ways, it was good it did it this way as I inadvertantly revved the production server and had to back track.

check for a bios update and/or use undionly.kkpxe instead of undionly.kpxe (undionly.kkpxe works better with buggy bios/pxe rom configurations)

SOLVED: Had to delete the /var/lib/dhcp/dhcpd.leases file. Started working again like a charm. Thanks again!

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