Best posts made by george1421

george1421

Use dnsmasq on the fog server to supply the pxe boot information.

The quick steps are this.

Remove the pxe boot information from your router.
Install dnsmasq service from your linux distribution’s repo
Make sure its at least version 2.76 by issuing this command at the fog server’s linux command prompt sudo dnsmasq -v The version needs to be 2.76 or later.
Create a configuration file called ltsp.conf in /etc/dnsmasq.d directory.
Paste this content into that file.

# Don't function as a DNS server:
port=0

# Log lots of extra information about DHCP transactions.
log-dhcp

# Set the root directory for files available via FTP.
tftp-root=/tftpboot

# The boot filename, Server name, Server Ip Address
dhcp-boot=undionly.kpxe,,<fog_server_IP>

# Disable re-use of the DHCP servername and filename fields as extra
# option space. That's to avoid confusing some old or broken DHCP clients.
dhcp-no-override

# inspect the vendor class string and match the text to set the tag
dhcp-vendorclass=BIOS,PXEClient:Arch:00000
dhcp-vendorclass=UEFI32,PXEClient:Arch:00006
dhcp-vendorclass=UEFI,PXEClient:Arch:00007
dhcp-vendorclass=UEFI64,PXEClient:Arch:00009

# Set the boot file name based on the matching tag from the vendor class (above)
dhcp-boot=net:UEFI32,i386-efi/ipxe.efi,,<fog_server_IP>
dhcp-boot=net:UEFI,ipxe.efi,,<fog_server_IP>
dhcp-boot=net:UEFI64,ipxe.efi,,<fog_server_IP>

# PXE menu.  The first part is the text displayed to the user.  The second is the timeout, in seconds.
pxe-prompt="Booting FOG Client", 1

# The known types are x86PC, PC98, IA64_EFI, Alpha, Arc_x86,
# Intel_Lean_Client, IA32_EFI, BC_EFI, Xscale_EFI and X86-64_EFI
# This option is first and will be the default if there is no input from the user.
pxe-service=X86PC, "Boot to FOG", undionly.kpxe
pxe-service=X86-64_EFI, "Boot to FOG UEFI", ipxe.efi
pxe-service=BC_EFI, "Boot to FOG UEFI PXE-BC", ipxe.efi

dhcp-range=<fog_server_IP>,proxy

Be sure to replace <fog_server_ip> exactly with the IP address of your fog server. Be aware that <fog_server_ip> appears multiple times in the config file.
Save and exit your text edit.
Issue the following command to restart dnsmasq service sudo systemctl restart dnsmasq
Ensure that dnsmasq service is running in memory by issuing this command ps aux|grep dnsmasq. You should see more than one line in the response. If its running then go to step 10.
Ensure that dnsmasq starts when the system is rebooting with sudo systemctl enable dnsmasq
PXE boot a target computer.

NOTE: If you are supporting multiple foreign subnets (not on the same subnet as your dnsmasq server, you will need to add additional with dhcp-range statements that properly describe that foreign network segment. If you fail to do this the dnsmasq server will not respond to the request from your dhcp-relay service an example of what is needed is below:

dhcp-range=<fog_server_IP>,proxy
dhcp-range=192.168.100.0,proxy,255.255.255.0
dhcp-range=172.16.45.0,proxy,255.255.255.0

Dhcp option 93 to hardware type table

DHCP option 93 Client architecture|
0 Standard PC BIOS
6 32-bit x86 EFI
7 64-bit x86 EFI
9 64-bit x86 EFI (obsolete)
10 32-bit ARM EFI
11 64-bit ARM EFI

george1421

Introduction

First I have to say this article contains the results of many brilliant people and is not my content. I’m only assembling this information into a consistent document instead of spread around buried in posts and responses. My intent is to not dig into the details behind the scripts or how to tweak them for your needs. You can read the links below to figure out why things are being done the way they are. I wanted to create a tutorial that was as close to a cut and paste to get driver injection going in your environment. Now I will primarily focus on Dell hardware for the main reason that Dell does supply driver archive files (known as .CABs) that can be downloaded and extracted quickly to create the driver structure. I’m sure that HP, Lenovo, and others have similar driver packs.

You can download the Dell driver cabs for your hardware from here: http://en.community.dell.com/techcenter/enterprise-client/w/wiki/2065.dell-command-deploy-driver-packs-for-enterprise-client-os-deployment

Reference links:
https://forums.fogproject.org/topic/4278/utilizing-postscripts-rename-joindomain-drivers-snapins
https://forums.fogproject.org/topic/7740/the-magical-mystical-fog-post-download-script-under-construction
https://forums.fogproject.org/topic/7740/the-magical-mystical-fog-post-download-script
https://forums.fogproject.org/topic/8878/fog-drivers-script-will-not-run-correctly-in-postdownloadscripts/46

george1421

In this series if posts I plan on outlining what the FOG post download script is, what its about, and how to use it to your advantage with image deployment.

I’ve debated with myself if another post was needed since Lee https://forums.fogproject.org/topic/4278/utilizing-postscripts-rename-joindomain-drivers-snapins and I https://forums.fogproject.org/topic/7391/deploying-a-single-golden-image-to-different-hardware-with-fog have written tutorial about them in the past.

Where I want to explore with this series of posts is more about the background behind its function and to cover some of the script elements from Lee’s and my previously linked tutorials.

First of all lets get a little background here and some terminology defined. The FOG image deployment system consists of three main components:

The FOG management environment. The FOG management environment is the FOG server itself, which is responsible for planning, scheduling, instructing and documenting the image deployment.
The FOS (FOG OS) target engine {need better name here}. The FOS target engine, or FOS (as it will be known in this document) is responsible for capturing and deploying images from the defined storage node, as well as other actions on the target computer. FOS is actually an FOG Project created high performance linux operating system that was specifically constructed to image target computers. We have to remember for the rest of the tutorial, FOS is a linux based operating system that is used to deploy any OS image to your target computer.
FOG Client. This is an add on utility service for windows and linux, which is installed on the final or target OS. The FOG Client queries the FOG server for instructions and actions. I’m not planning on discussing the FOG client during this tutorial since it is out of scope in regards to post installation scripting.

The FOG Post install scripts give FOG system admins the ability to inject actions in the image creation process. To allow this custom scripts to run the developers added an external call into the image deployment sequence. Just after the image is placed on the target computer’s storage device, the FOG server calls a script in the /images/postdownloadscripts directory (on the FOG server). That script is called fog.postdownload. The fog.postdownload script is created when the FOG Server is installed. In its default state the script doesn’t do anything much. It is just a place holder to call your custom post install scripts. As I mentioned the fog deployment process calls this fog.postdownload bash script just after the image is placed on the target computer’s storage device. Once all of the external post install scripts have completed the FOG server completes the imaging and data recording steps.

While the post install scripts are stored on the FOG server in the /images/postinstall directory, they are executed by FOS running on the target host. So you have to remember when writing your post install scripts, they execute from the perspective of the target host. The post install scripts have limited access to resources on the FOG server (outside of the /images directory), but have full access to the target host. As noted above, these scripts run on a linux OS, so any resource (programs) available to linux operating systems can be run against the target host. I want to make this distinction to make it clear that FOS is linux and not MS Windows based. So you can not run MS Windows based applications, like DISM, in your post install script. FOS and linux is very powerful, but also limiting in some ways. As long as you are aware that MS Windows based applications can not run in a post install script then you should have little trouble. There are some cross over applications that are compiled for both MS Windows and linux, you just need to ensure you have the correct application for the OS and architecture (IA32 or X64).

george1421

Setting up the foundation for installation

Hopefully this setup will be pretty clean and easy (just hoping…)

In this tutorial, I’ve personally setup each distribution and booted it into a virtual machine. I didn’t run the installer to completion, but I did ensure the installer was running as far as I took the install (unless otherwise noted).

These setups were only tested with a bios (legacy mode) target computer. They WILL NOT work with uefi systems. For uefi based systems they have their own kernel requirements and options. The intent of this tutorial was to show its possible to boot your installation media via pxe booting.

First we need to setup the storage locations for our boot images. The plan is to put the installation media on the /images nfs share and the boot kernel and initfs in the tftp boot directory.

mkdir /images/os
mkdir /tftpboot/os
mkdir /mnt/loop

For the foundation setup that should do it. On to the OS specific configuration…

Link to Windows 7 & Windows 10 BIOS Mode Only
Link WinPE 10 for BIOS and UEFI based systems
Link to Centos 7
Link to Ubuntu 16.04.03
Link to Ubuntu Desktop 19.10
Link to Ubuntu Server 19.10
Link to Ubuntu 17.10 Desktop
Link to Ubuntu 16.04.03
Link to Linux Mint 18.1
Link to Linux Mint 19.1 Cinnamon
Link to Debian 9.2
Link to OpenSuSE Leap 42.3
Link to Fedora Workstation v26
Link to Fedora Workstation v27
Link to Ubuntu Desktop 17.10
Link to installing Samba on your FOG server
Link to Kali Live 2017.3
Link to ESXi v6.5u1
Link to ESXi v6.7u2
Link to SystemRescueCd 5.2.2 x64
Link to GParted 0.33.0 x86
Veeam Agent Rescue DVD
Acronis 2018 (WinPE version)
Paragon Hard Disk Manager
Parted Magic version from May 2023

george1421

The developers found this issue to why the log file grew so big (after almost a year of log file collection). The log file will now be capped at the log file maximum set by the fog configuration settings. This was just a fluke case that caused this file to grow to an abnormal size.

The fix / log file limiting code will be in 1.3.5RC11 when its released.

george1421

What you need to understand that the FOS Engine (the customized linux operating system that captures and deployed images on the target computer) is a complete linux OS. It is built with 2 halves. The first part is the the kernel (bzImage) which contains the core linux functions as well as the compiled in device drivers. And the second part is the virtual hard drive (inits) which contains the linux utilities, programs, and fog command scripts. When you PXE boot a target computer into the iPXE menu, certain iPXE menu options will send the bzImage and inits files to the target computer. The iPXE menu will also send specific kernel parameters to tell the FOS Engine (linux) how to react when it boots.

You can take the FOS Engine (bzImage and inits) and just as easily boot directly from a usb flash if you use grub as your boot loader. The FOS Engine will boot from the USB stick without requiring the FOG server to be online. The FOS Engine won’t do much without the proper kernel parameters being passed from the FOG server. But in the end FOS is a specialized, high performance, standalone linux OS.

Now for specifics, I don’t have the details from inside FOS, but I suspect there is something in /etc/init.d that calls the main fog script called /bin/fog that script. The fog master script reads in the passed kernel parameters and then selects the proper task to execute.

george1421

Preface

The bits I’m going to cover here are the general outline of what needs to be done to create and deploy a hardware independent image across your fleet of computers. In this tutorial I’m going to discuss how to do this with Dell computers. I know this process works with Lenovo, Intel NUC, and a few others with some caveats. I’m going to touch on some steps that you need to do in MDT to build your universal reference image, but I’m not going to discuss how to setup MDT to create your reference images. There are plenty of examples on the internet on how to do this.

This process makes use of a custom script that gets executed post image deployment but prior to the reboot of the FOS client. This step is vial since we need to make some tweaks to the windows environment pre first windows boot. This is the key. I can’t/won’t share that script I created because of my contract with my employer, because it is derived work because of my employment. So that script is intellectual property of my company. I’ve held the job title of unemployed, its not a great title. The pay stinks, the stress level is high, but the hours are great. I don’t plan on going there any time soon, so no script for you. BUT, sitting here on my zorin (ubuntu) dell laptop I should be able to reverse engineer the important parts to give the crafty scripters here the tools they need to create their own post install script.

Our master image is created following the standard Microsoft SOE guidelines, meaning MDT to build the reference image, sysprep to reseal the image, use a custom unattend.xml file (required to make this process work for Win10) and some disk imaging tool to capture and deploy the image to the target hardware. In this process sysprep is mandatory since we want to create a single image that can be deployed to any hardware. The generalize process of sysprep removes all hardware references (for the reference image) so that when windows first boots it goes through the hardware discovery process. Without sysprepping the image the process I’m going to discuss will not work. So use sysprep.

When I started out creating this process for FOG, I began with the process we created for deploying Windows XP from a usb stick using Ghost. In that process we would automate the image deployment with ghost to lay a hardware independent image onto the target hardware and then detect the current hardware using a DOS program that would query smbios to get the target hardware. Then once the target hardware was known we would move the correct driver pack into a location where windows would find it on the first boot. This worked extremely well with Windows XP. So I took the knowledge that I had from that process and tried to do something similar with FOG.

I do have to say I did not think up this entire process all by my self. I did start the design base on the information found on this wiki page. https://wiki.fogproject.org/wiki/index.php?title=Auto_driver_Install This page and associated scripts gave me just what I needed to take our xp/ghost process and covert it to windows 7/FOG. So without that wiki page the remainder could not be possible.

george1421

NOTE: Changes in FOG's code since this article was written have made it harder to use NAS' as storage node with FOG. If you use a NAS with FOG 1.5.x and beyond the FOG replicator will continue to cycle and recopy files over and over again.

Part 1 NAS Setup

So far I’ve setup what should work from the synology NAS side of the fog storage node. This has NOT been proven to work just yet. So far the synology nas has been configured to what “should work”. On my test NAS I’m using DSM 6.0.

The following is just my short hand notes that will be used to create the actual tutorial. I’m out of time tonight to complete the docs for this.

The first thing we need to do is setup our NAS with the required network shares. To do this you need access to the Synology NAS’s web console. Log into the web console as admin and do the following.

Control Panel->Shared Folder
Create new share
Name: images
Location: volume 1
Checked Hide this shared folder in My Network Places
Checked Hide sub-folders and files from users without permissions
Press OK
NFS Permission (tab)
Create new Permission
Hostname or IP: *
Privilege: Read/Write
Squash: No mapping
Security: sys
Checked Enable asynchronous
Checked Allow users to access mounted subfolders
Control Panel->Shared Folder
Create new share
Name: snapins
Location: volume 1
Checked Hide this shared folder in My Network Places
Checked Hide sub-folders and files from users without permissions
Press OK
NFS Permision (tab)
Create new Permission
Hostname or IP: *
Privilege: Read/Write
Squash: No mapping
Security: sys
Checked Enable asynchronous
Control Panel->Shared Folder
Create new Share
Name: tftpboot
Location: volume 1
Checked Hide this shared folder in My Network Places
Checked Hide sub-folders and files from users without permissions
Press OK
NFS Permission (tab)
Create new Permission (we only need this nfs shared for setting up the storage node)
Hostname or IP: *
Privilege: Read/Write
Squash: No mapping
Security: sys
Checked Enable asynchronous
Control Panel->File Services
Select Win/Mac/NFS (tab)
Checked Enable NFS
Control Panel->File Services
Select FTP (tab)
Checked Enable FTP service (no encryption)
Checked Use the default port range
Control Panel->File Services
Select TFTP (tab)
Checked Enable TFTP service
TFTP root folder: tftpboot (this is the share name we created above)
Control Panel->User
Select User (tab)
Create user foguser
Name: foguser
Description: FOG User
Password: fogremote1 (pick your own secure password)
Conform Password: fogremote1
Checked Disallow the user to change account password
Press Next
Join to group: users
Press Next
images: RW
snapins: RW
tftpboot: RO
Press Next
(Assign quota as needed)
Press Next
Assign application permissions: None
Press Next
Speed limiting: None
Press Next
Press Apply
Control Panel->User
Select the Advanced (tab)
(scroll way at bottom)
Under User Home
Checked Enable user home service
Press Apply

That completes the setup of the Synology NAS.

In the next part we’ll test the network shares we setup above and create the remaining flag files and directory structure needed to transform the Synology NAS into a FOG storage node.

george1421

LET ME SAY THIS RIGHT OF THE BAT, I have not used this in my test environment, only on my dev box. So it may work well for production or it may fall flat. (it shouldn't because the code is solid). After my holiday I'll test it completely in my test environment before moving it to production.

I think I was able to create a solution for this issue. I attempted to do a git fork / pull request but I’m not sure it worked so for the sake of documentation I’ll update what I was able to do there.

First I created two new FOG Server pages. One is to pull the system variables I need into the fog postdownload bash scripts. The second page allows me to update/change a registered fog target computer name from a postdownload script. Just some background on this, my target machine names are all calculated based on the computer serial number and a OU prefix. Currently I’m using an unused field in FOG (Other1) to hold this OU prefix. So to properly and automatically name the target computer I need to pick up the serial number from smbios and combine it with the value from the other1 field in the host information. Below is what I’ve worked out to extend FOG to what I need.

Create the following file: /var/www/html/fog/service/sethostname.php

<?php
require_once('../commons/base.inc.php');
FOGCore::getClass('SetHostName');

Create the following file: /var/www/html/fog/service/hostinfo.php

<?php
require_once('../commons/base.inc.php');
FOGCore::getClass('Hostinfo');

Create the following class file: /var/www/html/fog/lib/fog/sethostname.class.php

<?php
class SetHostName extends FOGBase {
    protected $macSimple;
    protected $newName;
    protected $oldName;

    public function __construct($check = false) {
        parent::__construct();

        self::stripAndDecode($_REQUEST);
        $this->macSimple = strtolower(str_replace(array(':','-'),':',substr($_REQUEST['mac'],0,20)));
        $this->newName = substr(trim($_REQUEST['newname']," \t\n\r\0"),0,20);
        $this->oldName = substr(trim($_REQUEST['oldname']," \t\n\r\0"),0,20);

        ob_start();
        header('Content-Type: text/plain');
        header('Connection: close');

        if ((strlen($this->newName) > 3) & (strlen($this->oldName) > 0)) {
            $query = sprintf("UPDATE hosts JOIN hostMAC ON (hostMAC.hmHostID = hosts.hostID) SET hostName='%s' WHERE ( (hostMAC.hmMAC='%s') AND (hostName LIKE '%s') );", $this->newName, $this->macSimple, $this->oldName);

            self::$DB->query($query);
            echo "OK";
        } else {
            echo "Fail";
        }
        flush();
        ob_flush();
        ob_end_flush();
    }
}

Create the following class file: /var/www/html/fog/lib/fog/hostinfo.class.php

<?php
class HostInfo extends FOGBase {
    protected $macSimple;
    protected $repFields = array(
        'hostName' => 'hostname',
        'hostDesc' => 'hostdesc',
        'imageOSID' => 'imageosid',
        'imagePath' => 'imagepath',
        'hostUseAD' => 'hostusead',
        'hostADDomain' => 'hostaddomain',
        'hostADOU' => 'hostadou',
        'hostProductKey' => 'hostproductkey',
        'iPrimaryUser' => 'primaryuser',
        'iOtherTag' => 'othertag',
        'iOtherTag1' => 'othertag1',
        'lName' => 'location',
        'iSysman' => 'sysman',
        'iSysproduct' => 'sysproduct',
        'iSysserial' => 'sysserial',
        'iMbman' => 'mbman',
        'iMbserial' => 'mbserial',
        'iMbasset' => 'mbasset',
        'iMbproductname' => 'mbproductname',
        'iCaseman' => 'caseman',
        'iCaseserial' => 'caseserial',
        'iCaseasset' => 'caseasset',
    );

    public function __construct($check = false) {
        parent::__construct();

        self::stripAndDecode($_REQUEST);
        $this->macSimple = strtolower(str_replace(array(':','-'),':',substr($_REQUEST['mac'],0,20)));

        $query = sprintf("SELECT hostName,hostDesc,imageOSID,imagePath,hostUseAD,hostADDomain,hostADOU,hostProductKey,iPrimaryUser,iOtherTag,iOtherTag1,lName,iSysman,iSysproduct,iSysserial,iMbman,iMbserial,iMbasset,iMbproductname,iCaseman,iCaseserial,iCaseasset FROM (((hostMAC INNER JOIN (hosts LEFT JOIN images ON hosts.hostImage = images.imageID) ON hostMAC.hmHostID = hosts.hostID) LEFT JOIN inventory ON hosts.hostID = inventory.iHostID) LEFT JOIN locationAssoc ON hosts.hostID = locationAssoc.laHostID) LEFT JOIN location ON locationAssoc.laLocationID = location.lID WHERE (hostMAC.hmMAC='%s');", $this->macSimple);

        $tmp = (array)self::$DB->query($query)->fetch('','fetch_all')->get();

        ob_start();
        header('Content-Type: text/plain');
        header('Connection: close');

        foreach ((array)$tmp AS $i => &$DataRow) {
            foreach ((array)$DataRow AS $j => &$DataField) {
                echo  "export " . $this->repFields[$j] . "=\"" . $DataField . "\"\n";
                unset($DataField);
            }
            unset($DataRow);
        };
        flush();
        ob_flush();
        ob_end_flush();
    }
}

And finally the post install bits

Edit /images/postdownloadscripts/fog.postdownload and insert the following command before your custom post install script

. ${postdownpath}fog.hostinfo

Create the following file: /images/postdownloadscripts/fog.hostinfo

#!/bin/bash

  . /usr/share/fog/lib/funcs.sh;
  wget -q -O /tmp/hinfo.txt "http://<fog_server_IP>/fog/service/hostinfo.php?mac=$mac"
  . /tmp/hinfo.txt
  rm -f /tmp/hinfo.txt

If everything works as expected you should now have access to the following bash variables in your post install script

$hostname == name of the host (should overwrite existing $hostname)
$hostdesc == Description of host
$imageosid == Operating System ID (should be the same as $osid)
$imagepath == The root path of the image(should also be the image name)
$hostusead == 1 or 0 to add host to AD
$hostaddomain == host domain name
$hostadou == host target ou
$hostproductkey == host product key
$primaryuser == Value from Primary User field
$othertag == Value from OtherTag field
$othertag1 == Value from OtherTag1 field
$location == Location Name from location plugin
$sysman == System Manufacturer from smbios
$sysproduct == System Product Name from smbios (from full registration)
$sysserial == System Serial Number from smbios (from full registration)
$mbman == Motherboard Manufacturer from smbios (from full registration)
$mbserial == Motherboard Serial Number from smbios (from full registration)
$mbasset == Motherboard Asset tag from smbios (from full registration)
$mbproductname == Motherboard Product Name from smbios (from full registration)
$caseman == Case Manufacturer from smbios (from full registration)
$caseserial == Case Serial Number from smbios (from full registration)
$caseasset == Case Asset tag from smbios (from full registration)

And the last bit is to call the set host name function.
wget -q -“http://<fog_server_IP>/fog/service/sethostname.php?mac=$mac&oldname=$oldhostname&newname=$newhostname”

For this script to work you must supply the host mac address, its new host name and for safety sake its old host name to prevent an accidental host name change.

george1421

Part 2 FOG WebGui Configuration

We need to create a new Storage Group. Go to Storage->Add Storage Group
Enter a new Storage Group Name and Description
Press Save/Update to create this new Storage Group.
Note that now we have 2 storage groups (default and ImageStoreGroup2)
Now we need to add a new Storage Node. Go to Storage->Add Storage Node.
Enter the values in the storage node configuration appropriate for your setup. The key values to watch are the IP Address (fog server IP address), Is Master Node, Storage Group, Image and FTP Path. The rest can remain the defaults.
Its worth noting that the Management Username and Management Password are related to the FOG server where we just mounted to the new hard drive. If you don’t know what these values should be you can always inspect the default storage node settings. Just copy and paste them from the default storage node configuration to this new storage node configuration.
In the All Storage Nodes list note that the storage node ImageStore2 is attached to the ImageStoreGroup2 and that it is a Master Node in that storage group. This is important since only master nodes in a storage group can capture files.
Now we will setup an image definition to store images to this new storage group. Goto Image Management->Create New Image.
Enter the Image Name and select ImageStoreGroup2 for the Storage Group. Fill in the remaining fields as you would normally for the image.
Update your host to use this new image definition.
At this point we can schedule an image capture for this host. Go ahead an schedule a capture task for this host.
Below is a screen shot of the capture task as its running. The key thing to note here is that the Working with node points to our node definition that is pointing to /images2 directory. (Wh00t!!)
You can also confirm that the image is being saved to the /images2 directory by monitoring the partclone display.
We are done.

As you can see from this tutorial, its possible to add a second hard drive to your FOG server to add additional storage space by simply creating a loop back storage node definition. There are a number of steps involved with setting this up, so take it slow and follow each step exactly.

george1421

@oraniko What hardware are you using?

On my campus I have 15 standard hardware where I deploy 1 image to then and then copy the appropriate driver files during FOG imaging.

Ref: https://forums.fogproject.org/topic/7391/deploying-a-single-golden-image-to-different-hardware-with-fog
Ref: https://forums.fogproject.org/topic/8889/fog-post-install-script-for-win-driver-injection
Ref: https://forums.fogproject.org/topic/7740/the-magical-mystical-fog-post-download-script
Ref: https://forums.fogproject.org/topic/4278/utilizing-postscripts-rename-joindomain-drivers-snapins

george1421

We have seen (sometimes) the FOG Admin will use/change/modify the linux user fogproject’s user account properties and password (note: versions prior to 1.5.6 use fog as account name). This is generally a bad idea to use a service account for normal system maintenance. In fog’s case if someone outside of the FOG installer changes this account your fog installation will become broken.

Understand this linux user account fogproject (fog if you run 1.5.5 and earlier versions) is not the same as the default WebGUI administrator of the same name (fog). We are discussing resetting fog’s linux service account fogproject.

You will typically see this error when trying to capture an image to the FOG server. FOG will throw an error like:

Reattempting to update Database.... Failed

or

Message: ftp_login(): Login incorrect., Host: xx.xx.xx.xx, Username: fogproject

The following is the procedure for resyncing the fog service account. This must be done while logged in using a linux user account other than fogproject

Review the file /opt/fog/.fogsettings (this is a hidden file)
In that file there is a entry called password=
Capture that password. You will need it to reset the FOG server.
Hint: I can tell you its much easier to do these steps by connecting to your fog server using putty from a windows computer. Copy and paste works great using putty (free terminal program).
Now reset the linux user fogproject’s password with sudo passwd fogproject
Now go to the FOG WebGUI and FOG Configuration->FOG Settings->TFTP Server and ensure the password listed in FOG_TFTP_FTP_PASSWORD matches the password you collected in step 2.
While still in the FOG WebGUI goto Storage Management->All Storage Nodes select the default or storage node in question.
Ensure that Management Password matches the password you collected in step 2.
Now finally back in the linux console of the fog server, navigate to where your fog installer files are (typ either /root/fogproject or /opt/fogproject) and rerun the fog installer (./bin/installfog.sh) to realign the remaining bits…

Once these steps have been completed your FOG server should be happy with you again.

george1421

@julianh A SSD for only the OS will not add much value making FOG go fast. The critical data path is from /images -> nfs -> network -> target computer.

george1421

NOTE: This method below is no longer needed, but we are leaving it active for reference only. FOG now contains all of the tools you need to compile the current version of iPXE. That tutorial is listed here: https://forums.fogproject.org/topic/15826/updating-compiling-the-latest-version-of-ipxe

To answer several requests in the forum about changing the keyboard mapping in the FOG iPXE menu. The only way to do change the keyboard mappings is to recompile the iPXE kernels from their source code since the keyboard layout is defined/set at compile time and not run time.

By following the process below you should be able to compile your own copies of the ipxe boot kernels (undionly.kpxe, ipxe.efi or any other FOG Project supplied boot kernel).
Understand: This method of creating your own boot kernels is not supported by the FOG Project Developers. If your make your own boot kernels and your computers fail to pxe boot, YOU are responsible for fixing any issue (or rerun the fog installer to restore the files to what the developers have created and tested).

Be aware that FOG uses another open source application called iPXE to provide the dynamic menuing structure. iPXE is created and manged by the iPXE Project team and not the FOG Developers.

This tutorial is only an example of how one might compile your own iPXE boot kernels on your fog server.

If your fog server is Ubuntu based you will need to install the compiler and development tools

sudo apt-get install build-essential liblzma-dev

If your fog server is Centos based you will need to install the compiler tools and required library

yum groupinstall "Development Tools" 
yum install xz-devel

Change to your home directory and clone the ipxe source files

git clone http://git.ipxe.org/ipxe.git ipxe

Make back up copies of the files we ar e about to change.

mv ~/ipxe/src/config/console.h ~/ipxe/src/config/console.h.sav
mv ~/ipxe/src/config/general.h ~/ipxe/src/config/general.h.sav
mv ~/ipxe/src/config/settings.h ~/ipxe/src/config/settings.h.sav

If you have the FOG Project installer files already downloaded on your fog server, you can just copy the FOG Project customized files to the iPXE source directories

cp <path_to_installer_files>/fogproject/src/ipxe/src/config/* ~/ipxe/src/config
cp <path_to_installer_files>/fogproject/src/ipxe/src/ipxescript ~/ipxe/src

If you DO NOT have the FOG Project installer files you can download only the specific files needed from the FOG Project GitHub site to create your custom iPXE boot kernels:

wget https://raw.githubusercontent.com/FOGProject/fogproject/blob/master/src/ipxe/src/config/console.h -O ~/ipxe/src/config/console.h
wget https://raw.githubusercontent.com/FOGProject/fogproject/blob/master/src/ipxe/src/config/general.h -O ~/ipxe/src/config/general.h
wget https://raw.githubusercontent.com/FOGProject/fogproject/blob/master/src/ipxe/src/config/settings.h -O ~/ipxe/src/config/settings.h 
wget https://raw.githubusercontent.com/FOGProject/fogproject/blob/master/src/ipxe/src/ipxescript -O ~/ipxe/src/ipxescript

Use the linux command sed to change the keyboard mapping. To use the following command replace XX with the proper keyboard code for your location.
sed -i 's/KEYBOARD_MAP\tus/KEYBOARD_MAP\tXX/g' ~/ipxe/src/config/console.h

For example if you want to change the US keyboard to the French keyboard in the FOG iPXE menus you would replace XX with fr as in this example:

sed -i 's/KEYBOARD_MAP\tus/KEYBOARD_MAP\tfr/g' ~/ipxe/src/config/console.h

To be sure the settings are correct, you can run the following command to confirm the keyboard mappings have been changed.

grep -e 'KEYBOARD_MAP' ~/ipxe/src/config/console.h

[Editor note, insert expected output here]

All supported iPXE keymaps are listed on this page:
https://github.com/ipxe/ipxe/tree/master/src/hci/keymap

Now that you have the keyboard mapping set, lets compile iPXE…
Change to the iPXE source directory and run make clean to remove any unneeded bits

cd ~/ipxe/src
make clean

Build the BIOS boot kernel undionly.kpxe, rename the original undionly.kpxe file, and finally copy over the custom iPXE boot kernel.

make bin/undionly.kpxe EMBED=~/fogproject/src/ipxe/src/ipxescript
sudo mv /tftpboot/undionly.kpxe /tftpboot/undionly.kpxe.old
sudo cp bin/undionly.kpxe /tftpboot

Purge any prevoiusly built object files (aways good practice when you update configuration files.

make clean

If you have the FOG Project installer files already downloaded on your fog server, you can just copy the FOG Project customized files to the iPXE source directories

cp <path_to_installer_files>/fogproject/src/ipxe/src-efi/config/* ~/ipxe/src/config

If you DO NOT have the FOG Project installer files you can download only the specific files needed from the FOG Project GitHub site to create your custom iPXE boot kernels:

wget https://raw.githubusercontent.com/FOGProject/fogproject/blob/master/src/ipxe/src-efi/config/console.h -O ~/ipxe/src/config/console.h
wget https://raw.githubusercontent.com/FOGProject/fogproject/blob/master/src/ipxe/src-efi/config/general.h -O ~/ipxe/src/config/general.h
wget https://raw.githubusercontent.com/FOGProject/fogproject/blob/master/src/ipxe/src-efi/config/settings.h -O ~/ipxe/src/config/settings.h

Use the same sed command above to update the UEFI boot files. Hint: Don’t forget to replace XX with your desired keyboard map.

sed -i 's/KEYBOARD_MAP\tus/KEYBOARD_MAP\tXX/g' ~/ipxe/src/config/console.h

Build the UEFI boot kernel ipxe.efi, rename the original ipxe.efi file, and finally copy over the custom iPXE boot kernel.

make bin-x86_64-efi/ipxe.efi EMBED=~/fogproject/src/ipxe/src/ipxescript
sudo mv /tftpboot/ipxe.efi /tftpboot/ipxe.efi.old
sudo cp ~/ipxe/src/bin-x86_64-efi/ipxe.efi /tftpboot

If you need snponly.efi (roughly equivelent to BIOS’ undionly.kpxe) run these commands (Hint: This compile command will run really quick since all of the hard work was done in the previous step).

make bin-x86_64-efi/snponly.efi EMBED=~/fogproject/src/ipxe/src/ipxescript
sudo mv /tftpboot/snponly.efi /tftpboot/snponly.efi.old
sudo cp ~/ipxe/src/bin-x86_64-efi/snponly.efi /tftpboot

Clean up after yourself in case you need to build these kernels over again.

make clean

george1421

@AlexPDX Change the disk controller mode from raid-on to ahci mode and linux will detect the drives behind the controller. This is an age old issue with intel-rst disk controllers.

george1421

@sourcaffeine Welcome to the FOG Project.

Tom already covered the FOG shutdown capabilities.

Depending on your needs you can use a windows scheduled task to shutdown the workstations at a specific time and then if you have WOL setup on the workstations you can wake them up with fog. If you are linux aware you can even setup a cron job on the FOG server to do this at a specific time, like 6a so that all of the workstations are on when the workers get into the office.

As for the documentation the FOG wiki site contains an abundance of information of FOG some new and some a bit out of date. A good place to start learning fog is here:
https://wiki.fogproject.org/wiki/index.php?title=Booting_into_FOG_and_Capturing_your_first_Image

and here
https://wiki.fogproject.org/wiki/index.php?title=Deploying_your_Image_a_single_client

and of course the wiki home page.
https://wiki.fogproject.org/wiki/index.php?title=Main_Page

I could go on with specific references if you had a bit more details in what your intended purpose is.

We are always looking for other to contribute to the wiki, so if you do find a deficiency we are more than willing to take your input on how to better the documentation. I do have to say the FOG Project forums are quite active and if you run into issues with FOG either installing it or how to do something please post your concern in the proper forum.

cheers and happy imaging.

george1421

@ITSolutions said

Disadvantages in my personal opinion are few:

Need to have Linux knowledge(although having Linux knowledge is a advantage in the industry)
The other disadvantages I used to see, when I first found FOG in the .3x days have been corrected/added. I would like to see what others feel are disadvantages.

I can see the linux knowledge thing being a big issue for those that grew up in the MS Windows era. Once the system is setup you don’t need to step into linux at all. But every once an a while you need access to the linux command shell, so you will need someone in your company with some familiarity with linux.

Other things I can see that are limitations…
Access control. Right now there isn’t a real good way to limit what IT techs can do in the system. Like certain IT techs can only deploy images 1,2,3 to location C only.

Having a centralized login authentication system with either AD/LDAP.

Linux hardware drivers lag a bit behind windows drivers. The fact is that most hardware vendors develop hardware for the windows folks and then it seems like linux is either an after thought or some really smart linux people hack into the hardware and come up with their own linux drivers. (thinking about the surface pro 4 as I write this).

george1421

Here is a similar thread that discusses the same issue and the commands needed to disable it: https://forums.fogproject.org/post/102522

Review the posts by @THEMCV they are enlightening. This issue does come up quite often. Most specifically this post:

Try this, I ran into this on Surface’s.

Open command prompt as admin.

manage-bde -off

manage-bde -status

Fingers crossed that it will fix it. In my case, Windows was by default encrypting the free space which caused issues.

george1421

If you have the resources, just spin up a new clean instance of ubuntu 16.04 and FOG 1.3.1-RCx instead of upgrading your existing server.

The logic here is two folder.

You are versioning over a large gap both for ubuntu and FOG. This can be done, but you will spend more time rolling the OS from 10.04 to 16.04 than just spinning up a new server.
If something happens during the upgrade you will loose access for imaging. Keeping your legacy FOG server functional will give you a working FOG system while creating your new FOG server.

You can move the images between fog servers OK, but unless you have a huge number of fog clients, you would be better served by just recreating the hosts in your new fog server instead of copying the DB over. Also with the images created with 0.3x, you would be better served by converting them to the newer FOG 1.3.x format. This will save on deployment times since the new format deploys quite a bit faster than the old format.

george1421

@developers Here’s the final update on this issue.

I reset my kernel build environment and then created 2 new kernel builds. The first was to remove the imposed CPU limit on the linux kernel this kernel was called bzImageMaxCPU. I reset the kernel build environment and then went through the ACPI settings turning on what I turned on in the debug kernel. This kernel was called bzImageACPI.

The OP tested both and the bzImageMaxCPU was the only kernel that booted on those Dell servers. So in the end @Quazz was right about the CPU not liking some of its cores disabled.

So I would recommend that we add the following settings to the official kernel build

CONFIG_INTEL_IDLE
and
Processor type and features —>

Enable Maximum number of SMP Processors and NUMA Nodes

We have seen a recent uptick in reports of rcu_sched stalls with kernel panics Maybe we are running into this issue more often as the core counts go up on these processors.