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

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:

1. 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.
2. 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.
3. 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).

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.

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.

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.

@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.

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.

1. 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

2. 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

3. 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

4. Control Panel->File Services
   Select Win/Mac/NFS (tab)
   Checked Enable NFS

5. Control Panel->File Services
   Select FTP (tab)
   Checked Enable FTP service (no encryption)
   Checked Use the default port range

6. Control Panel->File Services
   Select TFTP (tab)
   Checked Enable TFTP service
   TFTP root folder: tftpboot (this is the share name we created above)

7. 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

8. 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.

@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

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

@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).

Are you using FOG as a backup server for DR reasons or do you plan on deploying this single 2012 image to many computers? I see a few flaws in your process if you are going to send that single 2012 server image to multiple systems. But lets first find out how you are going to use it.

BTW This isn’t specifically a FOG issue, but more of a windows issue. FOG is properly deploying the image to the target computer. It just may not be doing what you want and how you want it.

@juels said in Zyxel USG40 DHCP Pool:

Actually I don’t need dual NICs since the server is located in my department, so I can just access it when I need it.
I actually just want a FOG server and a 24port switch connected so I can connect my workstations for deployment, but what about dhcp then?

Well you do and you don’t. To install FOG the fog server needs to have internet access. BUT FOG gets cranky when you change its IP address after FOG is installed. So its best to have 2 network interfaces. One for management and internet access to install/upgrade FOG and one for imaging (if you want an isolated imaging network, not specifically required). If you have an isolated imaging network then you will need to configure the FOG server to be the dhcp server for the imaging network. Just understand the system’s imaged on the imaging network won’t have access to the rest of your network including the AD server if the target servers will connect to AD.

If you are concerned about network traffic AND as part of the imaging process your computers need to reach out of the isolated network you are better off not to use an isolated imaging network. You can modify your design a bit to plug the fog server and computers to be imaged on that 24 port switch, then plug that 24 port switch into your business network. All imaging will stay local to that 24 port switch but the clients that are imaged will be able to reach your business network servers and the internet if needed.

@juels said in Zyxel USG40 DHCP Pool:

But if I use dnsmasq do I need to put all 100+ workstations MAC-addresses in the dhcpd.conf? Or can dnsmasq automatically provide DHCP address for all 100+ machines? without giving them fixed addresses?

How dnsmasq works in this configuration is that it only supplies the pxe boot information. The main dhcp server provides all other settings. If you follow this tutorial exactly it should take you about 10 minutes to setup and start servicing your pxe booting. https://forums.fogproject.org/topic/12796/installing-dnsmasq-on-your-fog-server DNSMASQ will override any settings you have in dhcp for pxe booting.

You still haven’t explained the dual network bit. You will need to take precautions if you install dnsmasq on a linux server with 2 network interfaces. One of the 2 subnets will get the wrong boot information if dnsmasq is bound to both interfaces.

@juels

1 that’s used to access it from our local network 192.168.10.0 and 1 that has it’s completely own network like 10.0.0.0 or 192.168.0.0

What is your end goal here with 2 networks. Is one for management and one for an isolated imaging network? If so this is a common configuration.

But since i’m running the DHCP from our USG40 I just wanted to share the config of the DHCP pool and I want to see if any of you can spot if there is any issue

Share the dhcp between what? the business network and the isolated imaging network? If so, not possible.

a really good distro for FOG or FOG version please share you’re knowledge.

We see less problems with Centos 7 than Ubuntu. Bot FOG supports the big three the best with Centos, Ubuntu, and Debian.

i’m cloning is a Dell OptiPlex 3070

You will need to test the bleeding edge hardware to see if its compatible with the linux kernel that FOG uses. The FOG Project is dependent on the linux kernel developers to provide hardware support.

Also using your router, I will suspect that you will have issue supporting both bios and uefi systems seamlessly. Both hardware platforms require their own boot loader. For the bios systems you need to load undionly.kpxe and for uefi you will need ipxe.efi boot loaders. The static settings in most routers don’t support the dynamic boot file allocations. Not a problem because we can use dnsmasq to support dynamic booting between the firmware platforms.

Just to add a bit of detail to this issue.

The linux driver that comes with the stock linux kernel is insufficient to configure and use these new breed of realtek 8168 network adapters. Last fall I created a one off kernel with the updated linux drivers from the realtek web site. These updated realtek drivers seem to work better with these new nics than the stock 4.x kernel drivers.

I asked the OP to try the latest one off 5.5.3 stock linux kernel and that version also did not work with this realtek nic. I have not tried to patch the 5.x series kernels as of now with the updated realtek drivers as I did with the 4.19.x series.

key search term is bzImageRT

For now I had the OP change the global FOS boot kernel to bzImageRT in the fog configuration page. That way all systems will use this one-off kernel. The only changes from the base FOG kernel is that it has the updated realtek drivers.

ref: https://forums.fogproject.org/topic/14020/issues-with-realtek-rtl8168-and-4-19-48-kernel

@Dankau So how many hops (network switches) is the target computer away from the FOG server.

Did you capture your golden image from a lenovo desktop or is this the first time you are deploying to a physical machine?

If you setup a test image capture to this machine do you get the same chainloading error?

If you run the FOG hardware compatibility test from the iPXE menu, what are your results.

@Arrowtron Our goal with this step is to remove 2 settings from the compiled in default values for the db server.

To do that we need to add a configuration file into /etc/mysql/conf.d/ called sqlmode.cnf. Into that file add in the following:

[mysqld]
sql-mode="ONLY_FULL_GROUP_BY,STRICT_TRANS_TABLES,ERROR_FOR_DIVISION_BY_ZERO,NO_AUTO_CREATE_USER,NO_ENGINE_SUBSTITUTION"

Save that file and then restart the sql server with sudo systemctl restart mariadb You might have to adjust for your linux OS.

Once the sql server comes back online login with the mysql cli too and key in SELECT @@GLOBAL.sql_mode global, @@SESSION.sql_mode session;

With any luck the following settings will be gone.

+-------------------------------------------------------------------------------------------------------------------------------------------+-------------------------------------------------------------------------------------------------------------------------------------------+
| global                                                                                                                                    | session                                                                                                                                   |
+-------------------------------------------------------------------------------------------------------------------------------------------+-------------------------------------------------------------------------------------------------------------------------------------------+
| ONLY_FULL_GROUP_BY,STRICT_TRANS_TABLES,>>NO_ZERO_IN_DATE<<,>>NO_ZERO_DATE<<,ERROR_FOR_DIVISION_BY_ZERO,NO_AUTO_CREATE_USER,NO_ENGINE_SUBSTITUTION | ONLY_FULL_GROUP_BY,STRICT_TRANS_TABLES,NO_ZERO_IN_DATE,NO_ZERO_DATE,ERROR_FOR_DIVISION_BY_ZERO,NO_AUTO_CREATE_USER,NO_ENGINE_SUBSTITUTION |
+-------------------------------------------------------------------------------------------------------------------------------------------+-------------------------------------------------------------------------------------------------------------------------------------------+

If only those values are missing then lets continue with the alter database commands.

ALTER TABLE hosts ENGINE=InnoDB;
ALTER TABLE imagingLog ENGINE=InnoDB;
ALTER TABLE inventory ENGINE=InnoDB;
ALTER TABLE snapinTasks ENGINE=InnoDB;

SELECT TABLE_NAME,ENGINE
FROM information_schema.TABLES
WHERE TABLE_SCHEMA = 'fog' and ENGINE = 'MyISAM';

@Arrowtron ok i will follow up in about 30 minutes with a test we can try.

@kyokushin Look at the forum chat bubble for some additional hints.