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.
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:
checkintime=302
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.