I understand why this is an issue but cannot explain why it’s happening. Especially as this seems to be a one off problem. While some systems seem to be more prone to this than others it’s still a very strange issue. Part of the strangeness of the issue is it doesn’t actually appear to affect the imaging process in any way. It ultimately is just colors. If I knew what’s causing it, and my suspicion is with the frame buffer console, I might be able to get a fix for this. Again, while I understand the issue it doesn’t appear to actually interfere with the imaging process.

I get what you’re saying. Nonetheless, I would hate to return to unicast because in the rooms where everything works correctly, I can image 35 computers with a 42 GB image in less than 8 minutes. That’s really hard to beat. It’s getting so fast that we can just about use FOG to push out an image whenever we need even small changes made to the room and just forget about using VDI, as that is VDI’s big advantage (i.e., being able to quickly push out changes to a whole room of computers without much hassle).

We could go computer-by-computer to find the culprit, but that’s such a pain. That would be the perfect feature for FOG, as it would know better than any other tool which computer is being the hold-up.

If you’re running FOG 0.32,

The kernel likely “panicked” which would explain the “kernel error” you were seeing. Since 1.0.0 I’ve been building a 64 bit AND a 32 bit kernel. When you downloaded your new kernel, which architecture did you download? My guess is you downloaded the 64 bit kernel and this is where things went south for you.

Also, you state the file “could not be found & the kernel error” This sounds exactly like the information I just told you. The 64bit kernel cannot find a 64 bit init.gz file. It’s because of this you see the “could not be found” AND the reason why you have the kernel error.

If you download the bzImage32 file as your bzImage, things should work more properly for you.

If you haven’t already, run:

[CODE]sudo service tftpd-hpa restart[/CODE]

Thanks Tom. I guess you fix it in last builds. I am going to try it.

there are plenty of other programs to do this (silent application installs while pc is in use). I don’t use snapins in fog.

php files in Ubuntu 14.04 are located in:

/etc/php5/cli/php.ini

tftp boot file locations in Ubuntu 14.04

/var/lib/tftp

it is no longer needed, it just hasn’t been removed.

Thanks Tom!!

Thank you!

I don’t know all of the ports in use but here is a quick list of what I know:

UDP 9 (Wake on Lan)
UDP+TCP 20/21 (FTP)
TCP 80 (Web)

UDP 69 (TFTP/DHCP???)

NFS uses many different ports and We (fog) are telling NFS to go over TCP if that’s any help.

Multicast will generally use all UDP Ports and it varies. But our defaults are anything from 49152 thru 65534

Hopefully this helps. I may have missed a few ports too but this could help you out a little.

Ahh, good to know that’s the intent then. Thank you.

A simple method is to create a folder in “c:\windows\inf” . I use “c:\windows\inf\xinf”.

Because Windows 7 recursively searches folders for drivers, and since Windows 7 searches “c:\windows\inf” by default, there is no configuration required other than to drop each extracted driver into its own folder inside “c:\windows\inf\xinf”.

Be aware, that some drivers are coded for both x86 and x64. Some will load x64 when x86 is required or vice versa, causing a failure of varying degree.

Some drivers for some versions of hardware will load the wrong version and brick the system. I’m looking at you Intel USB 3.0 eXtensible Host Controller (series 7 vs series 8).

I’ve dropped x86 and x64 drivers that play nice together into my xinf folder. I then use a vb script called from sysprep that detects specific needs for specific make/models that we have in service, that then performs installations and configurations, all the while using auto-logon.

Importantly, I disable and set to manual, the FOG Service before I close an image with sysprep. Reactivating the FOG service is the last thing my script does because the FOG Service will ungracefully interrupt any running scripts and force a restart when an image is deployed with naming and domain-joining enabled.

There isn’t a specific number but the total number of hosts in the task, but what you could check is that the FOGMulticastManager service is frunning as well.

[code]sudo service FOGMulticastManager stop
sudo service FOGMulticastManager start[/code]

because the image part, iam working on. and iam not so good at making an universal image of evry singel windows version 🙂 thats why

from the licensing brief: “you may use an OEM recovery image on devices shipped by that OEM provided that the device is appropriately licensed.”
[SIZE=2]if you are restoring computers to backups of themselves, you are perfectly legal. you said you only have 14 computers, so i’m going to assume that the hassle of [/SIZE]acquiring[SIZE=2] volume licensing isn’t worth it for you.[/SIZE]

Thanks for the replies.

you’ll want to edit the default storage node info on the storage management page to change these settings.
i have never used clonezilla, but it might be more in line with what you want

Yes it is possible , no it is not a plugin. Fog configuration-> fog settings -> quick reg settings I think

The location plugin was built to do exactly this. Even down to downloading the init.xz and bzImage from the rekavant location.

Goto FOG Configuration -> FOG Settings -> Plugin and enable plugins. Then go to the plugin page and choose activate plugin. From there choose the locationbplugin. It will install kind of. Choose install plugin and select location. It will ask to install itself. Then you will have a new menu option available. Go to the location page and set up you locations.