I don’t know what is causing the slowness between vm and fog imaging, but that’s what I see as well. I’ll see it start out, not fast, but not slow, to almost a crawl. I, too, only have vm’s that I can use to test so I’m much in the same boat, though when I deployed my wife’s laptop, it was not slow at all. Imaging was around 2.5 ~ 3.5 GiB Min on upload, and deploy was close to 4.0 and 5.0 GiB. I have gig switches at the house.

[quote=“ID10Tea, post: 3548, member: 1040”]I have the same problem when I try to open FOGImageReplicator I get an error. " The folder contents could not be displayed. You do not have the permissions necessary to view the contents of “FOGImageReplicator”"[/quote]
Where in the file should I put this information?
Thanks

no problem.

What I’d recommend for this, is to change the actual fog user password with:
[CODE]passwd fog[/CODE]

Make sure this password is then changed in the GUI under:
FOG Configuration (Other Info)->FOG Settings->FOG_TFTP_FTP_PASSWORD
[B]AND[/B]
Storage Management->All Storage Nodes->Click the node you’re having problems with->Management Password

That should fix it. At the very least, make sure the GUI FOG_TFTP_FTP_PASSWORD and Storage Node::Management Passwords are the same and correct for the fog user on the FOG server.

To FIX this problem, follow the steps:

access: [url]http://fogserver/fog/management/[/url]
*** FOG Configuration ***
*** FOG Settings *** in the menu on the left
-> Replace the FOG_TFTP_FTP_PASSWORD fields under FOG settings

Then open the file:
/var/www/fog/commons/config.php - check the values of: TFTP_FTP_PASSWORD and STORAGE_FTP_PASSWORD
These MUST match the password you set above, if not write them properly in here
Finally reload of the service
/etc/init.d/vsftpd reload

then will need change the user fog password, by shell: eg.
fogserver:/# passwd fog
enter the new password
re-enter the new password
done

Ok. so easy ! sorry for bothering.

Another possibility is that if you are using HP ProCurve switches, the Spanning Tree protocol could be causing the delays which will cause pxe to timeout. I am not sure why reverting to an older bios will help this, but maybe they simply have a longer timeout period.

TRY turning spanning tree OFF for the switch that the system you are wanting PXE boot is connected to and see if that helps. If it does, then this could be an option for when you need to reimage a room. It is probably best to ensure Spanning Tree is re-enabled when finished to ensure there is some protection from network loops.

Just to touch base, setting the Clone flag in deepfreze while imaging did NOT fix the issue.

I also want to clarify that it is NOT a FOG issue.

Faronics is aware of the issues with the thaw spaces and the beta test team is working on resolving the issue.

I hate to tell you this, but I had to blowout my fog server and start over. Also, any images I created during the reign of 12.04 had to be removed as well. The recovery wasn’t that bad since I backup my SQL database, tftpboot folder, and images folder manually. Until a new version of FOG comes out, I’m staying at 10.04.

Was able to fix the udpcast glitch, using Timeloard83’s post. However now i cannot access the web interface, it redirects me to “[url]http://192.168.137.5/fog/commons/schemaupdater/index.php?redir=1[/url]”

[quote=“Kylejb007, post: 4521, member: 1442”]Chad and Raff,

That Did it!!! The intial results have been really impressive. Today we imaged our high School (Classrooms), which is approx. 80 machines… Normally we use to use Novell Zenworks to image them and it would take practically 1 whole day to image (at least 4-6 hours) and we would come in the next day and join them to the domain. Well im pleased to say that we started this morning at 9am, and completed the last computer (we dont have the fog service setup yet) we joined the last computer to the domain at 3:30PM. All of the machines loaded up fine with no Kernel downloading slow, and the Storage Node happily pumped images out to 10 machines at a time with everyone taking roughly 25-30 minutes to complete each. We even had to re-queue a couple computers due to Sysprep failing to process the unattend file, I assume this happens due to a network glitch pushing it to it or hardware glitch on the end station, usually a second image to it and it works rarely have I had to do it a thrid time, I end up switching patch cords and that fixes it.

Do I dare increase the amount of machines imaging at one time or I do have another decomissioned G5 I could use if I wanted… This is our largest building so the others shouldnt have any issues at all with time, I just figured for planning in the future to do 20 at a time would speed things up tremendously.

Definitly thanks for the advice, best product around![/quote]

Same experience here. We use ZENWorks for other functions, but dropped it for imaging purposes as soon as we found FOG!

Update - Yeah creating a brand new image from scratch from a new client seems to have fixed it.

See the following

[url]http://fogproject.org/forum/threads/tftp-problems.6442/[/url]

Hello Matt, I was wondering if you solved this. I’m stuck at the same point. We have over a 140 3330’s that are awaiting to be imaged.

[CODE]mysql -u root -h <hostname> fog[/CODE]
If you have a root password for mysql:
[CODE]mysql -u root -pPASSWORD -h <hostname> fog[/CODE]

[quote=“Musoni, post: 15873, member: 14999”]I too am having the same issues with the carbons. Have you had any luck moving forward? What corrected the locked driver issue?[/quote] Yes, we had some carbons with a bad motherboard (sorry I’m not sure exactly what was bad about the motherboard). We also had a some board USB network adapters - this was very frustrating - but we finally got the carbons out the door. If I were to do this again I would order a couple extra USB network adapters.

Glad I could be of assistance.