For whatever reason fog needs to be connected to the internet or you will get that error. since I have sonicwall doing dchp it doesn’t support option 66 with IP address only hostname.

Since I had to image using fog dhcp I removed the PC and server from the reset of the network… It didn’t like that.

Once it began copying the image I connected it back to the rest of the network with internet access and it didn’t have issues anymore.

Good post. I ran 0.32 under Debian 7.4 for a while. I did have to do the first three modifications, but I never ran into the ‘Unable to Mount NFS Volume’ issue.

That being said, after I switched to Fog 1.0.0 and did a clean install, I did not have to make any modifications to get it to work. So good news for Debian users as we move forward.

downloads of partimage format images are supported for backward compatibility, but all uploads are done in partclone format. partclone uploads can be sped up by reducing the compression level on the settings page.

// Proxy
if ($Proxy)
{
$ContextOptions[‘http’][‘proxy’] = ‘tcp://’ . $Proxy;
$ContextOptions[‘http’][‘request_fulluri’] = true;
}
This what line 3506 looks like in /var/www/fog/commons/functions.include.php

[quote=“falko, post: 26602, member: 48”]Just wanted to chime in and say I install windows 7 as default from disc (ie. 100mb partition + Second partition as OS) and for years I have always used [I][SIZE=12px]Windows 7 image that was "Single Partition (NTFS Only, Resizable). [/SIZE][/I]

[SIZE=12px]Never had an issue[/SIZE][/quote]

I’m also to guess that you were sysprepping/generalizing your images first?

My init.gz fixes the problem for 0.32, if anyone else needs a copy send me a message.

thank you, this helped… now I do have the problem that the machine is not booting into PXE… I will look up the forum and wiki…

I just wanted to add my findings to this thread. Ubuntu 14.10 fresh install, fully updated, downloaded Fog .33b via svn. I got this error repeatedly until I installed it from my user account and not the root account. So if you have enabled and are using the root user via being logged in, it can give this error. Took me WAY to long to figure it out. I don’t know why as I’m not a Linux user but that was my solution.

Updated bios to A18 on those and still same issue.

That is already known issue and in these forums, and I believe it’s on the WIKI.

Hello,

I was downloading and install ubuntu 14.04 after this i’ve installed Fog 1.0.0 on machine with intel core i7 and 32 gb everything was fine. When i put the server adres to connect on fog ex: XXXX/fog/management my pc is freezing the webpage also … i can’t do nothing, i was trying to connect on site online and offline… but no result only if i restart my computer… i can’t acces fog from http. And i don’t have on my ethernet when i want to deploy or upload on image on fog eth0 there… and no DCHP service on. I was read on wiki on forums on tutorials and i was installing correct ubuntu and also fog.
It’s other person who have the same problem? It’s a bug or im to stupid?

That “decryption” actually is the plaintext password.

sudo mysqldump -u root --allow-keywords -x -v fog > fogbackup.sql

Setting a service to Automatic Delayed will delay a service for two minutes after all automatic services are run.

I thought about possible downsides of delaying the fog service, but in my situation I haven’t found any show stoppers yet.

Our images have the fog service starting as Automatic so on first startup after deployment when the machines are connected wired all is normal with no delays. They rename and join the domain as per usual. We have a GPO that changes the fog service to Automatic Delayed but of course that doesn’t get applied until after the machine has joined the domain.

This sequence seems to work fine for me so I’m sticking with it until we decide to have a look at 0.33

Thanks again to the development team for all of their fine work.

Sebastian, Try adjusting the Compression ratio on 0.33. This can now be done through the FOG GUI under FOG Configuration->FOG Settings->FOG Boot Settings->FOG_PIGZ_COMP.

It has a range of 0 thru 9. A 9 is the highest compression rating and takes the longest time to process and upload as it is compressing data quite a bit. 0 is the worst compression rating, and takes the shortest time to process and upload. In years past, the default was at 3, but it was Hardcoded into the init.gz file. This setting allows you to decide how much compression you would like. It auto set’s at 9 though so I would start here.

Or go to the proper link displayed at the bottom of the installer:

[url]http://10.0.0.10/fog/management[/url] for example.

I don’t think we need to delete the post as it may help others.

Update…I had to copy off the /images folder…750GB!!! lol…
Backed up the fog mysql database and re-built the Ubuntu server 12.0.4
Re-installed fog, restored the database and /images folder.

It works now. I would advise everyone who hasn’t found a logical answer to their problems to rebuild the server that fog is installed on.
In the end, something was not working right on the server, no fault of FOG or the Developers.

Just my 2 cents. Hope this helps someone else out.

yup tried that too, doesnt fix the issue. The problem is the workflow - client computer set to upload a new image - folder is created under /images/dev, then is transported to its final spot /images/(image name) . This normally works flawlessly. Yet, it seems that because “root” is the owner of the temporary folder, it wont allow “fog” to copy it and then remove it from its temporary spot. Since this process in fog is consecutive and unattended, there’s no time to pause and chmod or chown the folder.

Basically I need to make “fog” be the users who creates the temporary image folder. Yet, right now, its “root” who has that honor. I need to figure out where I can assign “fog” for the folder creation process.

it’s theoretically possible. the computer could be going into “low power mode.” if you test this, please let us know.