Holy snog. I was an archaic 10/100 switch that was holding this whole thing up. Switched it out with gigabit and its fine. This does concern me a little bit because we have some off-site machines I was hoping to FOG at a later date. That is a bridge I’ll cross when I come to it.

Actually it’s good you say that, I am currently doing exactly what you suggested, because I reverted back to my initial FOG server installation with a single 140 drive and the problem still persists. I am fairly certain this is nothing to do with FOG and something to do with a network change. I’m testing on multiple computers now to see if it could be either a bad NIC in my test PC, or maybe the networking level at which the imaged computer resides.

The bad part is I just got 15 new machines delivered that are supposed to get deployed next week.

Update: So I completed my install. Now FOG is installed on a Raid 5 will four disks. All 140gb SAS drives. Giving me 410ishGB of effective space. After restoring all my images and such, it still is taking 8-12 hours per image to deploy or upload.

I am just going to assume FOG and my cpu/controller combo do not get along and go back to a single disk solution.

If anyone has any ideas, I’ll keep these disks around so I can swap back to this config and test.

Please let me know if any more detailed information would be helpful.

Just a heads-up, and I know this guide is a little old, but there was a small correction I had to make to get the tutorial to work for me.
This command here:
[CODE]sed -i ‘s/udpcastsrc=“…/packages/udpcast-20071228.tar.gz”/udpcastsrc=“…/packages/udpcast-20120424.tar.gz”/’
…/lib/common/config.sh (enter)[/CODE]
Doesn’t seem to work. But all it took was editing the …/lib/common/config.sh file.

For newer users, that looks like this:
[CODE]sudo pico …/lib/common/config.sh
#Find the udpcastsrc line, and change …/packages/udpcast-20071228.tar.gz to
…/packages/udpcast-20120424.tar.gz[/CODE]

Hope this helps someone.

Currently I have two separate logical partitions. The OS and FOG are installed on a single SAS drive. The images are stored on a separate Raid 5 containing three 72gb SAS drives.

Anyway, my solution now is backing up my system, and re installing Linux fresh. This time I am going with four 146gb SAS in a RAID 5 from the start. We’ll see if it was the drives, or the multiple logical partitions that caused the issue. I was outgrowing that space anyway.

Great tool guys, I’ll update when I see how it runs with this new environment.

Update: After waiting 18 hours the image finally completed, I am now pulling a different, previously working image back down to the device and it is estimating 5 hours to complete. I should also note that the pigz timeout error is not present in this deployment, only in the previous upload task.

What happened to my 12-minute imaging? What could this new array of disks have done that would kill performance this immensely?

Thanks for any input.

Hey Folks,

I’ve had a Ubuntu 12.04LTS Fog Server running for a few weeks now, and I have a nice collection of XP and 7 images for different deployments we use. I am currently uploading my second custom image for a tablet some of our doctors use. They are HP Elitebook 2760p Tablets running Windows 7. My first image was this system running Office 2007, the current image is running Office 2013.

Now to the issue: This most recent image upload is failing miserably. I am getting this message every few minutes on the client. It looks like it is trying to overlay the message on top of the progress screen.
[CODE]task pigz:307 blocked for more than 120 seconds.
“echo 0 > /proc/sys/kernel/hung_task_timeout_secs” disables this message[/CODE]

In the web task management, I still see the queued task, but it is currently 1h out of 16h complete (5%) and it has uploaded 1.33GiB of 20.56GiB (0.33 MiB/sec)

The most recent change I’ve made to the server is adding disks, however this is not the first image I have uploaded on the new disks. I’ve included a screenshot of my System Monitor/File Systems tab, as you can see I have plenty of space.

[ATTACH=full]625[/ATTACH]

[url=“/_imported_xf_attachments/0/625_diskspace.jpg?:”]diskspace.jpg[/url]