Just a couple of thoughts of the top of my head.

1. For the root password in the db. By default pick a random password and then give the user the option to change it, akin to how the fog installer picks the network adapter, but then lets the user change it. The fog installer should warn the user to write this password down someplace because its important and would be needed for database repair.
2. The fogdb user’s password should be managed like the fogproject linux user’s password. Its owned and set by the fog installer, but is recorded in the .fogsettings file. If the fogdb user’s owns the fog db, then there really is never a reason to use the db’s root user any more.
3. For the db’s root user password resets, I don’t think we need to reinvent the wheel here. Maybe provide a wiki with examples for the big three centos, debian, and ubuntu (current minus 2 releases if there is any changes) and then say for other distros they will need to google the answer. Lets not kill our selves trying to be all things to everyone. If the fog admin has deviated from the recommended distros then they should have enough skills to reset the root password. Its not that complicated.

While I’m not familiar with the snapin system, that error makes me think that someone edited / changed the fog service account (fog’s) password. Understand this is the linux user called fog not the default webgui password of the same name. If you have happened to change the linux user fog password there is a sequence you need to follow to reset it back to a known value. https://forums.fogproject.org/topic/11203/resyncing-fog-s-service-account-password

@jj-fullmer said in OS Support - the numbers are in:

Also, for those 122 of us on the older CentOS 7/8, would this change to the installer make it so we need to move distros for future updates?

First let me say that Centos and RHEL is dead to me, so I might get a bit snarky… IBM has done to RHEL/Centos what its done to every other fine product its acquired.

Well with the end of support for real centos 8 ending in just a few days I don’t see any additional development work needed to maintain support for that. I can see value in saying that FOG only supports “currently maintained operating systems”. With centos 7 running til 2024 I think over time, system attrition we will also see a drop in support for centos 7. For FOG there probably isn’t a reason to change its installer base since the OS is pretty well fixed/non-changing now. There shouldn’t be a lot of dev overhead needed here. I’m also waiting to see if the RHEL forks pick up like rocky mount. So I wouldn’t throw out the rpm install bits just yet.

The other question is about the other mainstream OS like Arch and its forks. Should that be officially supported?

Finally on my campus we are slowly moving away form Centos to Debian as the platform of choice for new installs of linux. To me Ubuntu could likely be sucked into Microsoft and then where would we stand? (that embrace, extend, extinguish bit… and all that).

I found what the installer did incorrectly.

This is the default config file /etc/apache2/sites-enabled/001-fog.conf.

<VirtualHost *:80>
    <FilesMatch "\.php$">
        SetHandler "proxy:fcgi://127.0.0.1:9000/"
    </FilesMatch>
    KeepAlive Off
    ServerName 10.0.0.6
    DocumentRoot /var/www/
    RewriteEngine On
    RewriteCond %{REQUEST_METHOD} ^(TRACE|TRACK)
    RewriteRule .* - [F]
    <Directory /var/www/fog/>
        DirectoryIndex index.php index.html index.htm
        RewriteCond %{DOCUMENT_ROOT}/%{REQUEST_FILENAME} !-f
        RewriteCond %{DOCUMENT_ROOT}/%{REQUEST_FILENAME} !-d
        RewriteRule ^/(.*)$ /fog/api/index.php [QSA,L]
    </Directory>
</VirtualHost>

The closing </Directory> directive is in the wrong place. It should look like this:

<VirtualHost *:80>
    <FilesMatch "\.php$">
        SetHandler "proxy:fcgi://127.0.0.1:9000/"
    </FilesMatch>
    KeepAlive Off
    ServerName 10.0.0.6
    DocumentRoot /var/www/
    RewriteEngine On
    RewriteCond %{REQUEST_METHOD} ^(TRACE|TRACK)
    RewriteRule .* - [F]
    <Directory /var/www/fog/>
        DirectoryIndex index.php index.html index.htm
    </Directory>
    RewriteCond %{DOCUMENT_ROOT}/%{REQUEST_FILENAME} !-f
    RewriteCond %{DOCUMENT_ROOT}/%{REQUEST_FILENAME} !-d
    RewriteRule ^/(.*)$ /fog/api/index.php [QSA,L]
</VirtualHost>

Note: I also indent corrected the rewrite rules
If you correct your /etc/apache2/sites-enabled/001-fog.conf how I listed above FOG 1.5.2 will work correctly.

The issue here is not so much SSD drives but NVMe drives. FOG 1.2.0 does not support NVMe drives at all. Its not related just to the kernel in play, but the actual drive itself and its partitions are named different. The developers had to reengineer the FOS Engine (the customized linux OS that captures and deploys images) to specifically support NVMe drives.

At this point your only option to support these systems is to upgrade to 1.3.0RCx series. Other advantages of upgrading is much better GPT support, native Win10 support, faster image deployment, plus many new feature enhancements.

@Sebastian-Roth The more I look into this the more I’m going to blame mysql and the ISAM table format for the OP’s issue. ISAM uses table locking for updates to the data, where INNODB uses row level locking for updates. SO if you have 10 systems updating the fog history table that is in ISAM format, one system will have update access while 9 will be placed in a blocked status until the first system finishes its update action. When the first finishes, then the second in line will get its chance and so on. I think with FOG 1.6.x stream we should setup the innodb as the default table engine. Understand we NEED to do a lot more bench marking on this issue, but I think with the help of the OP and other large FOG deployments we can get a better understanding of what it will take to make FOG go faster…

@msi There is a know issue with the linux kernel (Not FOG) booting in uefi mode with disk mode in raid-on. If you switch to ahci mode then linux (FOS) will see the disk. Leave your current debug task running, just manually reboot the target computer, update the firmware with ahci mode, then boot back into fog imaging. Then run the lsblk command again. This time you should see your disk. You can either leave in ahci mode or switch back after imaging.

In the dell firmware change the disk mode from raid-on to ahci mode then it will find the disk. This is a know linux/dell/intel raid controller issue.

Also update your fos linux kernels. Be aware this has nothing to do with the FOG Host server but with FOS Linux. Goto FOG Configuration -> Kernel to update FOS Linux kernel.

Here is the sql script as I have it so far. It does work as advertised. Right now I’m doing additional testing on my dev FOG server before its put on the production server. This trigger will fire when a new host is associated with a group and there is a host with the same exact name as the group name.

DELIMITER $$

CREATE TRIGGER new_groupmember_added 
AFTER INSERT ON `groupMembers` 
FOR EACH ROW
BEGIN

 SET @myHostID = NEW.gmHostID;
 SET @myGroupID = NEW.gmGroupID;

 SET @myTemplateID = (SELECT hostID FROM groups INNER JOIN hosts ON (groupName = hostName) WHERE groupID=@myGroupID);

 IF (@myTemplateID IS NOT NULL) AND (@myHostID <> @myTemplateID) THEN
   UPDATE hosts d, (SELECT hostImage, hostBuilding, hostUseAD, hostADDomain, hostADOU, 
   hostADUser, hostADPass, hostADPassLegacy, hostProductKey, hostPrinterLevel, hostKernelArgs, 
   hostExitBios, hostExitEfi FROM hosts WHERE hostID=@myTemplateID) s
   SET d.hostImage=s.hostImage, d.hostBuilding=s.hostBuilding, d.hostUseAD=s.hostUseAD, d.hostADDomain=s.hostADDomain,
   d.hostADOU=s.hostADOU, d.hostADUser=s.hostADUser, d.hostADPass=s.hostADPass, d.hostADPassLegacy=s.hostADPassLegacy,
   d.hostProductKey=s.hostProductKey, d.hostPrinterLevel=s.hostPrinterLevel, d.hostKernelArgs=s.hostKernelArgs,
   d.hostExitBios=s.hostExitBios, d.hostExitEfi=s.hostExitEfi
   WHERE d.hostID=@myHostID;

   INSERT INTO locationAssoc(laHostID,laLocationID)
   SELECT @myHostID as laHostID,laLocationID
   FROM locationAssoc WHERE laHostID=@myTemplateID;

   INSERT INTO printerAssoc(paHostID,paPrinterID,paIsDefault,paAnon1,paAnon2,paAnon3,paAnon4)
   SELECT @myHostID as paHostID,paPrinterID,paIsDefault,paAnon1,paAnon2,paAnon3,paAnon4
   FROM printerAssoc WHERE paHostID=@myTemplateID;

   INSERT INTO snapinAssoc(saHostID,saSnapinID)
   SELECT @myHostID as saHostID,saSnapinID 
   FROM snapinAssoc WHERE saHostID=@myTemplateID;

   INSERT INTO moduleStatusByHost(msHostID,msModuleID,msState)
   SELECT @myHostID as msHostID,msModuleID,msState
   FROM moduleStatusByHost WHERE msHostID=@myTemplateID;

 END IF;

END;
$$

DELIMITER ;

@kalafina OK great. It appears that time fixes your problem. (not trying to be funny). This usually indicates standard spanning tree is enabled on this network port. FWIW standards spanning tree takes 27 seconds from the network link going up before it starts to forward data. FOS Linux boots so fast, in that it’s already errored out before spanning tree starts forwarding.

One quick test is to place a cheap-o/unmanaged switch (like those 5 port 1GbE switches from monoprice) between the building switch and the pxe booting client. These cheap switches typically don’t use the spanning tree protocol, plus they keep the building switch port from “winking” as the target computer boots.

If the cheap switch solves your problem, then look into the building switch’s configuration. You need to enable port-fast, fast-STP, RSTP, MSTP or what ever your switch mfg calls fast stp.

Also, intel network adapter [8086:15d6] was first added to the linux kernel in version 4.6 so having a current kernel (5.15) while its helpful for other hardware it will not solve this issue. I really think we need to focus on spanning tree.

The question order seems to be a bit out of place in the fog installer. The installer asks you a few questions about dhcp then asks you if you want to install the FOG dhcp server. IMO it should ask you if you want to install the dhcp server first then if yes ask the other questions.

Below is the current question ask order

What network interface would you like to use? enp0s31f6

Would you like to setup a router address for the DHCP server? [Y/n] n
Would you like DHCP to handle DNS? [Y/n] y
What DNS address should DHCP allow? [1.1.1.1]
Would you like to use the FOG server for DHCP service? [y/N] y

You may has why do we need this?

UEFI PXE booting is a bit different than BIOS based PXE booting. Some of the early UEFI systems like the Dell Latitude e6420 and the OptiPlex 790 do not support PXE booting in UEFI mode. But through testing they do support USB booting in PXE mode. So knowing this I’m going to set out a simple solution to PXE boot these devices in UEFI mode. I can say for sure this method works with the previous mentioned systems. YMMV with other hardware platforms.

The process steps are not hard at all (actually even easier than USB BIOS PXE booting). You will need to acquire these things.

1. A 2GB (min) flash drive
2. A UEFI pxe boot image from a functioning FOG server.

Boot image creation process

1. Insert your flash drive into a Windows based computer and format it with FAT32 disk format
2. On that flash drive create a folder called EFI
3. On that same flash drive create a folder called BOOT in the EFI folder creating this path “x:\EFI\BOOT”. Note: I have not tested if case is important or not, I used upper case for everything and it worked. That is as far as I tested.
4. From a functioning FOG server copy /tftpboot/ipxe.efi to your windows computers. (pscp from putty tools works great)
5. Copy that file to the flash drive in the EFI\BOOT folder. That file MUST BE RENAMED to bootx64.efi (note the case difference. I did not test to see if case is important)
6. At this point remove the usb thumb drive from the build up computer and insert the drive into a target computer
7. Power on the target computer and press F10 or F12 (depending on the mfg) to call up the EFI boot menu.
8. Select the USB boot device under the EFI section of the EFI menu
9. You should see the iPXE boot banner and then after about 30 seconds it should be prompted for the IP address of your FOG server. Key in the IP ADDRESS of your FOG server and press Enter.
10. At this point you should boot into the FOG iPXE menu.

@anthonyglamis if you are using svn to manage the trunk package, you change into the trunk folder and run svn up that will download the latest code from the subversion repository. Then cd bin and then ./installfog.sh

If you are using git they have a comparable update command.

WARNING: this tutorial is no longer relevant since the rom-o-matic site has been shutdown since Dec 2019. These instructions are no longer valid and can be followed. I'm leaving these instructions here for historical reasons. No additional support on this topic can be provided since they depend on an external web site working

You may has why do we need this?

UEFI PXE booting is a bit different than BIOS based PXE booting. Some of the early UEFI systems like the Dell Latitude e6420 and the OptiPlex 790 do not support PXE booting in UEFI mode. But through testing they do support USB booting in PXE mode. So knowing this I’m going to create the harder solution (see easier solution if this method is too complicated for your needs) to PXE boot these devices in UEFI mode. This method we will create a new efi boot kernel to install on our usb flash drive to boot into the FOG environment. Building linux kernels are not extremely difficult using the rom-o-matic, but because of the number of options you can choose, you can run into problems if not created correctly. I can say for sure this method works with the previous mentioned systems. YMMV with other hardware platforms.

The process steps are not that hard, its a bit like giving your self a root canal without medicine. It will hurt like crazy while you are doing it, but once its over you will have the satisfaction of not wanting to ever do it again <jk>. Its not really that hard, the rom-o-matic does all of the work.

You will need to acquire these things.

1. A 2GB (min) flash drive
2. A UEFI pxe boot image we will create from the rom-o-matic web site

iPXE UEFI boot kernel creation process

1. From a browser access the rom-o-matic web site at https://rom-o-matic.eu/
2. Select Advanced, for experienced users radio button
3. In the drop down list for the output format select EFI PXE bootstrap 64-bit (.efi) selection.
4. Ensure that NIC type is set to all-drivers (default)
   Since there are a ton of settings that could be changed here, I'm only going to post the changes from the default settings for the PXE boot. HINT: You may want to search in your browser for the variable names I used below to locate the exact setting in question.
5. Section: Download protocols.
   DOWNLOAD_PROTO_HTTPS = checked
   DOWNLOAD_PROTO_FTP = checked
   DOWNLOAD_PROTO_NFS = checked
6. Section: SAN boot protocols
   All checked in this section except HTTP_ENC_PEERDIST = unchecked
7. Section: Image types
   All unchecked except IMAGE_PNG = checked
8. Section: Command-line commands to include
   All checked except IWMGMT_CMD = unchecked, PXE_CMD = unchecked, PROFSTAT_CMD, = unchecked
9. Section: Console options
   All unchecked except CONSOLE_FRAMEBUFFER = checked
10. Section: Embedded script add in the following script

#!ipxe

set fogserver 192.168.1.88

isset ${net0/mac} && dhcp net0 || goto dhcpnet1
echo Received DHCP answer on interface net0 && goto netboot

:dhcpnet1
isset ${net1/mac} && dhcp net1 || goto dhcperror
echo Received DHCP answer on interface net1 && goto netboot

:dhcperror
prompt --key s --timeout 10000 DHCP Failed, hit 's' for the iPXE shell; reboot in 10 seconds && shell || reboot

:netboot
cpuid --ext 29 && set arch x86_64 || set arch i386
params
param mac0 ${net0/mac}
param arch ${arch}
param platform ${platform}
param product ${product}
param ipxever ${version}
isset ${net1/mac} && param mac1 ${net1/mac} || goto bootme

:bootme
chain http://${fogserver}/fog/service/ipxe/boot.php##params

Be sure to change the ip address above for next-server to the IP address of your FOG server. You must use an IP address and not the conical name of your fog server.

11. Section: Which revision should be set to Master (default)
12. Press the Proceed >> button. After a bit you will be prompted to download a file called **ipxe.efi ** be sure to save it. We will need this file in the section below.

Boot drive creation process

1. Insert your flash drive into a Windows based computer and format it with FAT32 disk format
2. On that flash drive create a folder called EFI
3. On that same flash drive create a folder called BOOT in the EFI folder creating this path “x:\EFI\BOOT”. Note: I have not tested if case is important or not, I used upper case for everything and it worked. That is as far as I tested.
4. Copy the ipxe.efi kernel created in the previous section to the flash drive in the EFI\BOOT folder. That file MUST BE RENAMED to bootx64.efi (note the case difference. I did not test to see if case is important)
5. At this point remove the usb thumb drive from the build up computer and insert the drive into a target computer
6. Power on the target computer and press F10 or F12 (depending on the mfg) to call up the EFI boot menu.
7. Select the USB boot device under the EFI section of the EFI menu
8. You should see the iPXE boot banner and then after about 30 seconds it should be prompted for the IP address of your FOG server. Key in the IP ADDRESS of your FOG server and press Enter.
9. At this point you should boot into the FOG iPXE menu.

While I don’t remember v2929 that number is close to FOG 1.2.0 stable, which does not support NVMe drives, gpt disks, or Win10 (in general).

What error is being thrown when you try to upload that image?

The ultimate answer is to upgrade to 1.3.0-RCX to get new hardware support as well as Win10 Support. But I do have to admit that I have not created a 1607 reference image as of yet, so there may be changes that not even fog 1.3.0 supports as of now.

Part 2 FOG Post install script.

As I noted above, the post install script is called by the FOS target engine just after the image has been copied to the target host computer and before the house keeping and recording steps are performed. (Hint, don’t force a reboot in your post install script or the house keeping and recording steps will not be performed). There is a call to execute the /images/postdownloadscripts/fog.postdownload script. You should hook your custom post install scripts into this bash script file.

The bash shell environment (created in 1988) is a mix of operating system interface (command processor) and programming environment. In windows terms, think of it as a great, great, grandfather to what MS PowerShell will be one day. If you are a PowerShell maven, a lot of the PS look and feel came from this era of command processors, so programming in bash is just a syntax change, the program flow is very similar. The bash shell script can call linux applications, create run time variables, and produce output that can be written directly to disk storage or filtered through another linux application before being written to disk (we are going to take advantage of this functionality in our fog post install scripts. I’m not going into the details of bash programming. The environment has been around for almost 30 years, there is plenty of examples on the internet to follow. I will go into the specifics of what we need to do in bash to connect to the target computer’s hard drive and query info about the target computer. In our case we can either query the computer directly to find out key elements of its design or since FOG r8050 we can make a call back to FOG to retrieve things that FOG knows about the target computer.

For our example post install script we are going to create it next to the existing fog.postinstall script. I do recommend that you compartmentalize your fog post install scripts based on their task and not just have a single monolithic (i.e. big a$$) script. Its much easier to maintain smaller and specific code elements. I also recommend that you write your own scripts in your own files and not just use the fog.postdownload script for your scripts. The nature of that FOG owned script may change over time. I would not want changes to the fog.postdownload script to erase your content.

For our example fog post install script, I’m calling it fog.postexamp and will place it in the /images/postdownloadscripts directory. For clarity you can call this script anything you want, I’ve just kept with the fog naming convention of “fog.<action>”.

For this example I'm running as root on centos, for other linux distros you will probably need sudo. For this thread assume all commands have a hidden sudo on front

1. Lets begin to create our script
   touch /images/postdownloadscripts/fog.postexamp
2. We’ll need to make it runable
   chmod 755 /images/postdownloadscripts/fog.postexamp
3. With your favorite text editor, edit the fog.postexamp script.
4. For every bash script you must insert this mandatory line on the very first line of your script. There can be no blank lines above or spaces to the left of this text. So insert this on the very first line of your bash script. #!/bin/bash and press enter. This line tells the command processor to use bash to process this script.
5. Now I recommend that you enter several lines of comments to describe what this script does, who created it, and any other relevant information. Comment lines for bash begin with a pound symbol (a hash tag for the millennials) and then the remainder of the line is text to the end of the line.
6. We are going to take advantage of one of the fog developers scripts for several interesting functions later so lets include that script in our script. After your comments enter the following line . /usr/share/fog/lib/funcs.sh (note: again don’t forget that lonely dot plus a space before the path to the script).

Comment: As I mentioned before the fog post install scripts execute on the FOS client, so the /usr/share/fog/lib/funcs.sh is not on the FOG server, but on the FOS virtual hard drive (a.k.a the inits). So if you are nosy you won’t find this file if you search the path on the fog server.

7. At this point your fog.postexamp script should look something like this one

#!/bin/bash

#
# This is an example script that will show you the recommend way to create a 
# FOG post install script. There are many ways you can go about this, some will be better than 
# others. 
#
# Author: George1421
# Version: 1.0
# Date: 20160611
#

. /usr/share/fog/lib/funcs.sh

8. If you stop right here you have a complete fog post install script. Admittedly it doesn’t do anything special, but you DO have a complete script.
9. The rest of the script will be up to you to decide what you want your post install script to do. I’ll include more code fragments that you can assemble into your own script in Part 3

Part 1 Prerequisites

This tutoral will show you how to pxe boot a target computer into the windows 7 setup program. While I see little value in this since there are other methods to go about installing Windows 7, this question gets asked now and again in the FOG forums. Just recently I had the opportunity to sit down and outline a process for doing this task.

The traditional method of just loading the iso image on the FOG server and sending it via PXE is not possible since the WIndows 7 dvd is over 3GB in size. Attempting the pxe boot just the boot.wim also fails since the winpe environment that is shipped on the DVD looks for the CDROM drive to load its setup. To work around this issue I ended up building my own WinPE boot image that was able to boot over PXE and then connect to a network share which held the Windows 7 DVD files. All hardware specific network and disk drivers are loaded into the custom WinPE environment, understand that these drivers will not be copied to your target computer, you will need to provide the proper network drivers to your target OS once its installed too.

To build this custom WinPE boot image you will need the following.

1. Windows 7 WAIK https://www.microsoft.com/en-us/download/details.aspx?id=5753
2. Not necessary but a good idea Windows 7SP1 WAIK https://www.microsoft.com/en-us/download/details.aspx?id=5188
3. The WinPE 3.0 Driver CAB from Dell (reported to work with some other manufacturers) http://downloads.dell.com/FOLDER03652574M/1/WINPE3.0-DRIVERS-A20-CT5DP.CAB
4. A fresh Pepsi cola and about 15 minutes of time.

Now you need to architecture of WinPE 3.0 you will build. Its important to point out in the beginning so you don’t get to the end and get surprised. WinPE x86 can install both x86 and x64 bit versions of the OS. WinPE x64 can only install x64 bit versions of the OS. So if you know you will only deploy x64 bit OS then go ahead and build a WinPE x64 image, otherwise you might want to play it safe and go with WinPE x86. They are functionally equivalent and there is no difference in the creation or the execution. You just need to pick one and work with it. I’ll give you directions to both so you can make both if you want.

The last bit of house keeping is to give some background links on where we are going here.

Source of the request to build a solution to PXE boot into windows setup.
https://forums.fogproject.org/topic/7751/fog-pxe-ipxe-boot-win-7-wimboot-cd-dvd-missing-issue
http://www.tecmint.com/installing-windows-7-over-pxe-network-boot-in-centos

Tutorial I wrote on PXE booting into the MDT lite touch setup
https://forums.fogproject.org/topic/6284/booting-mdt-2013-litetouch-with-fog

The first thing that needs to be done is setup your winpe build out environment

1. Install WAIK and the WAIK supplement programs.
2. Extract the Dell CAB file to c:\winpe (Hint: If you open the CAB with 7-Zip you can just drag the winpe folder from the cab and drop it on the root of C:. If you need additional drivers not supplied by the Dell cab then download the proper WinPE 3.0 driver cab for your hardware and merge it into the winpe folder structure.
3. Now from the start menu launch the WAIK command line tool {insert actual path to tool here} with the “Run as Administrator” option.
4. On a Windows server/Workstation create a network share. Set the permissions appropriate for you environment. The WinPE environment that we are building needs read only access to this network share based on the user ID we’ll provide in our script.
5. Copy the entire contents of the WIndows 7 DVD to this network share
6. Take a sip of your cola now we’re about to get busy
7. Continue to Part 2 for x86 or Part 3 for x64 WinPE environments.

Part 3 (When simple is not so simple)

This process is much more involved since we need to locate the RAID driver interface (blind approach).

1. The first thing we need to do is register this new target computer
2. Using the FOG web gui navigate to this target computer’s host configuration page
3. In the Host Kernel Arguments, enter mdraid=true
4. Save the settings
5. Schedule a debug deploy (you can choose capture or deploy it doesn’t matter, what we need is console access on the FOS engine).
6. PXE boot the target computer into the debug console (you may have to press enter a few times to get past the wall of text)
7. Once you are at the FOS command prompt key in the following: cat /proc/mdstat You should see a similar display as this

# cat /proc/mdstat

personalities : [linear] [raid0] [raid1] [raid10] [raid6] [raid5] [raid4] [multipath] [faulty]
md126 : active raid0 sda[1] sdb[0]
      156307456 blocks super external:/md127/0 128k chunks

md127 : inactive sdb[1](S) sda[0](S)
      4856 blocks super external:imsm

unused devices: <none>

I’m not going to decode this output for you other than to say that the line that starts with md126 is the array we are search for. If your RAID controller has multiple arrays created, you should see them here. You will need to identify which array will be your target array. You can see that our target array is made up of members sda and sdb in a raid0 configuration. Remember mdf126 is the driver name we need.
8. The next step is to query the raid driver/array for its status. The cat command above told the structure of the array, not the condition of the array. To check the condition of the array we’ll use the mdadm -D /dev/md126 command. Note that the array is referenced by its device driver name (/dev/md126). After you key in that command you should see an output similar to this

# mdadm -D /dev/md126

/dev/md126:
      Container : /dev/md/imsm0, member 0
     Raid Level : raid0
     Array Size : 156307456 (149.07 GiB 160.06 GB)
   Raid Devices : 2
  Total Devices : 2

          State : clean
 Active Devices : 2
Working Devices : 2
 Failed Devices : 0
  Spare Devices : 0

     Chunk Size : 128K


           UUID : d0202e14:9f7ca368:a44d0646:e4480443
    Number   Major   Minor   RaidDevice State

The key values to note here is the array size, state and working devices. If everything looks good then continue onto the next step.
9. So through this process we identified that the host primary disk (in this case) is /dev/md126.
10. Back in the FOG web gui update the host information for this target computer, set Host Primary Disk: to the value we identified in step 9 (in this case /dev/md126)
11. Save the settings
12. Delete the pending debug task for this target system
13. Schedule a real capture/deploy job (no debug mode this time)
14. Key in reboot on the target computer in debug mode.
15. PXE boot the target system and monitor its progress
16. Done.

Let me preface this with the following: Just because you can do something, it doesn’t mean you should.

I’ll repeat that again: Just because you can do something, it doesn't mean you should.

Please understand installing FOG on a Raspberry Pi is NOT recommended by the Developers of FOG. If you ask them for help they will only smile politely and tell you to move on, what you are doing is not supported. So don't ask them for help.

I’ve wanted to for a while see if I could install fog on a Raspberry Pi. In my case I have a Raspberry Pi that my brother gave me. It is currently running my home voip PBX. I took it down for a bit to prove this project out. If I was to build a FOG-Pi mobile deployment server I would not use the Pi-2b that I currently have. This system has an OK processor but the network interface is 100Mb/s, which will clamp my overall throughput to 12MB/s. If given a choice I would use a Pi3 for the demo project. An $80 complete mobile FOG deployment server does have its allure.

But in reality given a choice I would not use a Raspberry Pi, I would use a dual core Intel NUC with an built in SSD drive for about $280USD. Because of the scope of this project we’ll stick with a Pi2b.

In addition to the Raspberry Pi you will need to pick up a decent micro SD card that will be used for storage. Depending on the size of your images a 32GB Samsung EVO Class 10 costs about $12USD from amazon. A 64GB EVO will cost you about $20USD from Amazon.

For this project I used Raspbian Jessie downloaded from the official Raspberry Pi site: https://www.raspberrypi.org/downloads/raspbian/

Follow the instructions on the following page to write the downloaded image file onto the micro sd card: https://www.raspberrypi.org/documentation/installation/installing-images/README.md

After the image as been written to the micro sd card, move the card to the Pi and boot it up. You can either use the console to key in the remaining commands or you can use ssh and remote into the Pi once you determine its IP address.

Before we start installing FOG, we need to execute a few steps to prepare the Pi.

1. Run the Raspbain configuration tool sudo raspi-config
2. Change these settings:

1) expand filesystem to fill the storage device
2) Change user password
3) Boot options B1
5) Internationalisation Options I1 *uncheck en_GB.UTF-8) check en_US.UTF-8 -> UTF-8 
5) Internationalisation Options T2 Timezone
5) Internationalisation Options T3 Keyboard layout 
9) Advanced Options A2 Hostname

3. Reboot the Pi
   reboot
4. Log back in
5. Update the Raspbian apt cache
   sudo apt-get update
6. Install all of the current updates
   sudo apt full-upgrade
7. By default Raspbian will boot into graphical mode. Since there is only 1GB of memory we need to conserve as much ram as possible. Execute the follow command to tell the Pi to boot into console mode.
   sudo systemctl set-default multi-user.target
8. Reboot the Pi again to use the latest kernel and to boot into console mode.
   reboot
9. The following directory is missing from the default Raspbian install that FOG uses, so we’ll create it so the installer doesn’t complain.
   sudo mkdir /usr/lib/systemd/system
10. Now we need to install a couple default packages not installed by Raspbian by default
    sudo apt-get update sudo apt-get install git bc
11. Now install FOG from the git repository
    sudo git clone https://github.com/FOGProject/fogproject.git /opt/fogproject

@PDQ If there were FOG specific questions posted in chat or asked where you deferred to the FOG Project, if you could repost them here. We will answer them where we can (maybe better idea another clean thread). This was a very lively session that touched on a lot of things.

Thank you for taking the time to set this up and give a great overview of how the best of FOG and the best of PDQ Deploy can work together.