@Wayne-Workman Actually I think I figured out another way.

Understand I don’t have WDS setup and we build our reference images in a vm via an litetouch iso image. So the only pxe booting we do is into FOG. I’m kind of winging it here, but I know what needs to be done. I have found a reference to allow me to boot ISO images via tftp (I did this a while ago for diskless booting linux and a few other iso based utilities). If fog would use the traditional pxelinux menu I know how to get it done. Right now I’m trying understand how I can add these options to the fog pxe menu.

kernel memdisk
append iso initrd=litetouchpe_x64.iso raw

Once that is done, I think all I need to do is copy the iso image to /tftpboot directory on the fog server. Again this is a bit of guessing that it should work. The target computers will have 4GB of ram so there is enough room for the iso image to exist in memory as well as the WinPE environment (in theory)

I kind of have a similar setup as you, but not quite a chaotic.

Before I go too deep, I’m wondering if you have a separate subnet (vlan) away from your MDT environment you can use for testing? If have a subnet you could change the pxe boot settings just for that subnet to point to FOG. That way you would have a good test lab setup to ensure that everything deploys correctly before going live.

How I would go about this (be aware I have not needed to do it this way), is just as you stated to chain load MDT from FOG. Let the client pxe boot into the FOG menu and then add FOG menu item to chain load into MDT.

In our environment we use MDT to build the reference image, sysprep the image, and then capture the image with FOG for deployment. We do not deploy using MDT because of the volume of systems we manage.

If I can figure out how to chain load MDT from FOG I have the kit in place to test this concept.

We should first start out with what version of FOG are you using? Are you using the 1.2.0 release or a SVN trunk version. If it is a SVN trunk version what is the version number?

As for is this a problem, I’ll have to defer to the developers. Just off the top of my head, I would have to say yes this should be concerning.

1. Since they are checking for it, there may have been a problem in the past with this being set to 0
2. The function of an auto increment column is to generate a sequential number, typically starting at 1.

But, only the @Developers know if it WILL BE a problem moving forward.

@KKTwenty101 Interesting, I also do a minimal install for Cento 6 and 7 and fog installs no problem. As long as you remember to disable iptables and selinux. I know that FOG installs mysql during the initial install because the password for mysql root user is blank. If you are doing something outside of the normal FOG install then something is broken either with the system or the FOG installer.

My FOG server is behind a proxy server so I have to create a few envron variables and update wgetrc and subversion with the proxy server settings, but the basic workflow is

1. Install centos 6.5
2. yum upgrade -y
3. yum install subversion wget -y
4. reboot
5. disable selinux and iptables
6. reboot
7. mkdir /opt/fog_trunk
8. cd to the fog_trunk and use subversion to copy the current build
9. cd /opt/fog_trunk/bin
10. ./install.sh

That’s all I’ve done and it works correctly right out of the box, so to speak.

@Rusty It would be interesting to know if this computer’s bios is up to date. From Wayne’s suggestion, it would be great to know what SVN worked so then we could go back to the devs and say what’s different between then and now, why did this stop working? I’m still leaning towards the hardware on this issue though.

@Rusty said:

Updating to SVN 4367 didn’t help with this Dell Inspiron I have here. The second laptop I have here boots into FOG menu everytime.

Not to fork this thread, but just so I can get this clear in my head.

You have two computers that are exactly alike. They are the same models, with the same bios release and the same bios settings. But one boots to the fog menu and the other hangs at the init devices?

Have you tried to reset the bios back to defaults on the one that doesn’t work, save and reboot, then make any changes necessary for your image (uefi, legacy, roms, etc.) save then pxe boot. If it still hangs. Power it off, remove the battery and charging cable. Then power everything back up. If it still hangs then I might consider the mobo has issues. There may be a way (kernel parameter) that the developers can set to tell exactly where its hanging.

@Rusty Some systems will try to do a two way match between conical name->IP address -> conical name. This is a standard function of DNS. I’m kind of surprised that this issue (not having a reverse lookup zone) hasn’t been a problem.

Not to send you down a rabbit hole here, but I take it you don’t have a reverse lookup zone created for your DNS server. Because looking at the capture its looking for the 10.0.0.51 address but the reply from DNS is name not found. Can I guess that 10.0.0.51 is your FOG server? Outside of the scope of this project you should ensure you have a reverse lookup zone created in DNS.

Here is a how to for 2012. http://www.tomshardware.com/faq/id-1954333/create-reverse-primary-dns-zone-windows-server-2012.html

yes after you do the svn up then cd to the bin folder and run setup again.

A PRT record is a reverse lookup for DNS. Basically it asks DNS for this IP address what is its conical host name.

While I haven’t read this entire thread, for DHCP its best for option 66 to be an IP address and not a conical host name. Some PXE clients are just not that smart enough to know how to look up a name for option 66, so set it to the IP address of the FOG server.

Also I know they have been working on the boot image (in the last 3-4 days) where it was getting stuck at the initialing devices. You may want to try to update to the latest SVN. It sounds like you are almost there.

OK just to restate what I think you said, all of your fog servers are running under ubuntu 14.04 and the version of FOG is 1.2.0 base image. You have not applied any SVN trunk (a.k.a 1.3 beta) images on top of the 1.2.0 base image.

Now here is where I’m a bit fuzzy. Are you trying to deploy to a HP microserver or is the destination of the captured image the HP microserver? What I’m trying to dig at is of you are on the 1.2.0 base image and you have not updated the kernels since the base image was released (which is separate than applying a SVN upgrade), that kernels from 1.2.0 my not support current hardware.

While I think this is a kernel/root filesystem issue lets start with the basics.

What version of FOG are you using? Are you using 1.2.0 or a SVN trunk (beta) version?
What OS is FOG running under?
What is the target hardware you are trying to clone (make and manufacturer)

@Toby777

There are a few things that you might do to clear this up (proxy server related). I run FOG on centos 6.7 behind a proxy server and this is what I needed to do.

In the bashrc file I placed the following commands.

export http_proxy=http://192.168.1.10:3128
export https_proxy=http://192.168.1.10:3128
export ftp_proxy=http://192.168.1.10:3128
export no_proxy=“192.168.1.88”

In your wgetrc you can have the proxy settings too. The key is the no_proxy variable. That needs to be set to the IP address of the FOG server. Once these are set log out and back in. These new env variables will be set. From there FOG will install and backup correctly. If you look at the code for the backup, the script uses wget to pull the backup image. Well, wget isn’t that smart. Its trying to contact the proxy server instead of just connecting locally. The no_proxy statement tells wget to not proxy any requests for the FOG server.

As for the second question, that to find out if this was a new install that never worked, or a working install that broke after the upgrade.

First, what is the host OS that FOG is running under?
Was this system running under the 1.2.0 prior to you upgrading to the latest SVN?

I think we need to divide your issue into two parts

1. FOG not installing correctly
2. The image not deploying correctly (which may be a symptom of #1)

I guess I have two questions here

1. Is this FOG server behind a proxy server or does it have direct internet access. I have seen if FOG is behind a proxy server wget gets confused when it tries to backup the database. There is a fix for this.
2. Has this ever worked? Or did the system work then you upgraded to the latest svn trunk and it broke? Knowing this will help to know if this was a botched install or something went sideways with the upgrade.

Actually we would like to see you generate that error message again, then view the apache error log in /var/log/httpd/error_log. The last few lines should indicate the current error. The access_log should only show use details when things go right.

@Tom-Elliott

FWIW: I have seen if you stop the fog image replicator while a transfer is underway the lftp process will continue. If you stop and restart the fog image replicator multiple times, you might end up with 3 or more lftp processes running at the same time each with their own bandwidth limitation and ignorant of the other running processes.

If you really want to go there, using the current svn trunk (if things go sideways, just rerun the fog installer to correct the files. No harm done then)

Edit this file:
/var/www/html/fog/lib/service/FOGService.class.php

Search for the first occurrence of the word fragment: limit.

You should see something like this:

$limitsend = $this->byteconvert($StorageNodeToSend->get('bandwidth'));
if ($limitmain > 0) $limitset = "set net:limit-total-rate 0:$limitmain;";
    if ($limitsend > 0) $limitset .= "set net:limit-rate 0:$limitsend;";
        $limit[] = $limitset;
    }
}
unset($StorageNodeToSend);
$this->outall(_(' * Starting Sync Actions'));
foreach ((array)$nodename AS $i => &$name) {
    $process[$name] = popen("lftp -e 'set ftp:list-options -a;set net:max-retries 10;set net:timeout 30; ".$limit[$i]." mirror -c -R --ignore-time ".$includeFile[$i]." -vvv --exclude 'dev/' --exclude 'ssl/' --exclude 'CA/' --delete-first ".$myItem[$i].' '.$remItem[$i]."; exit' -u ".$username[$i].','.$password[$i].' '.$ip[$i]." 2>&1","r");

Insert the following line after: $this->outall(_(’ * Starting Sync Actions’));

$this->outall(_(' * Speed limiter settings: $limitset'));

That should make it like this:

unset($StorageNodeToSend);
$this->outall(_(' * Starting Sync Actions'));
$this->outall(_(' * Speed limiter settings: $limitset'));
foreach ((array)$nodename AS $i => &$name) {

Stop and restart the FOGImageReplicator. You may need to delete a file on the storage node for it to see a change. When the replication runs it should output the speed limits to /opt/fog/log/FOGImageReplicator

I’d do this in my test environment but its only partially rebuilt.

First I’m not a programmer. But I know the dot ( . ) string concatenation and .= may be short hand for “string = string + newstring”. Then that might make the statement accurate.

Right now I can’t think of a way to capture the environment that lftp is running in to see what is actually being set. It may be possible to hack the FOGImageReplicator to insert a few extra log statements to see what is actually being set by logging the variables.

@Jbob

Actually I share the same concerns about disabling selinux and the firewall. But this seems to be the standard practice for installing FOG so I didn’t want to push a different agenda. I also consider that FOG appears to be targeting the smaller SMB realm from a security stance and most have FOG installed inside a properly protected network so that does mitigate some of the risks.

Just thinking out loud, if we have a list of all services used for FOG then constructing firwall rules shouldn’t be difficult at all. The application of the rules may be difficult since each linux distro handles the iptables rules a bit differently.

The selinux part will be a bit harder since FOG is writing to files all over the place. We would have to get the selinux tagging just right (we could get there if we used the permissive setting then scanned the log for the required rights. Its been a while since I did that type of activity). But from a security standpoint I like where you are going with this.