No problem, glad to hear it’s working!

There is no good reason to still be using the 10.04 LTS branch. There are newer LTS branches out. However, this all comes down to personal setup and preference, and does not impact FOG.

[quote=“Tom Elliott, post: 37288, member: 7271”]It will try running all tasks at the same time, thus failing to create one or the other that’s already been created.[/quote]

Thanks Tom,

Is there a way to put the tasks in a queue?

Or, should I schedule the tasks at different times allowing enough time for the upload before scheduling the next task.

Thanks, Geoff

you should not need any automated logins for FOG. As long as the NIC works and has drivers you should be fine all the way to joining the domain.

if you click on export csv instead of pdf, you get all of that data

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