Here is the process to apply the patch:

1. Open a linux command prompt on your FOG server.
2. Key in the following command:
   sudo wget -O /var/www/fog/lib/fog/plugin.class.php https://raw.githubusercontent.com/FOGProject/fogproject/6717f382177e714c1bd22eb11627133cfd4e0ebe/packages/web/lib/fog/plugin.class.php
3. Remove the plugin
4. Reinstall the plugin
5. Add in your plugin settings and save

Just for something abstract, is 10.2.0.87 your FOG master node server?

Oh, what the hell is that?? image name =v2Office365-SymFix/18 Why is that forward slash ( / ) in the file name? What you have done is allowed in FOG, but I don’t think that is what you really intended here. By putting the forward slash in there FOG will look for a directory called v2Office365-SymFix and place the image in a image directory named 18 This allows for grouping of like Images. If this isn’t what you intended, replace the forward slash with something other than a special character.

Here you go.

1. Login to the database with this command
   mysql -u root fog
2. Use this command to list all of your images. You will need the exact image name for the next command.
   select imageID,imageName,imageProtect from images;
3. To change the setting run this command. imageProtect=0 to turn it off imageProtect=1 to enable, <exact_imageName> is taken from the select statment.
   update images set imageProtect=0 where imageName="<exact_imageName>";

OK changing your fog server IP address is never a good thing after FOG is installed. But I think we can get you going again.

1. You need to update the IP address in the web ui, go to fog settings. I think its in the tftp section. The easiest is to expand all sections and then search for the old IP address. Once the fog settings are correct then off to the next step.
2. Go into the storage node definition for this fog server. Change the IP address listed there to your new IP address.
3. Now off to the linux command prompt on the fog server.
4. You need to edit the following configuration file. /opt/fog/.fogsettings (hint: its hidden). Replace the old IP address with the new IP address and save.
5. Last step, rerun the fog installer script (installfog.sh) to fix the remaining bits.
6. Reboot your fog server for good measure.

That should be it, you should be back in business.

Well I can see from the message, you are trying to boot a uefi system. What exactly do you have configured for dhcp option 67? If its undionly.kpxe then that is your issue. You need to send a uefi boot loader like ipxe.efi.

@sebastian-roth we had an extensive IM chat session. The OP found where the issue was and identified the need for snponly.efi for a specific hardware configuration. I had him start with the examples from the fog wiki and work from there. Where we left it was he was going to see if he could collect the system uuid to see if we could write a better dhcp filter to only send i386-efi/snponly.efi for that specific model and send ipxe.efi for the remainder of the arch 0007 hardware types.

Let me see if I understand what you want.

First let me say, the FOG server must have internet access to install fog. After fog is installed, then no internet access is required.

After the install, you want to run FOG on an isolated network. Sometimes we call this an isolated imaging network. FOG can work in this design. You must then provide on this isolated network a dhcp server. The dhcp server can be an external device or the FOG server running isc-dhcp service. With a dhcp server configured to send dhcp option 66 [boot-server] and dhcp option 67 [boot-file] the pxe booting client computers should find the fog server and connect you to the FOG iPXE boot menu.

Can you confirm that you have a dhcp server on your isolated network and it has its settings configured to instruct the client computer to connect to FOG?

Did you disable selinux or at least change the settings to permissive?

From a windows computer install the tftp client feature, then from a windows command prompt use the tftp client program to download undionly.kpxe from the fog server with tftp -i <fog_server_ip> GET undionly.kpxe . If you can get the file then tftp is setup correctly and we need to focus on the pxe booting process at the cause.

If you have unbuntu and things are working fine until one day out of the blue… You may want to review this document: https://forums.fogproject.org/topic/10006/ubuntu-is-fog-s-enemy

The title is a bit tong and cheek, but the help it provides is spot on

The primary issue you have is this. The fog client runs as SYSTEM on the target computers. SYSTEM is an account with local administration rights, but doesn’t have any domain level rights (needed to access off system resources). If you need to access off system resources you will need to provide that connection information in the batch file, which from a security stance is not always the best choice.

As an example here is a batch file that will run an installer from a CIFS (SMB) share.

@echo off
net use w: \\server01\share01 /user:domain\user01 p@ssW0rd
w:
cd installers
setup.exe /qn!
net use w: /delete

As you can see in the made up batch file you would use the net use command and then supply the credentials needed to connect to an external resource. By doing that then SYSTEM can reach outside of the target computer.

With that said, its much easier some times to just create a snapin pack (think zip file) to install applications so the installer won’t have to reach outside of the target computer to get all of the needed files. I understand that creating a snapin pack is not realistic in all cases (think of AutoDesk design suite and how big the installer files are > 35GB). In that case having a shared install directory is the only/best solution.

@wayne-workman

Hey Wayne:

There ARE specific use cases for broken bios/firmware. But even with the USB boot sticks you still need to have dhcp services on your network.

@kafluke said in How do I schedule FOG image replication for after hours?:

@george1421 thank you so much! These are even the exact times that I needed to set the job for! You da man! This can be marked resolved now.

That is why I get paid the big bucks… oh wait… never mind.

If you have ubuntu (likely based on the path of the error log file) AND FOG was working great yesterday and now its not AND you changed nothing, blame it on Ubuntu. Review this document and see if it fixes your issue: https://forums.fogproject.org/topic/10006/ubuntu-is-fog-s-enemy

OK lets see if we can get you going.

1. SU to root and then log into mysql using mysql -u root fog
2. Issue this mysql command to list out your storage nodes.
   select ngmID, ngmMemberName, ngmMaxClients from nfsGroupMembers;
3. You should see a results list this:

MariaDB [fog]> select ngmID, ngmMemberName, ngmMaxClients from nfsGroupMembers; +-------+-----------------+---------------+
| ngmID | ngmMemberName   | ngmMaxClients |
+-------+-----------------+---------------+
|     1 | ATL StorageNode |            10 |
+-------+-----------------+---------------+
1 row in set (0.00 sec)

4. Collect and record the ID value of storage node in question. In this case we’ll use 1
5. Update the following query with the proper values.
   update nfsGroupMembers set ngmMaxClients=1 where ngmID=1;
6. Confirm that the value was set using the previous query.
   select ngmID, ngmMemberName, ngmMaxClients from nfsGroupMembers;
7. If the number are now correct exit mysql
   exit
8. Done.

Is both the linux firewall disabled and selinux set to permissive on the fog server?

What is the output of this command executed on the fog server showmount -e 127.0.0.1

@fry_p well I have no proof of this but my intuition is telling me that php-fpm is probably running out of memory when you are unicasting to that many systems. So as an experiment I want you to do this .

1. We need to locate a file called www.conf in the etc directory. It should be in a directory that has php-fpm in the path. Use this command.
   find /etc -name www.conf
2. Edit that file down towards the bottom. You should see a section that has a few entries that start out with php_admin_value. I want you to add a new line with this:
   php_admin_value[memory_limit] = 256M The exact placement of the line doesn’t really matter but keep it in the admin value section.
3. Save and exit your text editor.
4. Restart pgp-fpm and apache (make sure you don’t have imaging running when you do this)

sudo systemctl restart php-fpm
sudo systemctl restart apache2

Now when you have time or your next be image push see if you run into issue again.

@tomierna That IS very strange, once the kernel is booted, you should not see any link transitions.

a bit from the far side: I have no basis for this vision, but I’m seeing something about tcp off loading and ethtool.

This will be digging in the weeds a bit with this one.

1. Set up a debug deploy (tick the check box for debug before you submit the deploy task on one of these 480s).
2. PXE boot the computer, after a few pages of text it should drop you to a linux command prompt on the target computer.
3. look through the /var/logs to see if there are any error messages related to the network adapter.
   [sidebar] If you give root a password with passwd. Give it a simple password like hello. Then get the IP address of the fos linux with ip addr show. From here you can use putty on a windows computer to connect to the FOS engine. Login as root and the password of hello. Now you can interface with the FOS engine using the comfort of your windows computer. It will also make it easier to copy and paste text into the FOS engine. [/sidebar]
4. After reviewing the logs and recording any thing suspicious continue on to the next step.
5. using my vision above lets use ethtool to shut off some advanced features of the intel nic.
   ethtool -K eth0 sg off tso off gro off
6. Now comes the time consuming bit, by entering fog at the linux command prompt you can single step through image deployment. You will need to press enter at each breakpoint. It will be interesting to see if turning all of the advanced features of the nic has any impact on image deployment.

We can do some other benchmarking from the FOS debug prompt, but lets see how this goes.

For these computers that have a raid 0 setup. What do you have defined as the primary disk in the host definition?

My bet is that your raid setup is built on the intel rapid store “fake raid” (i.e. hardware assisted software raid) setup, which appear as 3 independent hard drives and only look like a raid setup when the kernel is told to look at them as raid.

I have a tutorial on how to tell FOS that the disks are a raid setup and not individual disks here: https://forums.fogproject.org/topic/7882/capture-deploy-to-target-computers-using-intel-rapid-storage-onboard-raid

@imagingmaster21 Well I’m still suspecting that the linux user fog’s password as been reset/out of sync with what FOG’s configuration thinks it is. Your screen shot of the error is almost 100% proof. Also if you inspect /images/dev directory on the fog server you should see one or more directories in there that are named similar to mac addresses.

Please follow the steps here to resync the linux user fog’s password with the web ui: https://forums.fogproject.org/topic/11203/resyncing-fog-s-service-account-password

@Sebastian-Roth I remoted into the OPs fog server. I switch him over to the working branch and repulled the using git. After I reran the installer all of the files were where they should be. He was able to schedule a deployment. I think he is good for now.