in the logs I see the machine tried to access

/fog/service/register.php?mac=00:18:8B:8C:2C:0D&hostname=6P1QBC1&ip=10.10.222.166&os=1
If I view that in a browser from the same machine I get
#!er:Invalid Version Number, please update this module.

I did some google ling, php5-mcrypt seem Ubuntu 14.04 has some issue with it…

The solution (for me) :
updatedb
locate mcrypt.ini
Should show it located at /etc/php5/mods-available
locate mcrypt.so
Edit mcrypt.ini and change extension to match the path to mcrypt.so, example:
extension=/usr/lib/php5/20121212/mcrypt.so [B](this path is missing) [/B]
Now this:
php5enmod mcrypt - (optional since its already enabled during phpmyadmin setup)
Verify that new files exists here (they should be auto created from the issue above)
ls -al /etc/php5/cli/conf.d/20-mcrypt.ini
ls -al /etc/php5/apache2/conf.d/20-mcrypt.ini
Otherwise do the following
Create symbol links now
ln -s /etc/php5/mods-available/mcrypt.ini /etc/php5/cli/conf.d/20-mcrypt.ini
ln -s /etc/php5/mods-available/mcrypt.ini /etc/php5/apache2/conf.d/20-mcrypt.ini
Restart Apacahe
service apache2 restart

and we have a working system again…
Thanks for the support

Doh! I’m a fool. I was not capturing the images as “resizable”.

I converted one of my images to resizable and it appears to be working now.

Thank you!

[quote=“Mark Cheavens, post: 42226, member: 28207”]Still can’t image/deploy a windows7 computer if using single disk resizable.[/quote]
What exactly do you mean by this? Error messages? Deploy going through but windows 7 is damaged afterwards?

Probably a good idea to check the partition tables and see what FOG does with it. Please run a debug upload session with your master pc and run this commands before you start the upload:
[CODE]# sfdisk -d /dev/sda[/CODE]

After downloading the image to another computer you can start another debug session and see how the partition table looks like…

Right, you both confirmed what I’d seen about interface.

Concerning ip add change, the only file I can’t find is the pxe file. Its not in /tftpboot.

So to fix this whole thing i edited the .fogsetings file and I ran the fog install script again to set the ip address to my static one, as the last time I had used the automatic ip.

After that the client could register! Actually, there’s a list of correct things to do in the installation.txt file that I hadn’t read before, about setting static ip before install of fog. Perhaps the user guide should mention that file?

Thanks guys for this software…. We are donating 100s of computers to villages in the malayan jungle so fog is crucial.

[QUOTE] The Username (in either settings or the host) is the Active Directory username and password pair.[/QUOTE]
That was my mistake… 🙂
I correct that and now it s working

Thanks a lot !

2/12/2015 2:21 PM FOG::SnapinClient The remote server returned an error: (500) Internal Server Error.
2/12/2015 2:21 PM FOG::SnapinClient at System.Net.WebClient.DownloadFile(Uri address, String fileName)
at System.Net.WebClient.DownloadFile(String address, String fileName)
at FOG.SnapinClient.startWatching()
2/12/2015 2:21 PM FOG::SnapinClient Attempting to connect to fog server…
2/12/2015 2:21 PM FOG::SnapinClient Module is active…
2/12/2015 2:21 PM FOG::SnapinClient Snapin Found:
2/12/2015 2:21 PM FOG::SnapinClient ID: 2
2/12/2015 2:21 PM FOG::SnapinClient RunWith:
2/12/2015 2:21 PM FOG::SnapinClient RunWithArgs:
2/12/2015 2:21 PM FOG::SnapinClient Name: Libre Office Installer
2/12/2015 2:21 PM FOG::SnapinClient Created: 2015-02-12 17:35:26
2/12/2015 2:21 PM FOG::SnapinClient Args:
2/12/2015 2:21 PM FOG::SnapinClient Reboot: No
2/12/2015 2:21 PM FOG::SnapinClient Starting FOG Snapin Download

Which lead me to inspect my php config and I found the issue. Memory_limit was way too low.

During the fog upgrade fog tried to install php which failed conflicting with php53. So uninstalled that and let it install php. That broke fog, so we swapped back to php53. I think during that we lost some config settings.

It appears I know have it working.

Might be nice to not have fog try to install php if a php is already installed.

3006 should’ve fixed this, but better to use 3009 as I found a few other issues.

I just wanted to chime in - my issue was the target disk was slightly smaller than the original as well (physical to ssd and assuming, without double-checking).

[FONT=Consolas]Ah ha, fixed![/FONT]
[FONT=Consolas]sudo ln -s [B]-r[/B] undionly.kpxe undionly.0[/FONT]
[FONT=Consolas]Looks like some people may need the -r switch too, if you create it within that folder![/FONT]

have you disabled or reconfigured the firewall to allow tftp file requests?

[quote=“Tom Elliott, post: 41986, member: 7271”]You can maintain the same size at 150, or 500.

However, you will need to upsize the amount of ram. I forget if this is even possible on 0.32. Basically FOG Configuration->FOG Settings->General Settings->TFTP Server->FOG_KERNEL_RAMDISK_SIZE

Change it from 127000 to say 600000 (to allow the size of 500MB if you wanted it.[/quote]

Thanks again sir tom, i have tried it again and it always failed around 80 percent again failed to write again. the space is @ 250mb is it still the size of the acocated space on tftp that causes this? if i cant make this work can you recommend me some newer version of fog that doesn’t need to update the ClamAV

What’s happening when you start the hardware inventory task? Does the client boot up in PXE and then…? You should see this on the screen after the kernel loaded:
[CODE]* Using disk device…

Starting host registration…[/CODE]
Do you get this far?

[quote=“Tom Elliott, post: 42038, member: 7271”]I am guessing it has to deal with your cache on the browser. You may think about refreshing the page completely and maybe you’re presented with the login page?[/quote]

Brilliant! That did the trick. Thanks as always Tom!

To a certain point, yes multicast is faster in performance, but it uses UDP with broadcasting all the “image’s” packets across your network. Unicast uses TCP directing the traffic to that particular machine. If on a separate network you will not see any issues either way. If on the same network (using multicast) you will find that your “bandwidth” will be effected throughout the entire network.

As i said before, Uncle Frank put me on the good way (DHCP issue). I tried before many options on the switch, and no one worked. My method for this was really empiric : many tests, many failed tests and - at least with DHCP relay - i succeed. It’s strange that a DHCP relay is necessary : all pc’s are on the same subnet. I don’t uderstand why, and i’m a little bit annoyed about this but it works for now. I made a upload/download with success. I hope that this DHCP relay won’t generate some issues on the network !

Thanks for the update. That’s really weird and I still can’t get my head around what’s going on there. As I said, I’ve tried to reproduce the issue but I just can’t do it. Very special. Would be great if you keep us posted on new findings.

The latest code as released by the developers it is updated daily sometimes. See [url]http://www.fogproject.org/wiki/index.php/SVN[/url]

this is a little embarrassing. I dont know if i am losing my mind or if a co-worker is fucking with me but the dhcp settings were removed. We are using windows dhcp, added options 66 and 67 back in and its working again.

Thanks a lot guys. This community is great!