@wayne-workman
Thanks, next time i will take some time before acting and wasting my time.
I keep this guide for the next time.
Thank.
Eric.

@msi said in Image capture task did not complete:

By the way, love the new look on the FOG

@Joe-Schmitt

@jburston see the wiki article called “password central”. If you need further help, please open a new thread for the new issue and post the last 200 or so lines from your fog.log file.

Fixed by changing memory size in php.ini

@tom-elliott yes it went back to the full amount.

@george1421 He’s referring to the autologout module, but you’re definitely not wrong.

@blkeller, duly noted. Updating the time restraints means updating the entry in SQL, not hard, and I can have that done fairly easily. Even not allowing the setting to hold on to anything less than 5 minutes isn’t too hard, though do I set it to 0 if it’s below 5? Just thoughts on how best to approach. I don’t think it should warrant an “error” to update the host because that field isn’t really necessary for normal imaging functions.

@wayne-workman Absolutely. As soon as I can I will.

@Julianh I am sorry to say that but your setup is quiet complex with so many disks mounted in various locations and I don’t think we’ll be able to reliably guide you through a migration here in the forums. I am not sure what to advice. As Wayne said, 1.4.4 can deploy 1.2 images. So unmounting and moving the disks to the new system should work.

@x23piracy Missing since RC10 - see here: https://github.com/FOGProject/fogproject/tree/1.5.0-RC-10/packages/tftp

@Tom-Elliott We should definitely put up a big note for the final 1.5 release.

@shad0wguy It would be helpful once you prove this setup as reliable, if you could write a tutorial explaining how you setup FOG on this device as well as what others need to watch out for. I don’t think the FOG Project developers will support this configuration directly, but I’m sure there are others in certain situations with your exact use case. Your configuration may help guide them.

Please consider contributing to the cause, if you can.

@tesparza well that would certainty do it. Reset Encryption Data is generally not advised to be done unless you specially do something to the client that would require it.

Hey Guys, thanks for leading me in the correct direction… one of our NEs worked with me today, what we found was… well… lets just say that I am glad I am a server engineer and not a network engineer.

We config’ed one port for Spanning tree fast port and it connects correctly. Now I have to go back to my Sys Eng and ask him WTF?!?!

Thanks again,

Rbryant

@dylanderr Please read through this:
https://wiki.fogproject.org/wiki/index.php?title=Password_Central#For_Storage_Nodes

The settings you set in the web UI only tells the fog services what credentials to use, it does not set the actual password in mysql. I will clarify this in the article, thanks for pointing it out.

@boyan-biandov We have an article now that details how to migrate FOG safely: https://wiki.fogproject.org/wiki/index.php?title=Migrate_FOG

I’m going to assume that once a volume has been encrypted, it remains that way even if bitlocker gets turned off, but it simply lends anyone access to it. (and is therefore generally not an issue for users).

If you could please use the commands Sebastian posted so we can see what partitions we’re dealing with, we might be able to figure this out.

@wayne-workman said in Image not syncing between nodes:

If you run this command from your Master Node, it will prompt you for the storage node’s local fog user’s password. You can find that in that node’s storage management area or from this file on it: /opt/fog/.fogsettings

rsync <options> <source> <destination>

rsync -r --bwlimit=6250 fog@10.134.200.230:/images/Laptop2.1 /images rsync -r --bwlimit=6250 fog@10.134.200.230:/images/Laptop /images

The 6250 is supposed to be 6250Kbps, or 50Mbps. If you want slower, you can do the math to figure out what you need with the calculator I reference below.

It took some times but it is working after issuing the rsync command. I had to delete the image from the NJED node after rsync completion.

@tom-elliott

[root@ianos ~]# ls -lhat /var/www total 4.0K drwxr-xr-x 4 root root 47 Feb 4 21:54 html drwxr-xr-x 4 root root 41 Feb 3 23:26 . lrwxrwxrwx 1 root root 18 Feb 3 23:26 fog -> /var/www/html/fog/ drwxr-xr-x 2 root root 6 Oct 19 23:39 cgi-bin drwxr-xr-x. 22 root root 4.0K Aug 21 21:29 .. [root@ianos ~]# ls -lhat /var/www/html total 12K drwxr-xr-x 13 apache apache 4.0K Feb 4 22:31 fog drwxr-xr-x 4 root root 47 Feb 4 21:54 . drwxr-xr-x 4 root root 41 Feb 3 23:26 .. -rw-r--r-- 1 root root 45 Jan 29 2015 index.php

Although the above don’t seem erroneous to me, I followed your advice and deleted
/var/www/fog and /var/www/html/fog. After re-running the installer multicasting works as it should. Apparently it was a right guess 😉
Thanks a lot for your nice work!

@gmonk I use Fog 1.3.3 for all my windows 10 captures and deploys works great in VM.

@sebastian-roth Here is a new thread: https://forums.fogproject.org/topic/11393/chromium-image-issues-after-updating-server

I got past the NFS-problem by changing the mount string! Thank you. 🙂