@Tom-Elliott Have re-installed everything from scratch, it is now working, settings saving as expected 🙂
Thankyou all for your help.

Tony

Bumping this thread, today at work I updated to cloud 5293 svn 4323 and UEFI network booting is WORKING for the Optiplex 9020! 🙂

ALSO, Much progress has been made in the way of GPT and Windows 8 imaging using resizable and non-resizable image types. Read more about it here: https://wiki.fogproject.org/wiki/index.php/Windows_8_UEFI_Imaging_Tips

@Sebastian-Roth to be honest, it was an attempt at comminizing the files so they were very similar between efi and non efi. It was not to hurt anything, but a way to make things more similar.

It’s this separation that you see two ipxescript files as well.

@Wayne-Workman won’t matter.

They are both 40GB virtual disks, with 20-25 used. I’m going to let it run overnight and if it hasn’t finished by morning, I’ll look into the defrag. Thanks @Wayne-Workman !!!

EDIT

One just went through, so this should be resolved.

Thanks for the help everyone, it seems up and working now, but I can’t say I know why. I didn’t get to change the MaxRequestWorkers before it came up.

I did notice in /var I have a fog and a wwwfog directory which I never remember seeing.

@Sebastian-Roth said:

Thanks for posting this. Please check your apache DocumentRoot setting: grep DocumentRoot /etc/apache2/*/*

Seams a bit like thinks got mixed up. See the timestamps of /var/www/html/fog… It’s Jul 16. From the error messages we saw in the apache error log this is the one being currently used and probably what you will see when grepping for DocumentRoot. But the newest date (Nov 4) is /var/www/fog. And I guess this directory is from a newer trunk install but is not being used.

If I remember right Ubuntu changed from /var/www to /var/www/html not that long ago. Tom changed the installer to reflect this and maybe it ran into some condition on your system to also change this at some point.

My advice:

Backup all the stuff in /var/www by moving it (mv /var/www /var/www.bak && mkdir /var/www && chown www-data:www-data /var/www) Update FOG to latest trunk (cd path/to/trunk && svn up) Comment the wget command in the installer script as done before Run the installer Check DocumentRoot setting (see above) and compare with what you see in /var/www

I really hope this will get us one step further. I am very sorry that it took us so long to find out about those different fog directories in /var/www…

This worked for me! I had very similar issues!

Thanks!!

@Julianh If you’re running SVN builds, I’d actually recommend starting by deleting the backups.

I generate a backup of your GUI layout, now, for Every version of FOG you’re attempting to install.

This can eat up quite a bit of space as one can imagine.

I’d recommend (before allowing resources to eat up the 5% for system files and such) clean up the backup location.

Most layouts have a separate layout for /, /home, /var, and maybe others, but some installs use the / only setup.

Check in the /home (unless you changed the backup path for the installer) and look at how many folders of .BACKUP you have.

My guess is this is what’s eating up your space.

While, yes the backups do eat space and it is quite intentional, the backups may not be needed, I find it safer to have and not need, than need and not have. I use the backup folder/file now to ensure any “extra” data you store in the gui folder (for say ISO’s or alternative kernel files etc…).

@Sebastian-Roth Sorry I assumed login == working kit.

I decided this AM to break down my POC setup and rebuild it. Yesterday I attempted to learn objected oriented php programming to add a function to FOG and promptly whacked my install. I’m in the process of rebuilding it with a consistent build across all nodes. It appears that Tom was able to fix the LDAP part. I will test that once I get the environment resetup. Thank you for your assistance.

@george1421 said:

ou have done all of that, but are getting an apache error in

i will do so, in just a few

I used this, and it solved my issue…not as many steps nor as dangerous it seemed.

http://linuxmanpages.net/manpages/fedora20/man1/avahi-browse-domains.1.html

I’m confused. There is no issue in the db, but the data is stored in the db as base64 encoded, though I plan to move this to aes encrypted just to ensure somebody can’t just steal your data.

@Sebastian-Roth for help the three exit types were sanboot, grub, and exit. Sanboot is ipxe’s way of getting first hard drive which appears at bios memory address of 0x80. It’s not always a workable method, so the grub exit type was brought in which can find or use an HDD. In 1.2.0 it always assumes the first disk is hd0. Exit does what it sounds like, it exits back to the bios for handling what to boot next.

@gooroox Did you get this issue solved?

Marking this solved here as the issue seams clear.

@bennewell Still it would be great to hear if you found what is causing it and can write a short summery for other users to know.

@ZINGARO1972 Please let us know more about your environment and we might be able to help.

Thanks Tom. I appreciate your help and this forum has always been awesome.

To me this means that even the MBR was not dumped to the disk. Otherwise you should at least see some kind of partitioning on the client that tried to download an image.

Anyhow. Marking this solved as we probably won’t bother about going into the details any further. Thanks a lot for letting us know.

@StahnAileron I’ve added a ton of functionality (I think) to the installer.

If even works with typical switches and output to assist in knowing more.

For example:

./installfog.sh -? will print potential usage options.

As we are not able to see what else is in your network it is very hard to guess what’s going on. But I can offer to look at a packet dump and hopefully we can find out what’s causing the issue.

Please turn off all your clients for that. Install tcpdump on your FOG server and start it up as root tcpdump -i eth0 -w bootup.pcap (change eth0 if you use a different network interface on this server). Leave tcpdump sitting there and start up one of your clients. After it “failed” you can stop tcpdmp with Ctrl+c and upload the PCAP file to the forum.

Please also take a picture or even better video of the booting client so we can see what you see as well.

This way we might be able to help. Everything else is just blind guessing.