• New FOG Testing dashboard. Feedback?

    This link is the original fog testing dashboard.
    This dashboard was created to help identify problems with the FOG installation process early on, so they can be fixed before users experience them. This dashboard has been generally UP for about two years now. It’s served the FOG Project well.

    However, the old dashboard was written mostly in BASH and is a mess. It requires custom setup, custom snapshots, hand-spun virtual machines, and a tremendous amount of compute resources and time. While the code that this dashboard uses is completely open source and available, due to the complex setup, nobody has bothered using it.

    Thank you, old dashboard, You’re retirement party is coming up soon.

    Hello new dashboard!

    The new dashboard has several significant improvements over the old one. Notably:

    • Mostly written in Python.
    • 100% AWS based.
    • 100% of the infrastructure is built via Terraform.
    • Includes Red Hat Enterprise Linux 7 testing.
    • Orders of magnitude faster to run.
    • Makes logs available regardless of success status.
    • New logs, and output - such as stdout from the fog installer, patching stdout, and php-fpm logs.

    The new code base has been made available for all here and includes instructions for you to set this up for yourself, should you decide to run the FOG Installer tests yourself.

    Features that existed in the old dashboard but were done away with (for now) are:

    • Streak counts
    • Log history.
    • FogProject slack channel posts.
    • Older OSs.

    I plan to make testing history available in the future.

    For a while, I plan to run the old tests and new tests in parallel until I’m sure the new tests are stable, bug free, and ready to be relied on. Then, the old tests will be shut down for good.

    posted in General
  • RE: Bandwidth line colors posted in General
  • RE: How do you re-compress an image file?

    You need to recapture. Preferably to a new image so that if something goes wrong, you still have the old one.

    posted in General
  • RE: Bandwidth line colors

    @The-Dealman I don’t think it’s currently possible through the web UI. Of course you could take a stab at modifying the code so that certain things are certain colors.

    posted in General
  • RE: PXE-E23: client recieved tftp error from server (linux)

    @chanstag Your picture is interesting, in that after ipxe.efi there is an unprintable character shown as a block character. Make sure there isn’t any spaces or other junk after .efi in your router’s configuration.

    It is also safe to assume the fog server is at

    If after checking your router settings and still are not having luck, we’ll get a pcap of the pxe booting process and look at what is flying down the network wires.

    posted in FOG Problems
  • RE: Fog Replication

    @The-Dealman The replicator is pretty simple in that it should be a sequential replication node by node. If I remember correctly the images are replicated based on their image ID sequence and not by image name. You can prove this out by looking at the fog replicator log. There will be a master replicator log and then one log per storage node.

    posted in General
  • RE: How do you re-compress an image file?

    @Pistachio said in How do you re-compress an image file?:

    We’ve captured an image with “6” level of compression and we want to compress it further using “18”. Do we need to recapture or just update the compression level via the web GUI?

    If you want to take advantage of the higher compression index (i.e. to get a reduce disk space footprint on your FOG server), you need to recapture your image. I would also suggest that you switch over to the zstd compressor with an index of 11 to start. The zstd compressor (in opposition to gzip), is slower on the compression side, but much faster on the decompression side than gzip. Consider that you typically compress the image one and decompress it many times. Personally I can live with a slower image capture once than many image deployments. I can tell you in my environment I can deploy a 25GB image in about 4 minutes.

    posted in General
  • RE: Questions about how FOG is Working

    @langerwo said in Questions about how FOG is Working:

    Hardware/Software inventory ( i think there is no software inventory)

    Hardware inventory is done either through the registration process of a new computer, or via the fog client service that gets installed in your golden image prior to capture. There is no software inventory. If you need this kind of information then you need to use a third party tool like PDQ Inventory, OCS, Spiceworks Desktop, etc.

    software deployment

    Software deployment is done by creating what FOG calls snap-in packages. These are deployment packages picked up by the FOG client service running on the deployed computers. Or you can use a tool like PDQ Deploy

    unattend installation

    This is a function of your target system OS. FOG does’t care about OOBE or kickstart operations of the target OS. If you are talking about MS Window, then you will need to build a golden image, sysprep it, capture with FOG and then deploy with FOG.

    i know for the unattend i need a prepared Image and the Software deployment works with some kind of plungins

    Again if we are talking about MS Windows, you need to build your golden image in Audit mode, or use Microsoft Deployment Toolkit (MDT) to create your golden image with all of the windows updates and applications installed. There is no fog plugin to do this, FOG is an image cloning tool.

    but how is the Hardware inventory working? is there a PXE image loaded? And whats inside?

    FOG uses the PXE process to transfer the FOS (Fog Operating System) to the target computer to capture and deploy images. FOS is a highly customized linux operating system built specifically for image capture and deploying withing the FOG environment.

    posted in General
  • RE: How do you re-compress an image file?

    @Pistachio I’m not sure I totally understand your question, but let me tell you how fog works.

    There are two elements to a fog image. The first is the meta data that is stored in the database. This describes the image. The second is the raw image files stored in /images/<image_name> directory. If you update the meta data then only the database record is changed. If you recapture an image then the raw data files are updated.

    Now you have to be careful if you change certain meta data that describes the information contained in the raw image. For example if you captured an image using gzip partclone and then change it to something else or change the format from single disk non-resizable to single disk resizable you will have issues. Because the actual image files will not match what the meta data is telling it to do during deployment.

    There are some meta data that if changed will not have an impact on an already captured image like compression index. That value is only used when the image is captured. On deployment the fog image decompressor just decompresses what has already be compressed it doesn’t care about the compression ratio.

    posted in General
  • RE: PXE-E23: client recieved tftp error from server (linux)

    When you see NBP in the pxe boot loader that tells us your target computer is in UEFI mode, the error picture indicates you are sending undionly.kpxe to the target computer. Undionly,kpxe is a bios mode boot loader. For a UEFI system you need to send ipxe.efi boot loader. From the screen shot of your router’s dhcp settings it appears that it doesn’t support dynamic pxe boot file names. In that it will send a bios boot loader name for a bios system and a uefi boot loader name for a uefi base system.

    posted in FOG Problems