If a user is logged on to a client machine the only way I can schedule a FOG upload is to send a shutdown/restart command to the client machine via the Linux scheduler.

Just tried reinstalling CentOS 6.6 and it gave the same error. I’m going to try CentOS 7 later today when I have more time.

CONFIRMED! It was an update (trunk ver. 2924) issue. The [FONT=Ubuntu][COLOR=#555555]FOG_UDPCAST_MAXWAIT [/COLOR][/FONT][COLOR=#000000]was set as default to 10 in the config settings of the web interface but the latest update as of the time (trunk 2924) was wrongly set up to seconds not minutes, so there was no enough time for all the multicast participants to join the multicast task. I can confirm it is fixed in [/COLOR]SVN 2926 like [URL=‘http://fogproject.org/forum/members/tom-elliott.7271/’][SIZE=13px][B]Tom Elliott[/B][/SIZE][/URL] says.

That seems to have fixed it thank you.

Correct,

Old style images had no reference as to the size (on client) ever started or used. So only Partclone images will have On Client sizes.

That said, this isn’t in reference to on client it’s in reference to on server, which I’m already aware of what’s wrong and the fix is in SVN.

The simple answer, because it’s Ubuntu, the “harder” answer, because it’s using upstart/systemd.

The answer to make it “automated” as you request, can be found on the forums. Specifically look for one of my posts today where I go almost fully in depth. I forget where.

That fixed it. Thanks!

worked for me; here is the line:

[CODE]date.timezone = America/Los_Angeles[/CODE]

I can try to help but if you’re on 1.2.0 you’re rather restricted to advanced menu. There is no need to edit any files on the server with the current setup.

Hello,

The problem was the extended partition if you have a dual boot.

what you’re seeing is actually a glitch that happens with some bios. the standard screen is blue and white. of the people who have reported the improper color issue, none of the systems have actually had any problems with functionality.

Think I figured it out. I had installed the locations plugin to see what it was all about. However I never had configured it…so one I added a location…it seems to be ok now. !

it doesn’t install anything, it makes nothing.

@ installfog.log only is

Script started on Sa 17 Jan 2015 22:34:22 CET
Debian

Also is this on upload or download tasks it is important

Though I will admit, I don’t know if we tested XP/2000 OSID type.

Known about issue and is fixed in SVN.

We narrowed what the issue was. On current SVN versions we are not specifying the version number of fog in the init. This displays when the banner is displayed and this was where the issue was/is occurring. The reason for the banner to be stuck is his system would boot and everything just fine. However the os layer is being assigned an ip outside of the fog dhcp controller. For example if his network main has a dhcp server handing out IPs in the 172.16 range while the fog dhcp is handling 10.x.x.x range, boot up would get the 10.x.x.x range but the init would get ip in 172.16.x.x range.

Just perfect, thank you very much!

We wanted to know what your server version was b/c there are may things you must do if you are moving from 0.32 to 1.x.x. So many things there is a nice wiki for it.
[LIST=1]
[*]I guess I haven’t as of yet. I keep rebuilding my images yearly and deploy soon after they are finished. You could always ftp them over to the “master” server before connecting the storage nodes. then just create the images in the web gui. as long as you drop the images in /images and name them exactly the same then you should be ok.
[/LIST]
You may also want to export your hosts and export you database. This will get you back in action faster.