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.

Wow site giving me a fit this morning, couldnt reply for the last 20 mins.

The version is the Trunk in the first post.

Hre is the output:

root@CINDSV10011:/home/ladmin# ls -lR /images /images: total 12 drwxrwxrwx 2 root root 4096 Nov 5 15:22 dev drwxrwxrwx 2 root root 4096 Nov 4 08:37 postdownloadscripts drwxrwxrwx 2 root root 4096 Nov 5 15:22 Win7VL /images/dev: total 0 /images/postdownloadscripts: total 4 -rwxrwxrwx 1 root root 233 Nov 4 08:37 fog.postdownload /images/Win7VL: total 15459848 -rwxrwxrwx 1 root root 2 Nov 5 14:47 d1.fixed_size_partitions -rwxrwxrwx 1 root root 1048576 Nov 5 14:47 d1.mbr -rwxrwxrwx 1 root root 184 Nov 5 09:50 d1.minimum.partitions -rwxrwxrwx 1 root root 30 Nov 5 14:47 d1.original.fstypes -rwxrwxrwx 1 root root 0 Nov 5 14:47 d1.original.swapuuids -rwxrwxrwx 1 root root 8886666 Nov 5 14:50 d1p1.img -rwxrwxrwx 1 root root 15820924479 Nov 5 15:22 d1p2.img -rwxrwxrwx 1 root root 190 Nov 5 14:47 d1.partitions```

Ah Okay. I thought I was missing something. I take care of multiple locations so walking a user through getting to the network boot screen is easier than traveling to work on it there or pick it up if I suspect something. Thanks for the fast reply Tom!

Thx for this. The plugin is exactly what i need.

The site deployment server is only a storage node with own pxe\tftp and mysql-client. It uses the MySQL DB of the Master Server.

Well, that is exactly what resizeable images are made for. Either that or for deploying to larger disks (expand partitions automatically).

I just read your earlier post where we pointed you to use resizeable images. So I guess you want this with your new machine as well?!

Could you please open the file d1.original.partitions in both images on the FOG server and post the contents here. Most likely the partition scheme is causing an issue here.

Did you see any errors while uploading that Win10 client? Did you see the blue partclone window? Probably best to start another debug upload task (Host -> Basic Tasks -> Debug Upload) and take pictures while you go.