Removed .fogsettings and re-ran the setup script. Worked.

Thank you!

Andrew: Great find! I decided to try deploying then uploading the image, but I ran into some trouble. I let it run overnight because it was a large image, and when I came back into the office this morning, I was greeted with this screen:
[IMG]http://i.imgur.com/5lXYdull.jpg[/IMG]

No idea what this is, and you can see my attempt to Ctrl-C whatever is happening. The image didn’t end up uploading to FOG, either.

I went into the image properties and changed the image manager from PartImage to PartClone and am attempting to upload again. Maybe that’s what I needed to do?

edit: Nope, still getting the same problem.

edit the second: Found out the issue. The user account I had set in Storage Management did not have write permission to the image’s folder. I changed this to an account that did, and now all is peachy.

Thanks to everyone for their help and input!

Had the exact same problem. In my case the second uploaded file was bigger than the size set in /etc/php5/apache2/php.ini.

Specifically i had missed to change upload_max_filesize. Check your post_max_size and memory_limit in the above mentioned file as well.

Cheers! 😄

[quote=“Steven B, post: 37172, member: 24174”]I’m running fog and imaging a bunch of HP t820 with 128G SSD drives. They are linux based so the up / down is raw not resizable. I can do on one system in about 15 minutes averaging 7G on the push down. I was able to push 16 systems last week and averaged 4.6G This week the 16 systems thru put drops to about 1G to all.
Similar thru put to traditional window systems but because nfts performance is better. Monitoring the eth0 now to see. I may have issues with the universities network getting udp traffic to and from other ips.[/quote]
No the server is not SSD. The ubuntu image has four VMs with networking. I have 3 SSD drives in the thin client. 16G windows 7 for horizon view 80G with dual boot windows 8 server 2008.

I don’t think your NIC is the issue. I use the same model of NIC in my fogserver and I do not have issues.

It is very odd the issue you are facing, please check on our discussion in your inbox.

The interface can be changed, but i believe the interface for the relevant nodes are in a text box. Does this sound correct?

If you change the interface it’s referring to, it’s likely you’ll have to restart the FOGMulticastManager service on the changed interface nodes as the php service file that sleeps and checks in as already been loaded under the other setup.

Maybe this will help?

hmmm. seemed to have worked. I moved the files over manually to /images but didnt like the image. I went and uploaded a new image. Worked then. But I had already made the dir in /images.

Ok, the solution is: do not[I] exit 0[/I] at the end of postdownloadscripts…

ok went back to 1.2.0 and works fine

[quote=“Tom Elliott, post: 36791, member: 7271”]Is next-server the IP of your FOG server and is filename undionly.kpxe?[/quote]
it was the “undionly.kpxe” file which was replaced by “prelinux.0.” What I do not understand is that it worked for a long time. Anyway Thanks

i have no idea what went wrong, but try running the installer again. perhaps something didn’t install correctly the first time

Sorry, I have been trying to find out. How would I access the log to copy the info? Is this done over ftp, or in the terminal.

Excellent! That is where the errant IP address was residing. I hadn’t thought to look there, thanks!

After that, the job still failed even after rebooting the server. Deleting the image and then re-creating it and restarting the task allowed this to run as it was intended. Thanks!

If only all the problems I encountered were so easily resolved. Thanks again.

Unless these are different from the ones we have, you can switch them to legacy boot. The BIOS/EFI/firmware is almost identical to that of Dell’s laptops and desktops, and it has all the same options, including legacy boot options to completely disable Secure Boot and UEFI.

Ooo, is there a handy link on how to do that?

Maybe you should change the memory_limit parameter in the php.ini.

This is a known issue with vbox. Use ipxe.pxe and all should work.