[quote=“Axel, post: 12528, member: 686”]So I spent 10+ hours today trying to get this to work. I’ve followed multiple tutorials on using an external NFS share and my results are not good. After I configure the NFS share in FOG the web GUI says unable to connect on the front page where usually the space free/used is displayed. I’ve created the NFS share, remade /images mounted my NFS share in FOG on /images, created the .mntcheck and then the /dev folder with .mntcheck inside it. I’ve made sure to chmod -R fog:root /images. When uploading an image once the process gets to send method-nfs I get an error of mount: 192.168.62.125:mnt/nfsdata/dev/ failed, reason given by server : Permission denied
mount: mounting 192.168.62.125:/mnt/nfsdata/dev/ on /images failed bad file descriptor. I’ve even tried following posts on here where people had similar issues and i’ve had no luck. The fog server is a vm running in Proxmox with bridged networking. Any ideas?[/quote]

hey Axel

not sure if you resolved your issue, post is too long… didn’t read all of it…

however, I have noticed two things that may be causing your issue…

the first… you used chmod -R fog:root /images… when it should be chown -R fog:root /images (perhaps you meant to type that…)
the second, in your screen shots for the storage node section, the password field should resemble the password in plain text, not the encrypted type… try changing to your normal password, save and try that…

I always issue (right or wrong) the following commands on the /images folder…
chmod -R 777 /images
chown -R fog:root /images

but that’s just me…

Good, glad to be of help. I’ve implemented this as a feature into FOG 0.33b as well.

In FOG 0.32 it’s call is MYSQL_DATABASE where in FOG 0.33 it’s called DATABASE_NAME.

That’s normal.

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]