Navigation

    FOG Project

    • Register
    • Login
    • Search
    • Recent
    • Unsolved
    • Tags
    • Popular
    • Users
    • Groups
    • Search
    1. Home
    2. george1421
    • Profile
    • Following
    • Followers
    • Topics
    • Posts
    • Best
    • Groups

    george1421

    @george1421

    Moderator

    2882
    Reputation
    12375
    Posts
    27680
    Profile views
    44
    Followers
    1
    Following
    Joined Last Online
    Location Western Michigan

    george1421 Follow
    Testers Moderator

    Best posts made by george1421

    • FOG Post install script for Win Driver injection

      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

      posted in Tutorials
      george1421
      george1421
    • The magical, mystical FOG post download script

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

      posted in Tutorials
      george1421
      george1421
    • RE: FOG broke my hard drive, why?

      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.

      posted in Bug Reports
      george1421
      george1421
    • RE: How does iPXE load fog files from the init.xz image

      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.

      posted in General
      george1421
      george1421
    • Deploying a single golden image to different hardware with FOG

      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.

      posted in Tutorials
      george1421
      george1421
    • Using FOG to PXE boot into your favorite installer images

      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)

      posted in Tutorials
      george1421
      george1421
    • Installing dnsmasq on your FOG server

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

      The quick steps are this.

      1. Remove the pxe boot information from your router.
      2. Install dnsmasq service from your linux distribution’s repo
      3. 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.
      4. Create a configuration file called ltsp.conf in /etc/dnsmasq.d directory.
      5. 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
      
      1. 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.
      2. Save and exit your text edit.
      3. Issue the following command to restart dnsmasq service sudo systemctl restart dnsmasq
      4. 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.
      5. Ensure that dnsmasq starts when the system is rebooting with sudo systemctl enable dnsmasq
      6. PXE boot a target computer.

      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

      posted in Tutorials
      george1421
      george1421
    • RE: OS drive SSD or SATA

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

      posted in Hardware Compatibility
      george1421
      george1421
    • Synology NAS as FOG Storage node

      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.

      posted in Tutorials
      george1421
      george1421
    • RE: master image with drivers

      @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

      posted in Windows Problems
      george1421
      george1421

    Latest posts made by george1421

    • RE: Persistent Groups - Snapins added to host but not deployed

      @tom-elliott said in Persistent Groups - Snapins added to host but not deployed:

      e host is joined to a group it should automatically deploy he snapins to the newly joined host?

      The short answer is, Yes.

      The bit longer answer is still, Yes.

      While I surely don’t need to repeat the concept of persistent groups to you, I’ll explain it for those who may find this thread in the future.

      The intent of a persistent group is to create a model/ideal/template host in FOG. That host may have specific kernels, inits, parameters, printers, snapins, etc. defined in that group. We might call that our baseline configuration for any new host we would add to that group.

      So lets expand this a bit, lets say we have 2 FOG Groups, Finance and Purchasing. Each department uses the same computer hardware, but have different application requirements and different local printers. Now lets say I’m staging a new computer for the Finance department. When FOG is done imaging the computer and doing any post install things via the FOG Client, I want that new computer to look exactly like the other computers in the Finance department with its baseline applications and default printers defined (just for full disclosure I don’t use the snapin or printer subsystems of FOG so I might overstate the capabilities of each). So when I’m running through the full registration, one of the questions the registration script asks is if I want to associate the host with a specific group. At this point I would say Finance, and proceed with imaging.

      With the current persistent group trigger, if the template host had Finance application snapins associated with the template host those associations would be copied over to the snapin association table like defined. But at the end of the imaging and FOG Client actions the applications would not be installed on the target computer. The snapin association was made, but the client was never told to install the software. This is the problem in the OP of this thread.

      We are missing the step to tell the FOG Client to install the associated snapins.

      Now with that said, I can also see a problem with this new approach in that its possible to deploy an already installed application to the same target host.

      Side note is that while the focus is on Snapins, the Printers module also suffers from the same condition in that the associations are created but the client is never told to do the install.

      posted in Feature Request
      george1421
      george1421
    • RE: Persistent Groups - Snapins added to host but not deployed

      @tom-elliott Thank you for the explanation. I took that info a new FOG install and a bit of reverse engineering and I found the bit I was missing.

      As I posted before this is the snapin section of the trigger that fires when a host is associated with a group.

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

      This does does for sure link the new host to the snapins associated with the template host. But what it doesn’t do (as the OP posted) deploy the snapin to the target computer.

      For that bit to work a new snapinJob must be scheduled and then a new snapinTask must be created for each snapin association that was just inserted.

      So this is (yet untested) code I’ve come up with to modify to the persistent group Trigger that replaces the code above

              SET @myDBTest = (SELECT count(`saSnapinID`) FROM `snapinAssoc` WHERE `saHostID`=@myTemplateID LIMIT 1);
              IF (@myDBTest > 0) THEN
                  INSERT INTO `snapinAssoc` (`saHostID`,`saSnapinID`)
                      SELECT @myHostID as `saHostID`,`saSnapinID` 
                      FROM `snapinAssoc` WHERE `saHostID`=@myTemplateID;
      
                  SET @sjDate = (SELECT NOW());
                  INSERT INTO `snapinJobs` (`sjHostID`,`sjStateID`,`sjCreateTime`)
                      SELECT @myHostID as `sjHostID`,1 as `sjStateID`,@sjDate as `sjCreateTime`;
      
                  SET @mysjID = (SELECT `sjID` FROM `snapinJobs` WHERE `sjCreateTime`=@sjDate);
                  INSERT INTO `snapinTasks` (`stJobID`,`stState`,`stCheckinDate`,`stSnapinID`)
                      SELECT @mysjID as `stJobID`, 1 as `stState`,@sjDate as `stCheckinDate`, `saSnapinID` as `stSnapinID`
                      FROM `snapinAssoc` WHERE `saHostID`=@myHostID;
              END IF
      
      

      I’ve run out of time at the moment to take this to finish, but I’ll get back to it a bit later tonight or tomorrow.

      posted in Feature Request
      george1421
      george1421
    • RE: FOG 1.5.9.57 on Debian 10 mysql root password is blank

      @tom-elliott I like that fog users a different user account for FOG db access. But I think the fog installer was programmed to either prompt for the root user ID to install FOG (because it needs initially root level access to create the fog database). I’m just noting that I noticed a change but its not clear if it is intentional or not. If the installer has been reverted back to not ask then that is the way is it, no problem.

      posted in Bug Reports
      george1421
      george1421
    • FOG 1.5.9.57 on Debian 10 mysql root password is blank

      I noticed when I installed 1.5.9.57 it never prompted me to enter a custom root password for mysql. I thought I just missed the question during the installation. While doing some reverse engineering I found that the root password for mysql was blank.

      posted in Bug Reports
      george1421
      george1421
    • RE: Changed IP, reinstalling not an option

      @boriquaboy115 The permission denied message is related to the certificates being used. I see you are using https so that means the certificate used to compile ipxe.efi and undionly.kpxe doesn’t match what the apache server is using.

      posted in FOG Problems
      george1421
      george1421
    • RE: HTTP ipxe boot setting?

      Edit the file /opt/fog.fogsettings and replace the IP address there.

      Then edit the /tftpboot/default.ipxe file

      in the fog settings and default storage node change the IP there.

      Finally rerun the fog installer once again to fix the rest of the bits.

      posted in FOG Problems
      george1421
      george1421
    • RE: Persistent Groups - Snapins added to host but not deployed

      @tom-elliott Tom thank you for the reply. From what I understand the snapin association is being made in the snapinassoc table. But what is not happening is a snapin task is never running to deploy the snapin to the target computer. I would think something is missing that is needed to kickoff the deployment. Or does the fog client do that.

      this is created by the host at the time a task is generated.

      After thinking about this for a bit. What tells the host to create these entries? I think that is the bit I’m missing. The association table links the host with the snapin, but something needs to trigger the host to deploy the snapin.

      posted in Feature Request
      george1421
      george1421
    • RE: Fog ProxyDHC with Fog and Pfsense on the same network

      @sckendall said in Fog ProxyDHC with Fog and Pfsense on the same network:

      Well, the question is whether it is possible to have two independent fog servers on the same network.

      Well this sentence changes everything.

      If you want to pxe boot on your laptop you will need an isolated network or if you are running a hypervisor on your laptop then you can create an internal network.

      I just think of an idea. Its possible if on your main FOG server, you create a custom FOG iPXE menu that links the fog server on your laptop. Then normal pxe booting to main fog server, then chain (ipxe command) to your FOG server. That is possible.

      posted in FOG Problems
      george1421
      george1421
    • RE: Fog ProxyDHC with Fog and Pfsense on the same network

      @sckendall said in Fog ProxyDHC with Fog and Pfsense on the same network:

      But can’t I keep them both running at the same time?

      Explain why you have doubt? At my home I have openwrt as my firewall and dnsmasq running on my FOG server(s) at the same time. No problems at all.

      posted in FOG Problems
      george1421
      george1421
    • RE: After being imaged, Win10 won't UEFI boot, will Legacy boot

      @mmarquis What you are saying is inconsistent with the way fog works.

      If you capture a uefi image and deploy it to another uefi image it will boot. FOG does not change the disk structure, like from uefi to bios. If you have to switch the target computer into bios (legacy) mode then your captured image was from a bios based computer. At the heart of it fog just moves partitions to raw data files on the fog server and then from the raw data files on the server to the new target computer. It doesn’t change the format of the media.

      FWIW uefi and bios partition tables are laid out differently.

      Just to add a layer of confusion here. The mode that image capture happens is not related to or has an impact on the target computer disk structure.

      For example I can have a UEFI computer and UEFI disk structure. I can boot the computer in bios mode and capture and deploy that UEFI disk as long as the target computer is configured for UEFI when it boot, it will see the hard drive and boot.

      posted in Windows Problems
      george1421
      george1421