[url]http://fogproject.org/forum/threads/requests-for-wiki-access-ask-here.3811/[/url]

Sorry I can’t be of more help, I set up a server at each of my locations, but that works out to my benefit because each building uses the same base, but this lets me tweak the settings to better fit that novell context.

also, from the article, you can test with this
[CODE]env X=“() { :;} ; echo busted” /bin/sh -c “echo completed”
env X=“() { :;} ; echo busted” which bash -c “echo completed”[/CODE]
or
[CODE]wget -U “() { test;};/usr/bin/touch /tmp/VULNERABLE” myserver/cgi-bin/test[/CODE]

[quote=“Rohn Gordon, post: 37516, member: 26505”]It hung at 99.82%. I will upload the file again.

Rohn[/quote]

[url=“/_imported_xf_attachments/1/1408_errorlog.txt?:”]errorlog.txt[/url]

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.