Well, I’m all good. ThreeGrizzly originally posted the problem.

Oh and the upgrade to the current version is in the pipeline. We just did so much customization on 0.32 that we’re moving a little slow on upgrading.

Oooh, the symbolic link would be a pretty neat work around! Thanks Wayne!

Sadly and/or stupidly I finally noticed that our partition for the FOG images was full and that appears to have been causing the problem. …So many clues.
I’ll know for sure in a few hours.

We started having the same problem today on 0.32. There’s a “d1.mbr” and a “d1p1.img” but, not a “d1p1.img.001” for any image in their directories.

-rwxrwxrwx 1 root root 512 Jun 2 13:16 d1.mbr
-rwxrwxrwx 1 root root 77976571904 Jun 2 14:30 d1p1.img

If I re-type the path into the error box, omitting the “.001” part, it’ll finish imaging and boot normally. …We can’t do that several hundred times though.

I know this is an old post but, I finally got annoyed by the “List All Snap-ins” requires a search first bug on our FOG 0.32 install, was looking to fix it and found this thread.

The search page assigns a variable, [COLOR=#339966]$_SESSION[“allow_ajax_snapin”][/COLOR], to [B]true[/B] but the list page does not. Until that variable is defined as true the List All Snap-Ins page won’t work. There’s a couple of ways to fix it but, I just assigned it to true in [COLOR=#0000ff]/var/www/html/fog/management/includes/snapin.list.include.php[/COLOR] on line 37 so, that the search page will work the first time:
[code] <tbody>
<?php
$crit = ‘%’;
$_SESSION[“allow_ajax_snapin”] = true;
require(‘ajax/snapin.search.php’);
?>
</tbody>[/code]

Ah, I found what I was initially thinking of with the “recompile” statement before. I finally remembered while adding a kill-all snapins button to the GUI this morning on 0.32.

Snapins were taking too long to deploy for our taste at first (we got over it). That was hard coded on line 129 of [COLOR=#0000ff]fog_0.32/FOG Service/src/FOG_SnapinClient/MOD_SnapinClient.cs [/COLOR]for a time between 350 and 500 seconds. That then hat to be compiled and then we had to put our new [COLOR=#0000ff]SnapinClient.dll[/COLOR] in [COLOR=#0000ff]C:\Program Files(x86)\FOG[/COLOR] on our Windows 7 images.

…not really topical but it was bugging me.

Might want to also check this part:

------------------------------------------------------------------------

How often do you want to service to hit the web server (in seconds)

------------------------------------------------------------------------

    checkintime=302

There it is!

------------------------------------------------------------------------

Where do you want the FOG Service to write it’s log?

------------------------------------------------------------------------

    logfile=c:\fog.log

---

In [COLOR=#0000ff]C:\Program Files\FOG\etc\config.ini[/COLOR] edit this line and I imagine you’ll be good to go once you restart the fog service or just reboot.

Oh yeah! Setting up some centralized logging for that would be pretty neat …or just not writing to the root of the [COLOR=#0000ff]C:[/COLOR] drive. Was the path an option in the [COLOR=#0000ff]C:\Program Files\FOG\etc\config.ini[/COLOR]? I don’t have super convenient access to a client right this second.

I’m not seeing a [COLOR=#0000ff]fog.log[/COLOR] on my system just now via “find / -name fog.log -type f”
There’s [COLOR=#0000ff]fogreplicator.log[/COLOR], [COLOR=#0000ff]fogscheduler.log[/COLOR] and [COLOR=#0000ff]multicast.log[/COLOR]* in [COLOR=#0000ff]/opt/fog/log[/COLOR]. Those are defined in [COLOR=#0000ff]/opt/fog/service/etc/config.php[/COLOR] and [COLOR=#0000ff]/var/www/html/fog/management/includes/about.log.include.php[/COLOR] which also uses [COLOR=#008000]FOG_UTIL_BASE[/COLOR] defined in the GUI via [B]Other Information > FOG Settings > FOG Utils > FOG_UTIL_BASE[/B] …if that does anything for you.

I can’t seem to find it now but, as I recall the check-in interval on the FOG client was hard coded into the source code so, you’d have to download it, edit it and recompile it.

Maybe watch [COLOR=#0000ff]/var/log/messages[/COLOR] on your fog server as it is happening. You should see something like the following:

udpcast[####]: New connection from [I]<ip_address>[/I] (#0)
udpcast[####]: first connection: min wait[0] secs - [COLOR=#ff0000]max wait[###][/COLOR] - min clients[2]
udpcast[####]: New connection from [I]<ip_address>[/I] (#1)
udpcast[####]: min receivers[24] reached: starting udpcast[####]: Starting transfer: file[] pipe[] port[63###] if[eth0]

This will show you if the multicast started deploying before all the clients checked in due to reaching the “[COLOR=#ff0000]max wait[/COLOR]” point. That could just mean that some clients are taking to long to reboot. You can edit the timeout in [COLOR=#0000ff]/opt/fog/service/etc/config.php [/COLOR]by changing the [COLOR=#008000]UDPSENDER_MAXWAIT[/COLOR] value (in seconds)

Yay! I’m glad I could help.

Check out [url]http://fogproject.org/forum/threads/snow-screen-with-hp-elitebook-8460p.164/[/url] and/or try a different kernel.

Just to add, you can export you Excel spreadsheet to a CSV assuming you set it up to match the requirements.

There’s an example in the wiki at [url]http://www.fogproject.org/wiki/index.php/Managing_FOG#Method_4:_Uploading_Host_Information[/url]

To summarize, you just need to create a plain text file with each line designating a host in this format:
[CODE]MAC Address, Host name, IP Address, Description, OSID , ImageID[/CODE]

Here’s an example for 4 lab computers w/ no IP or description:
[CODE]“B8:AC:6F:3F:A9:34”,“LABPC-1”,“”,“”,“5”,“15”
“B8:AC:6F:3F:A9:19”,“LABPC-2”,“”,“”,“5”,“15”
“B8:AC:6F:3F:A9:EF”,“LABPC-3”,“”,“”,“5”,“15”
“B8:AC:6F:3F:A8:F4”,“LABPC-4”,“”,“”,“5”,“15” [/CODE]

Although, FOG 0.32 has a bug where it ignored the ImageID. I added line 51 below to /var/www/html/fog/management/includes/hosts.upload.include.php to fix that (line numbers shown):

[CODE]48 $img = $core->getImageManager()->getImageById( $data[5] );
49 $mac = new MACAddress($data[0]);
50 $host = new Host(-1, $data[1], $data[3] . " “._(“Uploaded by batch import on”).” " . date(“F j, Y, g:i a”), $data[2], null, $mac, $data[4]);
51 $host->setImage( $img );[/CODE]

I’d love to volunteer FWIW but, I work for a University where we are not allowed to contribute to GPLv3 projects.
We can only file bug reports and snippets of code.

I believe it’s space separated

I’d almost forgotten about that - we’re still using the 239 hack for now.
The main change I wanted to make was to dynamically find the last three octets of the FOG servers IP address instead of statically assigning it. I can imagine, if we ever had to change the FOG server’s IP, that this static assignment might cause some problems until we remember that we had done that.

I should have said that “you can turn it off [b]theoretically[/b]”. I experienced the same thing as you are during our evaluation/testing but, we were already controlling auto logoff via Group Policy in production (and scheduled shutdown/starts via FOG). We were not planning to use this feature so, I didn’t get too far into it - I only found that quote from the wiki because it surprised me that “Auto Logoff” was rebooting machines instead of just logging off the current user.

Yeah, that’s what I experienced.
Check if [B]forcerestart[/B] is set to[B] [B]1[/B] [/B]on the client in[B] [B]C:\Program Files (x86)\FOG\etc\config.ini[/B][/B]. You can turn it off by changing this to[B] [B]0[/B].[/B]