my suggestion, install phpmyadmin

some people have reported issues with the Optiplex 760 and gotten them to work using the Official Kernel 3.0.1

Tom,

You are awesome. Worked like a charm. Feel free to move this to the Linux Problems forum if you feel appropriate. I couldn’t decide between the two.

Magnus

I ran into a lot of the problems. Since it’s only an imaging server I literally opened up TCP/UPD 0:65535 ports and disabled Selinux. Everything works great now.

Use my tutorial to create an NTFS partition on the disk and try to push your image again.

[url]http://fogproject.org/forum/threads/quick-format-to-ntfs-with-fog-for-noobs.10349/[/url]

when i try to build udpcast manualy i get the following error’s

root@fog:/root/udpcast-20120424# ./configure
checking for gcc… gcc
checking whether the C compiler works… yes
checking for C compiler default output file name… a.out
checking for suffix of executables…
checking whether we are cross compiling… configure: error: in /root/udpcast-20120424': configure: error: cannot run C compiled programs. If you meant to cross compile, use –host’.
See `config.log’ for more details.

[quote=“Flavalf, post: 30776, member: 24625”]Thank you Jaymes for your answer, I see there is plenty of messages claiming the team’s help on the forum and it’s not the best part of the job to answer and debug users … but it’s the price of fame.;)

I have to say, my point was not to blame FOG, I never thought the cause was the program.
You know, I’m just a teacher who is in charge ( with small time … ) of the network of my college ( nearly 400 Pcs ), and I just want with my poor knowledges to learn how it works and how it can works better !
For sure, using FOG is already a great gain of time and headache for me and I thank you guys again.

So, I will investigate my network as you told me and give feedback as i can.[/quote]

I wasn’t trying to say you were claiming a bug per say, but then it could be! We change and break things often! So run some of these test on an isolated network and see if that helps to increase your imaging speeds. If not we can work from there!

Thanks for being understanding, and good luck!

Ok, No Issues bro. I will try with different possible ways to fix this and let you know. Thanks for your support.

I have something to add to this. Have been using .32 without issues. Recently received a batch of HP z230 workstations. Updated to the newest fog kernel and had no issue uploading a custom image with the 32bit win 7 installed on it. But when I attempt to upload a custom image (that I created from the install dvd) with 64bit Win 7 installed, I get the error. So it seemed like something with 64bit win. Wiping the partitions, and clearing mbr doesn’t seem to help.

Three observations here…

The original “untouched” 64bit hp load can be imaged with no issues, although it looks like it may take 8 hours to do so If I pull the original hp hard drive that came with the machine, and replace it with a 1TB Western Digital (Blue) drive…off of my shelf…things work perfectly. No problem uploading a win7, 64 bit imge. I checked the original hp load, and it is using the gpt partition. Sectors are also 512 bytes.

Like others, I am in a production environment, and was hoping to hold off on updating fog server until after summer 2014.

Anyone else experience this? Any ideas?
tia

-Rick

try fog configuration -> fog settings -> fog boot settings
try messing with the fog_boot_exit_type … see which one works best for you.

Hmmm I have been making a lot of changes. I created a “Production” field in MySQL so that it doesn’t list non production images. I guess I need to go look at the original files. Thanks Tom!

OK that is stupid simple I was over complicating it again.

Which version of FOG did you upgrade from?

Did you make sure to update Option 67 to reflect the new bootfile that FOG 1.1.1 uses? If not, update your settings at the DHCP server to point to the undionly.kpxe file instead of pxelinux.0 like you were instructed to do during installation.

So I solved the problem, and thought I’d let everyone know what it was since I’ve been on here for a couple of days now banging my head against a wall.

As it turns out, an ambitious young would-be network technician decided to go ahead and change what switch my office is on in the MDF down the hall. That switch hasn’t been used in forever since it was so unreliable. I can’t even ssh in to it. I put my office back in the appropriate switch and everything works just like it ought to.

As far as I can tell this has been my issue since square one, and I just wanted to come thank everyone for the help and input along the way to this Mad Hatter’s Tea Party of a solution (chaaaaaaange places!).

Thanks again!

This is a typical problem when uploading to FOG due to compression settings and hardware, If you want to see a slow upload, build your images in VMware and push them up.

If you would like faster upload speeds, adjust the settings in the web GUI. Personally, I upload mulitple images and I prefer if they don’t take up a mound of space. I will allow a slow upload to keep my blazing fast download. I only upload a few times a year, I download almost constantly.

Similar post from same user…
[url]http://fogproject.org/forum/threads/fog-1-1-1-with-proxydhcp-default-ipxe-connection-timed-out.10829/[/url]

Sorry, I had left out that part, its an isolated network, so the only machines on it are those waiting to receive the image, and the FOG server.
It is the same setup as our other FOG server, completely isolated.
We had tried it on a different network initially and found this problem, so we isolated that network but FOG didn’t like the switch, so we changed over to our switch which we know works.
Then came back to our Head Office and tested it again, and we had the same issues.

We do think it could be an issue with the network, but are not sure how to resolve this. The laptop has a Gigabit port, and its connecting to a Gigabit switch.
We are using a stock version of Ubuntu desktop 10.4.4, with a stock install of FOG. The only configuration I have made on the server was to set static IP for the lan connection.
Is there anyway to test it against the network? As proof of the network being the issue?

However the extra steps mentioned here [url]http://fogproject.org/forum/threads/database-update-failed-1-1-0-to-1-1-1.10809/#post-30630[/url] did fix the issue. Seems like /var/www/fog/lib/fog/Config.class.php had a randomly generated password in it for the database the same as /opt/fog/.fogsettings.

Okay,

I found and corrected this bug. It is up in svn at 1862. Thanks for reporting.