I solved it with kind of a workaround. I ended up recreating image to be PartClone as this was old image from 0.32 fog and it was PartImage.

I will try your suggestion if I get the same error with the image which can’t be recreated. Thank you.

You could reinstall fog.

That will make a copy of your current /var/www/{html/,}fog folder in /var/www/fog.prev and place the contents of the default fog web folder in it’s relevant location.

I second Junkhackers statement. Typically, people place VoIP and Computer systems on separate networks. This serves two purposes.

It ensures traffic for VoIP is separated and uninterrupted by everyday network traffic.

It ensures somebody doesn’t accidentally get misleading information for troubleshooting within the network.

Unless your VoIP phones are being handed the exact same IP range as the systems (Highly recommend against) Windows DHCP Scope options can be specified per scope, not per server. This means, if you have 3 networks being handled by the same DHCP server, you can have each network find and get their relevant information all separate from one another.

For example,

192.168.1.X is looking to get Option 66/67 from 192.168.1.5 and undionly.kpxe

172.16.X.X is looking to get Option 66/67 from 172.16.15.1 and pxelinux.0

10.X.X.X is looking to get Option 66/67 from 10.2.5.3 and receives the VoIP phone tftp files.

Again, that’s just a simple break down, but this can all be done from a singular DHCP server.

That message means that all hosts within the group do not have the same image assigned to it

What version BIOS on the M72e are you using?

What BIOS settings do you set after [F9] Load setup default configuration?

[IMG]http://s27.postimg.org/4jsxfuugz/Capture.png[/IMG]

the fog username and password was the one that was given when I ran installfog.sh and setup the node.

Also,

Make sure your connecting to the proper database. The file /var/www/fog/lib/fog/Config.class.php should have only 4 lines that really deal with connecting to the database server. They fall under the method db_settings.

The major ones to be aware of are:
DATABASE_HOST
DATABASE_USERNAME
DATABASE_PASSWORD

Make sure these values are set correctly. Also verify the DATABASE_NAME is set correctly pertaining to your database (default is fog)

The USERNAME for a Server is typically root

The HOST for a server is typically 127.0.0.1 or localhost

The password is whatever you set during install time if you set one. If not it will most likely be “” or ‘’

If you’re not connecting to 127.0.0.1/localhost and actually connecting to an IP address of your fog server (e.g. 10.59.32.10) Then chances are, i’m going to guess here, you’re running ubuntu or debian derivative of some sort? Make sure the /etc/mysql/my.cnf has a commented bind-address line and if you have to change this line to make it commented (make it look like #bind-address), restart the mysql service.[code]sudo service mysql restart[/code]

Thanks for the response, i did find other post, sorry for this one. Which one should i comment on ? Fixparst showing that the created size for the partition to deploy on is wrong sized.

I’m not a big fan of the username and password in scripts either, but then I discovered a command to make the script delete itself and its containing directory at the end of the script. Just add this to the end
cd …
rmdir .\dir /S /Q & exit

or to delete just the script try this
del /f/q “%~0” | exit

Hope that helps

For anyone that is following this thread, this issue has been resolved and should be included in the 1.3.0 release.

I you are using host specific kernel settings, that will work for any tasks you setup through the WebUI in FOG, but will not work for tasks selected from the PXE boot menu. If you have a gmail account, I can share my kernel with you. Just PM me your email.

The trust relationship between the AD and the computer is based on the Computer Account Password which is saved as part of the computer object in the AD.

By default, trust relationship and computer account passwords are negotiated every thirty days, except for computer accounts that can be disabled by the administrator.

This password is generated, negotiated and maintained by the computer, entirely silently. A short history of passwords is supposed to be maintained by the AD for each computer object, in the case of some synchronization problems. However, this can easily be fubar’d if the computer undergoes one too many recovery sessions to restore points, is away from the domain too long to have been able to properly recognise the new password, or your AD has been restored to a previous restore point.

If you are capturing an image that is already joined to the domain, stop doing that.

The recommended fix from MS for a computer that no longer is trusted by the AD is:

From the client, remove it from the domain. Delete the computer object from the AD. Join the computer to the domain.

… Or …

Logon as a local Administrator CMD: netdom /resetpwd /server:YourDC /userD:Your.Domain\YourADAccount /passwordD:* /SecurePasswordPrompt

There are other scripting and powershell options as well.

See [url]http://support.microsoft.com/kb/216393[/url] for more information.

This problem can also be remediated by changing the default behaviour of the client by extending the lifespan of the computer account password through local Group Policy.

Okay, gave up on this since I needed an operational image server to finish deploying PCs that replaced the last of our XP boxes. Uninstalled Fog on 14.04 following these instructions ([B]excluding[/B] the removal of the /images directory):

[URL=‘http://www.fogproject.org/wiki/index.php?title=Uninstall_FOG’]http://www.fogproject.org/wiki/index.php?title=Uninstall_FOG
[/URL]
Re-installed Fog 1.2.0 on same Ubuntu 14.04 server. Existing images from old Fog server still in /images. I opted not to try to import anything else from the old Fog 0.32 server. Created new image entries and assigned the corresponding image file names. I did a trial run by uploading an image from a Dell OptiPlex 390 with some success. Will be testing more today for functionality and stability.

[quote=“KOA-IT, post: 36528, member: 25995”]Hi,

You might want to check my post out here: [url]http://fogproject.org/forum/threads/domain-join-not-working-since-moving-to-v1-2-0-error-87.11642/[/url]

If you change the settings in the configuration area the change does not update in the individual/group hosts so you need to check your settings in the config area match up and then go and replicate your change on either the one host you want to fog… the easier way of doing it is to replicate the configuration change for the groups you have the hosts in, if you’ve grouped them.

Hope this helps you out :)[/quote]

Hello KOA-IT,

Your post was the answer I was looking for. I was changing the AD Settings in FOG Settings. I didnt realise the changes were not replicating to the hosts/groups. Once I changed it in the groups it all started working.

Thank you very much for your help. Now I can reimage our computer labs.

So here is some stuff I pulled from my Apache2 error logs. Don’t know if its related to the unable to resolve hostname. I can ping IPs from FOG (and in the web UI when I list all hosts, it shows a little graphic at the top saying it is pinging all hosts, although there are still red exclamations on everything), but not hostnames which I am not entirely sure I am doing correctly.

[CODE][Thu Sep 11 19:57:43 2014] [error] [client 1.1.1.1] (13)Permission denied: access to /fog/management/index.php denied, referer: http://--------.edu/fog/managemen$
[Thu Sep 11 19:57:43 2014] [error] [client 1.1.1.1] (13)Permission denied: access to /fog/service/servicemodule-active.php denied
[Thu Sep 11 19:57:44 2014] [error] [client 1.1.1.1] (13)Permission denied: access to /fog/index.php denied, referer: http://fogserver.whatever[/CODE]
(different IPs and server name)

Any chance I might be on to something at least?

The SVN Version 2272. But i belive i fixed it. i used the default bzImage and unicast create/deploy image is working. only multicast is not working but i thinks its better to discuss this in the other thread 😉

id the name change service enabled? It sounds to me like the computer name doesn’t match what FOG thinks it should be and is attempting to set it, and rebooting to complete the change.

I know you are trying to get it to join to the domain, but lets test pieces at a time. Disable the name change service and see if that helps with the reboots.

Think I may have solved this, I didn’t realize that FOG saved the AD settings “inside” each host instead of using the settings specified in the configuration area. Will see if I’ve fixed it now. - Will update this post with result in case anyone else hits the same barrier.

That was the solution…
For people suffering with difficulties make sure the actual host has got the correct credentials as it didn’t apply globally when I changed it in the configuration area. See image below for the secondary configuration I needed to do.

[ATTACH]1363[/ATTACH]

Thank you for your help with this issue, I hope this helps others as well.

[url=“/_imported_xf_attachments/1/1363_fixed.png?:”]fixed.png[/url]

[quote=“Mentaloid, post: 36203, member: 4362”]You upgraded to 1.2.0? If so, you might want to verify that the default domain settings are correct in FOG config, noting that the domain portion should NOT be included in the username anymore.

If you have clients that are not using the default (as in you specified the OU, and therefore the rest of the domain settings as well), then you may need to double check the individual clients/groups as well for misconfigured domain/user’s[/quote]
hmmm thats interesting. i will have to try that when i return to work. the domain user section that is. When i searched the 2202 error is an AD authentication error and not a fog error, stating that the provided name is incorrect or in wrong format

Well, while I do make schema changes often, it’s not going to degrade the DB as that’s too much work. If there’s db values inserted, it’s all new stuff, and therefore wouldn’t matter to the FOG System as they most likely won’t even be updating anything.