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.

'Cause I wasn’t on site and deployed the task remotely It turned out that FOG couldn’t wake all the computers from Lan in that particular case. But still not all the computers join the Multicast session, some of them are just waiting on the screen with partclone. And I think is because of the [FONT=Ubuntu][COLOR=#555555]FOG_UDPCAST_MAXWAIT[/COLOR][/FONT]
It’s set to 10 in the config of FOG the hint says this is in MINUTES but I think (I’m sure) It’s in seconds, so I increased it to 100 and set the value define( “UDPSENDER_MAXWAIT”, null ); to define( “UDPSENDER_MAXWAIT”, 180 ); in the var/www/html/fog/lib/fog/Config.class.php file. Now I’m having more machines joining and actually participating in the Multicast Image Process.

UPDATE: The 4 machines are imaged OK but the others are still in the QUEUE and the listing of the Active Multicast Tasks says there are NO multicast tasks.

I added 15 computers to a new group with a Image associated to the group and made a Multicast task for imaging this computers, but when the FOG server wakes up the machines via WoL the imaging process begins only to some of them (4) and the others are listed as queued in the web interface and even after the 4 machines are imaged the job does not continue to another 4 or all of the others which are queued.

I’m running the latest TRUNK fog (v. 2924) on CentOS Linux. I had no problems before when I was running 1.2 (stable) fog.
So is it some configurational setup I have to make or is it some kind of BUG?[ATTACH]1628[/ATTACH][ATTACH]1629[/ATTACH]

[url=“/_imported_xf_attachments/1/1628_Multicast-task-active.png?:”]Multicast-task-active.png[/url][url=“/_imported_xf_attachments/1/1629_Multicast-tasks-list.png?:”]Multicast-tasks-list.png[/url]

Understood. Thank you.

I have fresh install of FOG and ran a Image Uploading task in debug mode and it says that It’l save the mbr sectors in /usr/share/fog/mbr/{myimagename}.mbr, but I do not have such a directory, nor I have any kind of *.mbr files on my system. Running Fog 1.2.

Absolutely no luck! I unchecked the chkdsk option and nothing. No resizing. I reinstalled my CentOS and newly installed fog stable version 1.2, uploaded my master image from VirtualBox to FOG, then deployed it to a real machine and still no resizing. I began to think that my Windows 7 master installation has problems , but It’s awkward that when making the master image with clonezilla from time to time I have the same problem, but rarely, and all I had to do is to retake the image. So maybe my problem is in another place.

[quote=“jmeyer, post: 37232, member: 6537”]Not sure of this but there is check disk thing in options -> general settings -> FOG_DISABLE_CHKDSK
It looks disabled for me because it’s ticked.
Maybe translation isn’t good ?[/quote]

Yes it was disabled [checked] in my config. Tomorrow when I go to office will try deploying the image with this option unset. And I’ll get you posted. Thanks for your post.

It was 1. 2 but after this problems I decided to use latest as of time svn 2353 build and that did not change nothing

Just to clarify: It’s not my first time making images with FOG, the image is selected rightfully, single disk, multiple partition (resizable), taken down from the VirtualBox and then uploaded to a real hardware. The image is made as described by the thread about Universal Windows 7 with SAD drivers deploying in this forum and It was working superbly up until now. I’m using the latest SVN trunk (2353). When using clonezilla for creating and deploying the same image i’ve noticed that just after deploying image and restarting the process and booting from HDD, the first thing that is being done is disk checking by the automated Windows 7 hardware independable installation and all is GOOD, but my failing FOG deployment does not run Windows disk checking.
P.S. Tomorrow I’ll run Single Disk, Multiple Partitions (not Resizable) type of image.