• Recent
    • Unsolved
    • Tags
    • Popular
    • Users
    • Groups
    • Search
    • Register
    • Login
    1. Home
    2. george1421
    • Profile
    • Following 1
    • Followers 64
    • Topics 113
    • Posts 15,330
    • Best 2,777
    • Controversial 0
    • Groups 2

    george1421

    @george1421

    Moderator

    3.3k
    Reputation
    28.3k
    Profile views
    15.3k
    Posts
    64
    Followers
    1
    Following
    Joined Last Online
    Location Western Michigan

    george1421 Unfollow Follow
    Testers Moderator

    Best posts made by 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.

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

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

      Dhcp option 93 to hardware type table

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

      posted in Tutorials
      george1421G
      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
      george1421G
      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
      george1421G
      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)
      Paragon Hard Disk Manager
      Parted Magic version from May 2023

      posted in Tutorials
      george1421G
      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
      george1421G
      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
      george1421G
      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
      george1421G
      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
      george1421G
      george1421
    • RE: Expose FOG host and image properties to post install scripts

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

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

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

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

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

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

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

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

      <?php
      class SetHostName extends FOGBase {
          protected $macSimple;
          protected $newName;
          protected $oldName;
      
          public function __construct($check = false) {
              parent::__construct();
      
              self::stripAndDecode($_REQUEST);
              $this->macSimple = strtolower(str_replace(array(':','-'),':',substr($_REQUEST['mac'],0,20)));
              $this->newName = substr(trim($_REQUEST['newname']," \t\n\r\0"),0,20);
              $this->oldName = substr(trim($_REQUEST['oldname']," \t\n\r\0"),0,20);
      
              ob_start();
              header('Content-Type: text/plain');
              header('Connection: close');
      
              if ((strlen($this->newName) > 3) & (strlen($this->oldName) > 0)) {
                  $query = sprintf("UPDATE hosts JOIN hostMAC ON (hostMAC.hmHostID = hosts.hostID) SET hostName='%s' WHERE ( (hostMAC.hmMAC='%s') AND (hostName LIKE '%s') );", $this->newName, $this->macSimple, $this->oldName);
      
                  self::$DB->query($query);
                  echo "OK";
              } else {
                  echo "Fail";
              }
              flush();
              ob_flush();
              ob_end_flush();
          }
      }
      

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

      <?php
      class HostInfo extends FOGBase {
          protected $macSimple;
          protected $repFields = array(
              'hostName' => 'hostname',
              'hostDesc' => 'hostdesc',
              'imageOSID' => 'imageosid',
              'imagePath' => 'imagepath',
              'hostUseAD' => 'hostusead',
              'hostADDomain' => 'hostaddomain',
              'hostADOU' => 'hostadou',
              'hostProductKey' => 'hostproductkey',
              'iPrimaryUser' => 'primaryuser',
              'iOtherTag' => 'othertag',
              'iOtherTag1' => 'othertag1',
              'lName' => 'location',
              'iSysman' => 'sysman',
              'iSysproduct' => 'sysproduct',
              'iSysserial' => 'sysserial',
              'iMbman' => 'mbman',
              'iMbserial' => 'mbserial',
              'iMbasset' => 'mbasset',
              'iMbproductname' => 'mbproductname',
              'iCaseman' => 'caseman',
              'iCaseserial' => 'caseserial',
              'iCaseasset' => 'caseasset',
          );
      
          public function __construct($check = false) {
              parent::__construct();
      
              self::stripAndDecode($_REQUEST);
              $this->macSimple = strtolower(str_replace(array(':','-'),':',substr($_REQUEST['mac'],0,20)));
      
              $query = sprintf("SELECT hostName,hostDesc,imageOSID,imagePath,hostUseAD,hostADDomain,hostADOU,hostProductKey,iPrimaryUser,iOtherTag,iOtherTag1,lName,iSysman,iSysproduct,iSysserial,iMbman,iMbserial,iMbasset,iMbproductname,iCaseman,iCaseserial,iCaseasset FROM (((hostMAC INNER JOIN (hosts LEFT JOIN images ON hosts.hostImage = images.imageID) ON hostMAC.hmHostID = hosts.hostID) LEFT JOIN inventory ON hosts.hostID = inventory.iHostID) LEFT JOIN locationAssoc ON hosts.hostID = locationAssoc.laHostID) LEFT JOIN location ON locationAssoc.laLocationID = location.lID WHERE (hostMAC.hmMAC='%s');", $this->macSimple);
      
              $tmp = (array)self::$DB->query($query)->fetch('','fetch_all')->get();
      
              ob_start();
              header('Content-Type: text/plain');
              header('Connection: close');
      
              foreach ((array)$tmp AS $i => &$DataRow) {
                  foreach ((array)$DataRow AS $j => &$DataField) {
                      echo  "export " . $this->repFields[$j] . "=\"" . $DataField . "\"\n";
                      unset($DataField);
                  }
                  unset($DataRow);
              };
              flush();
              ob_flush();
              ob_end_flush();
          }
      }
      

      And finally the post install bits

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

      . ${postdownpath}fog.hostinfo
      

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

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

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

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

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

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

      posted in Feature Request
      george1421G
      george1421
    • When DHCP-PXE booting process goes bad and you have no clue

      Sometimes when we can’t understand why the pxe booting process is going sideways and we’ve touched on the common causes, the easiest solution is to setup the FOG server to eavesdrop on the dhcp setup process between the dhcp server and pxe booting client.

      This process will work perfectly if the fog server, dhcp server, and pxe booting client are in the same broadcast domain (IP subnet, network, vlan). It will work if your fog server and pxe booting client are on the same subnet too, its just not as clean of a trace. And the last way to achieve this is to use a second computer running wireshark on the same subnet as the pxe booting computer. Setting up the wireshark filters are similar to the tcpdump filters, but that is a bit beyond the scope of this tutorial.

      This is going to be a pretty low impact test. We just want to capture a packet trace of the pxe booting process to the error.

      First a little background. The DHCP protocol is broadcast based. That means that discovery, offer, request and ack are all sent as broadcast messages (because the client doesn’t have an IP address during this process). Knowing this fact we can eavesdrop on the communication between the dhcp server and pxe client with the FOG server as long as all three are in the same broadcast domain, subnet, vlan, etc.

      So what we need to do is this:

      1. Install tcpdump on your FOG server from your linux distributions repository.
      2. Start tcpdump on the FOG server’s linux console with this command tcpdump -w output.pcap port 67 or port 68 or port 69 or port 4011
      3. PXE boot the target computer until you see the error or the FOG iPXE menu
      4. Wait about 5 seconds then hit ctrl-C on the FOG server’s linux console.
      5. You can review the pcap with Wireshark or upload it to a developer/moderator for their review.

      Just a quick sidebar: We are telling tcpdump to write the output of the packet capture to output.pcap. And we have setup some filters because we only care about dhcp (port 67 and 68), tftp (port 69), and dhcpProxy (4011). One thing you should do is keep the time when you start tcpdump and start the pxe boot process on the client as short as possible. Because if you have a busy dhcp network we may key in on the wrong dhcp boot process. So you want to start tcpdump and then right away start the target pxe booting.

      posted in Tutorials
      george1421G
      george1421

    Latest posts made by george1421

    • RE: Deploying FOG in a Secure‑Boot‑Mandated UEFI Environment

      @Aaexy said in Deploying FOG in a Secure‑Boot‑Mandated UEFI Environment:

      Secure Boot policy Must remain enabled at all times; only Microsoft‑signed keys are in the firmware (no option to enrol custom keys).

      If this is the case there is nothing you can do with FOG. You will need to get the ipxe kernel (ipxe.efi / snp.efi) and bzImage signed with the microsoft keys so they can boot in your environment. While this pains me to say, you would probably be better off with a different imaging solution than FOG.

      posted in FOG Problems
      george1421G
      george1421
    • RE: UEFI Boot - Kernel panic: Unable to mount root fs on /dev/ram0

      @mbghost said in UEFI Boot - Kernel panic: Unable to mount root fs on /dev/ram0:

      I disabled Snooping

      If that was dhcp snooping I can see where it might be causing a problem. If that’s igmp snooping then for multicasting you want that enabled.

      @mbghost said in UEFI Boot - Kernel panic: Unable to mount root fs on /dev/ram0:

      But when I try to create an image from the FOG web console and capture image, it breaks everything. I get the same error on all device

      Mind including the error you are seeing? It would be helpful to include a screen shot or picture of the error so we can see the context of the error too.

      posted in FOG Problems
      george1421G
      george1421
    • RE: UEFI Boot - Kernel panic: Unable to mount root fs on /dev/ram0

      @mbghost If the network test doesn’t work then lets focus in on that toshiba all in one. Lets identify the hardware components since it seems to be the focus of the problem. First do the easy stuff.

      posted in FOG Problems
      george1421G
      george1421
    • RE: UEFI Boot - Kernel panic: Unable to mount root fs on /dev/ram0

      @mbghost I’m still leaning towards init.xz corruption. Its very strange that on a fresh fog sever it works on day one and then the next its no good.

      Just for clarification its all and every Toshiba all in ones but other models work just fine? Its only this specific model.

      What I’m thinking at the moment is that bzImage transfers fine and its around 8MB in size. The kernel also boots fine because its getting to the point where it attempts to connect to the root file system.

      init.xz is a zstd compressed image. Its compressed size is around 350MB. Both images are very small in size. Something is happening to the init.xz image to where bzImage is not able to mount it and the kernel panics.

      This image persists across multiple deployments and multiple installs of FOG server. It also crosses different init.xz and bzImage kernels.

      FOS linux does boot 1 out of 12 attempts.

      So where could the problem hide?

      1. The FOG server hardware if that was a consistent deployment throughout the server rebuilds. (test try building fog server on a desktop/laptop computer to rule out fog server infrastructure)
      2. Something with the network between the fog server and the target computer. (move target computer as physically close to fog server as possible and test deployments eliminating all of the existing networking between fog server and target computer)
      3. Something with the target computer. (if you have been testing with the same computer throughout these tests use a different computer. Its possible there is a ram issue with this computer)

      Right now there isn’t a clear picture on the cause. I can say this IS unique and I’ve haven’t seen this before with FOG.

      Something else you might do is in the fog settings, set the log level to 7. I think the default is 4. 7 is verbose and the kernel might spit out more information to why its not happy with the init.xz file. Like decompression failed.

      posted in FOG Problems
      george1421G
      george1421
    • RE: UEFI Boot - Kernel panic: Unable to mount root fs on /dev/ram0

      @mbghost This error message baffles me. If its happening where I think its happening its not a pxe boot issue. This error happens after you pick an iPXE menu item or if you tell a computer to image.

      So you can probably rule out ipxe.efi/snp.efi here.

      This error message is generated with FOS linux is booting. The kernel has booted and when it goes to connect to init.xz the format of init.xz is corrupt for some reason.

      What version of FOG are you running
      What version of “the kernel” are you running?
      What version of init.xz are you running (get this from a bios computer that boots. the version of the init will be under the fog logo)

      What computer is this happening on (make and model)?
      Is it all uefi systems or only from one manufacture?
      How much ram does this computer have?
      Are you seeing both bzImage and init.xz get transferred completely to the target machine. This will be visible just after you pick an item on the FOG iPXE menu.

      To me this error is telling me something is wrong with init.xz or for some reason bzImage is not the right kernel for init.xz

      posted in FOG Problems
      george1421G
      george1421
    • RE: Unable to Get IP Address After PXE Menu on Physical PC (FOG Project on ESXi)

      @mbghost said in Unable to Get IP Address After PXE Menu on Physical PC (FOG Project on ESXi):

      ESXi server → Cisco Switch → Client.

      So just to be clear pxe boot the vm on esxi works no prob, but physical host does not.

      Lets test this, on the target computer, put one of those cheap unmanaged switches (like the $20 monoprice ones) between the pxe booting computer and the building network switch. Now try to pxe boot. If it works then get with your networking group and make sure the switch ports are configured for portfast, because its spanning tree causing you some troubles. Understand this is an educated guess based on what you’ve posted.

      Just for some background on this, standard spanning tree takes 27 seconds to start forwarding traffic. FOS Linux boots in under 15 seconds, so its already given up trying to get an IP address by the time spanning tree starts forwarding data.

      posted in FOG Problems
      george1421G
      george1421
    • RE: Help needed for multiple Ubuntu desktops deployment

      @uzee FOG doesn’t change or really step into the target system during deployment. You CAN do this if you write a post install script that will get called once the target image is deployed to the target computer. In the case of a linux computer you could potentially set the target computer’s name here by updating the /etc/hostname file or anything else you can do with a bash script. The FOG Client can also be configured to make changes to the target computer or install applications based on instructions from the fog server. Its really identifying what you want to do and how much automation you want to script. Its all possible with FOG and a little creativity on your end. Since you already know Ubuntu (linux) bending FOG to what you want will be easier than coming strictly from a MS Windows background.

      posted in FOG Problems
      george1421G
      george1421
    • RE: Help needed for multiple Ubuntu desktops deployment

      @uzee Your approach to this (imaging) really depends on your short term and long term goals.

      If imaging these machines are just a one time time (like if you were a PC reseller) then there is a process I call load and go. where you pxe boot one time into the FOG iPXE menu and then issue a Deploy Image from the FOG iPXE menu. This will deploy the target image to the target computer one time and then the FOG server will forget about the computer. Again you would use this method if you were going to stuff an OS onto some hardware and then never see that target computer again.

      The other method is the traditional registration, assign an image and then schedule an image deployment. In this case the FOG server will register and know about the target computer in the future. You have to remember though that you register the target computer once and then can deploy many times. Future remote imaging will be possible because you register the target computer with FOG. FOG also gives you the ability to manage the computers in the future if you install the FOG Client.

      Now with this registration and then booting. The registration process must be hands on, but imaging can be touch less or at least low touch. Some people will have the target computer configured so that it always pxe boots. In this case the target computer will always pxe boot through the fog ipxe menu. The default action if you don’t touch the computer will be to boot the OS off the hard drive. This boot through the iPXE menu, will also check to see if the fog server has any tasks assigned for the target computer. If there is a task assigned (like reimage the computer) then instead of booting through to the local hard drive, it will boot into imaging. If you couple that with the fog client install on the target coputer’s host OS. When you schedule a deployment to the computer, the fog client will then reboot the computer and then the bios is configured to boot through the fog menu, the target computer will be reimaged without requiring a tech to touch the computer. You would use this process to maybe reset a computer lab between classes, where you can wipe the target computer and then reload the OS on 30 computers in 10 minutes.

      The interrupt the booting process twice, is actually pressing F12 to get into the firmware’s boot menu to pick PXE booting. You are not changing the forever boot order, you are just picking one time pxe boot. Yes you will have to do that twice, but this way the default boot is always the hard drive.

      posted in FOG Problems
      george1421G
      george1421
    • RE: No Network Interfaces Found Error

      @Ryxn I checked and that nic has been in the linux kernel for several years.

      And secondly when you checked for missing firmware the kernel wasn’t complaining about missing something.

      Its a good thing you were able to get the error while in debug mode. Because that was going to be the next quest for you. To get the system when its behaving badly.

      So when you get it into debug mode and its complaining about no nic lets do the following.

      ip a s should show if the network interface has an ip address, I’m going to suspect no because it complained about it earlier in the boot process.

      lspci -k -nn | more Look through this list until you find the entry. The number in the square brackets will be what you posted earlier. [8086&1502]. See if the nic is visible to the kernel. AND if it is it should mention what kernel driver its using. I’ll give you a for example using my laptop.

      0000:00:1f.6 Ethernet controller [0200]: Intel Corporation Ethernet Connection (
      13) I219-V [8086:15fc] (rev 20)
      	Subsystem: Dell Ethernet Connection (13) I219-V [1028:0a22]
      	Kernel driver in use: e1000e
      	Kernel modules: e1000e
      
      

      lastly if everything looks good, kernel sees the nic, there is a kernel driver assigned. Lets see if time fixes your problem.

      When you ran the ip a s command it listed all of the network interfaces and if it has IP addresses. You will need to know the interface name for your network adapter. It may be something like eno1 or ens192, or something else. Get that device name.

      Now run this command /sbin/udhcpc -i $iface --now replacing the whole word $iface with the device name listed from the ip command. This will tell the network adapter to again poll for an IP address from your dhcp server. If it picks up an IP address this time, then time does solve your problem and you will need to look into your network configuration and make sure that port-fast or fast-stp is enabled on your network port.

      posted in FOG Problems
      george1421G
      george1421
    • RE: Image Replication Issues

      @ProfessorFow OK what I want you to do is on the master node, go into the storage group where this remote node is. Look at this remote node. There should be a ftp user ID and password listed there (said from memory). Use those credentials to connect like you did with the ftp CLI from the master node to the remote node. See if you can login using ftp to the remote node. Then issue a ls command, Its not important what the answer is as long as it gives you an answer and not an error.

      If you can’t login using those credentials then on the remote storage node look at the /opt/fog directory. There is a hidden file called .fogsettings. issue the command cat /opt/fog/.fogsettings In that file should be the password for the account used when the fog server was installed. Make sure they match what is on the master node.

      There is something with ftp that is not working correctly, that is why the replication is not happening.

      posted in FOG Problems
      george1421G
      george1421