• Recent
    • Unsolved
    • Tags
    • Popular
    • Users
    • Groups
    • Search
    • Register
    • Login
    1. Home
    2. Tom Elliott
    3. Posts
    • Profile
    • Following 27
    • Followers 83
    • Topics 140
    • Posts 19,330
    • Groups 0

    Posts

    Recent Best Controversial
    • RE: Fog 1.6.14 Driver Replication Issue

      @FlareImp That message is a warning, not a failure. The install continues past it. It does not affect replication.

      1.6 lets a storage node ask the main server for a web certificate signed by the main server’s CA. The CA permits only names in the main server’s own domain. Your main server is named tv-fog-main with no domain, so no node name fits, and the main server declines. The node then keeps its own self-signed certificate. That is what storage nodes have always used, and the installer prints “Skipped” and says so on the next lines.

      You do not need to do anything about it. Continue with the update on the other nodes. When all servers run dev-branch, enable the replicators on the storage nodes again and check one cycle of /opt/fog/log/fogreplicator.log on N01. It should now say “This is not the master node” instead of “We are node ID: 1”.

      posted in FOG Problems
      Tom ElliottT
      Tom Elliott
    • RE: Fog 1.6.14 Driver Replication Issue

      @FlareImp A correction to my last post: the fix is already in dev-branch. You do not need to wait for the next release. To use it now, update the main server and every storage node from dev-branch:

      cd /path/to/your/fogproject/checkout
      git fetch
      git checkout dev-branch
      git pull
      cd bin
      sudo ./installfog.sh -y
      

      Update every server, because the bug is on each node. After all of them run the new version, you can enable the replicators on the storage nodes again.

      posted in FOG Problems
      Tom ElliottT
      Tom Elliott
    • RE: Fog 1.6.14 Driver Replication Issue

      @FlareImp Thanks, that log shows the cause. Every cycle on TVNE-Fog-N01 starts with:

      We are node ID: 1. We are node name: TV-Fog-Main
      

      So N01 runs replication as if it were your main server. N01 has short copies of the large files, and every hour it pushes them to TVAE-Fog and TVNE-Fog. For example, it sends d1p3.img at 1323409736 bytes over the full 22556692664 byte file. That is the copy you saw, and that is why both nodes show the same short sizes. Your main server then deletes the short file and starts again, and the cycle repeats.

      This is a bug in 1.6. Each FOG server adds the FOG_WEB_HOST address (your main server) to the list of its own addresses. So every storage node matches the main server’s storage node entry and acts as the main server. 1.5 does not do this, which is why 1.5 replicated correctly. The fix is done and will be in the next release.

      The same bug explains the files that vanished during your rsync. A server that acts as the main server deletes each file on the other nodes that it does not have itself. While the rsync ran, N01 did not yet have the Win11_25H2_Smart26 files. So N01’s replicator deleted them on TVNE-Fog. To confirm, look in /opt/fog/log/fogreplicator.log on N01 for “File does not exist on master node, deleting” lines that name TVNE-Fog.

      Until the fix is released, stop the replicators on every storage node, but not on the main server:

      sudo systemctl stop FOGImageReplicator FOGSnapinReplicator
      sudo systemctl disable FOGImageReplicator FOGSnapinReplicator
      

      Run that on TVAE-Fog, TVNE-Fog and all four N01/N02 nodes before you copy anything else. Then start the replicator on the main server. It replaces the short and missing files on TVAE-Fog and TVNE-Fog, Win11_25H2_Smart26 included, on its next cycles. Leave N01 and N02 disabled in Storage Management until the fix is out, because their copies are short too.

      posted in FOG Problems
      Tom ElliottT
      Tom Elliott
    • RE: Fog 1.6.14 Driver Replication Issue

      @FlareImp Thanks. The main server has the full file (1692345974 bytes). The node tvne-fog has a short copy (1558966032 bytes), and the log shows that same short size every hour. A copy that is still running would show a different size each time. So something writes the same short file to the node again and again.

      The copy you saw from the other node is the likely source. Only a node marked as master runs replication. A master sends to every other enabled node in its own storage group, even to another master. If that node is also marked master and has a short copy of the file, it overwrites the copy on tvne-fog each cycle.

      Can you check these:

      • Storage Management: list each storage node, its storage group, and whether “Is Master Node” is checked.
      • On the node you saw copying: ls -l /images/Drivers/Latitude3500/win11/
      • On the same node: the top of /opt/fog/log/fogreplicator.log for one cycle. It shows which nodes that node sends to.

      If that node is a master in the same group as tvne-fog, uncheck “Is Master Node” on it. A storage group must have only one master.

      posted in FOG Problems
      Tom ElliottT
      Tom Elliott
    • RE: Fog 1.6.14 Driver Replication Issue

      @FlareImp Thanks, that copy in the other direction is a good clue. The log shows two separate problems.

      1. A file name with a space is never seen on the storage node. For example, “7450 AIO-WIN11-A10-YHP57.CAB” shows a size of 0 on the node every cycle, so the replicator deletes it and copies it again. This is a bug in how FOG reads the node’s FTP listing, and a fix is on the way. Until then, renaming those files without spaces stops the loop for them.

      2. Files without a space, such as win11/3500-win11-A00-YH77C.CAB, show the same smaller size on both nodes every hour. A copy from the other node back toward your main server would explain that. Each storage group’s master sends an image to the other groups only when its own group is that image’s primary group. If another group’s master also sends the image, the two copies overwrite each other.

      Can you check these for one affected image, such as Drivers_Latitude3500:

      • Image Management > Drivers_Latitude3500 > Storage Groups tab: which group is marked primary?
      • Storage Management: for each storage group, which node is the master? Is the node you saw copying marked as a master?
      • ls -l /images/Drivers/Latitude3500/win11/ on the main server and on that node.
      posted in FOG Problems
      Tom ElliottT
      Tom Elliott
    • RE: Fog 1.6.14 Driver Replication Issue

      @FlareImp Thanks, the log shows the cause. 1.6.0.14 has a replication bug: the check for a transfer that is still running never matched. So each cycle compared the files while lftp was still copying them. It saw the half-copied file on the node, logged “File size mismatch”, deleted it, and started the copy again. A large file over your rate-limited link never finished. That is why rsync worked and the replicator did not.

      1.6.0.158 fixes this. Please update the master and every storage node to 1.6.0.158, then turn the replicator back on.

      The “File does not exist win11” lines are the subfolder name, not a missing file. 1.5 logs the same lines. They make lftp run once per cycle, but it copies nothing when the files already match.

      posted in FOG Problems
      Tom ElliottT
      Tom Elliott
    • RE: Using FOG Postinstall scripts for Windows Driver injection 2017 ed.

      I just wanted to add some updates as 1.6 being released and with advent of Win 11 now.

      Wanted to have more capable set of scripts here. I know the thread is very old, but it’s still worth the update in my book.

      /images/postdownloadscripts/fog.postdownload

      #!/bin/bash
      . /usr/share/fog/lib/funcs.sh
      [[ -z $postdownpath ]] && postdownpath="/images/postdownloadscripts/"
      # FOS sets osClass from the image's OS (determineOS, FOS 20261110 or later).
      # On an older FOS kernel osClass is empty, so derive it from the osid.
      if [[ -z $osClass ]]; then
          case $osid in
              5|6|7) osClass="win7" ;;
              9|10|11) osClass="winmodern" ;;
          esac
      fi
      case $osClass in
          win7|winmodern)
              clear
              [[ ! -d /ntfs ]] && mkdir -p /ntfs
              getHardDisk
              if [[ -z $hd ]]; then
                  handleError "Could not find hdd to use"
              fi
              getPartitions $hd
              for part in $parts; do
                  umount /ntfs >/dev/null 2>&1
                  fsTypeSetting "$part"
                  case $fstype in
                      ntfs)
                          dots "Testing partition $part"
                          ntfs-3g -o force,rw $part /ntfs
                          ntfsstatus="$?"
                          if [[ ! $ntfsstatus -eq 0 ]]; then
                              echo "Skipped"
                              continue
                          fi
                          if [[ ! -d /ntfs/windows && ! -d /ntfs/Windows && ! -d /ntfs/WINDOWS ]]; then
                              echo "Not found"
                              umount /ntfs >/dev/null 2>&1
                              continue
                          fi
                          echo "Success"
                          break
                          ;;
                      *)
                          echo " * Partition $part not NTFS filesystem"
                          ;;
                  esac
              done
              if [[ ! $ntfsstatus -eq 0 ]]; then
                  echo "Failed"
                  debugPause
                  handleError "Failed to mount $part ($0)\n    Args: $*"
              fi
              echo "Done"
              debugPause
              . ${postdownpath}fog.copydrivers
              # . ${postdownpath}fog.updateunattend
              umount /ntfs
              ;;
          *)
              echo "Non-Windows Deployment"
              debugPause
              return
              ;;
      esac
      

      /images/postdownloadscripts/fog.copydrivers

      #!/bin/bash
      ceol=`tput el`;
      manu=`dmidecode -s system-manufacturer`;
      dots "Identifying hardware"
      case $manu in
          [Ll][Ee][Nn][Oo][Vv][Oo])
              machine=$(dmidecode -s system-version)
              ;;
          *I[Nn][Tt][Ee][Ll]*)
              # For the Intel NUC and intel mobo pick up the system type from the
              # baseboard product name
              machine=$(dmidecode -s baseboard-product-name)
              ;;
          *)
              # Dell and everything else
              machine=$(dmidecode -s system-product-name)
              ;;
      esac
      
      # if the machine isn't identified then no need to continue with this script, just return to caller
      if [[ -z $machine ]]; then
          echo "Unable to identify the hardware for manufacturer ${manu}";
          debugPause;
          return;
      fi
      echo "${machine} Identified";
      
      # Remove spaces from the machine name, works better with path definitions
      machine="${machine//[[:space:]]/}"
      
      dots "Verifying we've found the OS disk"
      if [[ ! -d /ntfs/windows && ! -d /ntfs/Windows && ! -d /ntfs/WINDOWS ]]; then
          echo "! OS root Not found !";
          debugPause
          return;
      fi
      echo "Found";
      
      dots "Verifying target Arch"
      system64="/ntfs/Windows/SysWOW64/"
      [[ ! -d $system64 ]] && arch="x86" || arch="x64"
      echo "${arch} found";
      
      debugPause
      
      # Build the OS folder name from osname, which FOS sets from the image's OS.
      # "Windows 10" becomes win10, "Windows 8.1" becomes win8.1, "Windows 11"
      # becomes win11. So the folder names from the old osid table still match.
      osn="${osname,,}"
      osn="${osn//[[:space:]()]/}"
      osn="${osn/windows/win}"
      
      dots "Preparing Drivers"
      clientdriverpath="/ntfs/Drivers"
      remotedriverpath="/images/drivers/$machine/$osn/$arch"
      
      debugPause
      
      if [[ ! -d "${remotedriverpath}" ]]; then
          echo "failed";
          echo " ! Driver package not found for ${machine}/$osn/$arch ! ";
          debugPause;
          return;
      fi
      echo "Ready";
      
      debugPause
      
      [[ ! -d $clientdriverpath ]] && mkdir -p "$clientdriverpath" >/dev/null 2>&1
      echo -n "In Progress"
      
      rsync -aqz "$remotedriverpath" "$clientdriverpath" >/dev/null 2>&1
      
      [[ ! $? -eq 0 ]] && handleError "Failed to download driver information for [$machine/$osn/$arch]"
      
      debugPause
      
      # Windows 7, 8 and 8.1 only. Windows 10 and later read the OEM driver path
      # from the unattend.xml, so they skip the registry edit.
      [[ $osClass != win7 ]] && return
      
      regfile="/ntfs/Windows/System32/config/SOFTWARE"
      key="\Microsoft\Windows\CurrentVersion\DevicePath"
      devpath="%SystemRoot%\DRV;%SystemRoot%\inf;";
      reged -e "$regfile" &>/dev/null <<EOFREG
      ed $key
      $devpath
      q
      y
      EOFREG
      

      /images/postdownloadscripts/fog.updateunattend

      #!/bin/bash
      # Sets the computer name and, for a host with "Join Domain" on, the domain
      # join in the deployed image's unattend.xml. fog.postdownload sources this
      # file with the Windows partition mounted on /ntfs.
      #
      # FOG sends these from the host record (service/hostinfo.php):
      #   hostname                      the host name
      #   hostusead                     1 when "Join Domain after deploy" is on
      #   hostaddomain, hostadou        the domain and the OU
      #   hostaduser, hostadpass        the join account and its password
      # hostadpass is empty unless FOG Configuration > FOG Settings >
      # FOG_HOSTKEY_ALLOWED_SOURCES lists the imaging network. The FOG Agent,
      # and the older FOG Client, join the domain without writing the password
      # to disk. Use this only where neither is installed.
      
      # Escape a value for XML text, then for the right side of a sed s|||.
      # The quoted replacements stop bash 5.2 from reading & as "the match".
      xmlEscape() {
          local s="$1"
          s="${s//&/'&amp;'}"
          s="${s//</'&lt;'}"
          s="${s//>/'&gt;'}"
          s="${s//\"/'&quot;'}"
          s="${s//\'/'&apos;'}"
          printf '%s' "$s"
      }
      sedEscape() {
          local s="$1"
          s="${s//\\/'\\'}"
          s="${s//|/'\|'}"
          s="${s//&/'\&'}"
          printf '%s' "$s"
      }
      xmlValue() {
          sedEscape "$(xmlEscape "$1")"
      }
      
      # The places Windows Setup reads an unattend.xml from after sysprep. The
      # [x] in each name makes it a glob, so nocaseglob matches any case of it.
      shopt -s nocaseglob nullglob
      unattends=(
          /ntfs/[w]indows/[p]anther/[u]nattend.xml
          /ntfs/[w]indows/[p]anther/[u]nattend/[u]nattend.xml
          /ntfs/[w]indows/[s]ystem32/[s]ysprep/[u]nattend.xml
          /ntfs/[u]nattend.xml
      )
      shopt -u nocaseglob nullglob
      if [[ ${#unattends[@]} -eq 0 ]]; then
          echo " * No unattend.xml found, skipping"
          debugPause
          return
      fi
      
      # A PXE boot does not carry the AD values on the kernel command line. Ask the
      # server for them, the same way FOS does after a USB boot. Keep only the
      # host* lines of the reply, and delete the reply because it holds the password.
      if [[ -z $hostusead ]]; then
          curlcmd=(curl -Lks)
          command -v fog.curl >/dev/null 2>&1 && curlcmd=(fog.curl -Ls)
          sysuuid=$(dmidecode -s system-uuid)
          sysuuid=${sysuuid,,}
          [[ -z $mac ]] && mac=$(getMACAddresses)
          token=$("${curlcmd[@]}" --data "mac=$(echo $mac | base64)" "${web}status/hostgetkey.php")
          "${curlcmd[@]}" -o /tmp/hinfo.txt --data "sysuuid=${sysuuid}&mac=${mac}&hosttoken=${token}" "${web}service/hostinfo.php" -A ''
          if [[ -f /tmp/hinfo.txt ]]; then
              . <(grep -E '^\[\[ -z \$host[a-z]+ \]\] && export host[a-z]+=' /tmp/hinfo.txt)
              rm -f /tmp/hinfo.txt
          fi
      fi
      
      joinDomain=""
      if [[ $hostusead == 1 && -n $hostaddomain ]]; then
          if [[ -z $hostadpass ]]; then
              echo " * No domain join password received, so the domain join is skipped."
              echo "   Set FOG_HOSTKEY_ALLOWED_SOURCES to the imaging network to send it."
              debugPause
          else
              joinDomain=1
              # Qualify a bare user name with the domain: DOMAIN\user.
              joinUser="$hostaduser"
              [[ $joinUser != *\\* && $joinUser != *@* ]] && joinUser="${hostaddomain}\\${joinUser}"
          fi
      fi
      
      name=$(xmlValue "$hostname")
      for unattend in "${unattends[@]}"; do
          dots "Writing Computer Name to $unattend"
          sed -i "s|<ComputerName>[^<]*</ComputerName>|<ComputerName>${name}</ComputerName>|g" "$unattend"
          if [[ ! $? -eq 0 ]]; then
              echo "Failed"
              debugPause
              handleError "Failed to update $unattend"
          fi
          echo "Done"
          debugPause
          [[ -z $joinDomain ]] && continue
          dots "Setting the domain join in $unattend"
          # Username and Password change only inside <Credentials>. AutoLogon and
          # the local accounts use the same element names.
          sed -i \
              -e "/<JoinWorkgroup>/d" \
              -e "/<Credentials>/,/<\/Credentials>/s|<Password>[^<]*</Password>|<Password>$(xmlValue "$hostadpass")</Password>|" \
              -e "/<Credentials>/,/<\/Credentials>/s|<Username>[^<]*</Username>|<Username>$(xmlValue "$joinUser")</Username>|" \
              -e "s|<MachineObjectOU>[^<]*</MachineObjectOU>|<MachineObjectOU>$(xmlValue "$hostadou")</MachineObjectOU>|g" \
              -e "s|<JoinDomain>[^<]*</JoinDomain>|<JoinDomain>$(xmlValue "$hostaddomain")</JoinDomain>|g" \
              "$unattend"
          if [[ ! $? -eq 0 ]]; then
              echo "Failed"
              debugPause
              handleError "Failed to set the domain join in $unattend"
          fi
          echo "Done"
          debugPause
      done
      
      posted in Tutorials
      Tom ElliottT
      Tom Elliott
    • RE: Fog 1.6.14 Driver Replication Issue

      @FlareImp Thanks for the details. Each “File does not exist” line in the Image Replicator log names the file the replicator could not find on the storage node. Can you post the following:

      • One full replication cycle from the Image Replicator log (FOG Configuration > Log Viewer), including the “File does not exist” lines.
      • The FOG version on each storage node that receives the driver folders. Do any of them still run 1.5?
      • For one file that the log names, the ls -la output for that file on the master node and on the storage node.
      posted in FOG Problems
      Tom ElliottT
      Tom Elliott
    • RE: 1.6.0.14: Web UI not staying signed in?

      @Shuttleu The fix is now in stable release 1.6.0.158. Update to it, and remember me should work appropriately.

      posted in FOG Problems
      Tom ElliottT
      Tom Elliott
    • RE: 1.6.0.14: "Create new tasking" modal hangs on "Loading, please wait..." if the host has no image

      @lperoma The fix is now in stable release 1.6.0.158. Update to it, and a refused task shows its reason in the modal instead of hanging on “Loading, please wait…”.

      posted in FOG Problems
      Tom ElliottT
      Tom Elliott
    • RE: 1.6.0.14: Web UI not staying signed in?

      @Shuttleu This is a bug in 1.6.0, not a setting you missed. The inactivity timeout signs you out and clears the Remember Me cookie, even when you checked Remember Me. The default timeout is 1 hour.

      Workaround until the fix ships: go to FOG Configuration → FOG Settings → Login Settings. Set FOG_ALWAYS_LOGGED_IN to 1, or set FOG_INACTIVITY_TIMEOUT to 24.

      I will post here when the fix reaches the stable channel.

      posted in FOG Problems
      Tom ElliottT
      Tom Elliott
    • RE: 1.6.0.14: "Create new tasking" modal hangs on "Loading, please wait..." if the host has no image

      @lperoma Thanks for tracking this down. Your reading is right.

      The 400 is “Assigned image is invalid”. The modal tried to close itself on the error, but the request came back while the modal was still opening, and the browser ignored the close. So it sat on “Loading, please wait…” with nothing to say why. The group Tasks tab and the re-deploy link on the Tasks page had the same problem.

      The fix is in this pull request: https://github.com/FOGProject/fogproject/pull/2091. On any refused request, the modal now shows the reason in a red box, for example “Assigned image is invalid”, and stops loading. It is not merged yet. It reaches stable with the next stable release after it merges.

      Until then, the workaround is what you found: set an image on the host’s General tab first.

      We did not grey out Deploy and Capture. With the reason in the modal, it is clear what to fix.

      posted in FOG Problems
      Tom ElliottT
      Tom Elliott
    • RE: Feature request: a "Troubleshooting" menu in the web UI to find hosts that fail to authenticate

      @lperoma Thank you for the detailed write-up. The detection notes made this quick to scope.

      FOG 1.6 covers this as follows:

      FOG Client cannot authorize. This was the real gap, and a pull request now adds it: https://github.com/FOGProject/fogproject/pull/2089. The server records each host whose client fails the handshake: since when, how many times, the source address and the reason. A new list report, Reports > Client Authentication Failures, shows them with the fix next to each one. A host leaves the list when its client authenticates again. Two reasons are recorded:

      • The security token does not match. Reset Encryption Data fixes this.
      • The server cannot decrypt the client’s key. This means the certificate the server publishes for clients does not pair with its private key, so every host fails at once. A reset does not help. Running the installer with --recreate-keys issues a new pair.

      One case stays invisible to the server. A client that trusts a different FOG CA refuses the server’s certificate and never sends a login, so there is nothing to record. Its fog.log shows “Certificate is not from FOG CA”.

      Rejected iPXE menu logins. 1.6 already records each rejected login in the audit trail, with the username and the address. Look under Reports > Audit Report.

      Hosts with no contact. 1.6 stores the last check-in and the last ping for each host. Fleet Report shows the last check-in, so you can sort on it.

      All of this is 1.6 only. 1.5.x does not get these changes, so your script remains the answer there until you move to 1.6.

      posted in Feature Request
      Tom ElliottT
      Tom Elliott
    • RE: Question regarding the new Fog Agent (FOG 1.6.x) prior to syspreppping

      @JYost With agent 0.1.23 or later, you do not need to stop or disable it before Sysprep, and you do not need the SetupComplete.cmd line. The agent waits until Windows setup has finished before it enrolls, checks in, or reboots. It starts on its own after OOBE completes.

      On an older agent, update it on the reference machine first. Or use the same steps as before with the new service name: sc config fog-agent start= disabled before Sysprep, then sc config fog-agent start= delayed-auto and sc start fog-agent in SetupComplete.cmd.

      You also do not need to clear the agent’s key before capture. Each deployed machine has different firmware IDs, so the agent drops the captured key and enrolls as itself. A deploy from your server approves it automatically.

      No firewall rule is needed. The agent opens no listening port. It only connects out to the FOG server over HTTPS.

      Details: https://docs.fogproject.org/installation/client/install-fog-agent#capturing-an-image-with-the-agent-installed

      posted in FOG Problems
      Tom ElliottT
      Tom Elliott
    • RE: Fog 1.6.0.14 Master Storage Node not handing off to Slave Storage Nodes

      @FlareImp One correction to my last post. With the fix, a location’s Storage Node is where its hosts start, not a hard limit. When that node is full, a waiting host moves to a free node in the location’s own storage group. It never leaves that group, so the image still comes from your site. You can leave the location’s Storage Node set.

      posted in FOG Problems
      Tom ElliottT
      Tom Elliott
    • RE: Fog 1.6.0.14 Master Storage Node not handing off to Slave Storage Nodes

      @FlareImp Thank you. This is a bug in 1.6, and it explains what you see.

      What happens: FOG picks a storage node for each host when you create the task. It should pick the node with the lowest load. In 1.6 the load value was always empty, so every task went to the first node in the group, which is your master. A host also stays on the node it got at task creation. When that node is full, the host waits in line there, even when another node in the group is idle.

      The fix: https://github.com/FOGProject/fogproject/pull/2082. It does two things:

      • Task creation picks the least-loaded node in the group.
      • At boot, a host whose node is full moves to the node in its group with the most free slots. A capture never moves, because it must upload to the master.

      It goes to dev-branch first, and reaches stable in the next stable release.

      Check your location settings first. Copying the plugin folder does not change this, but your location can. If the location for those hosts has a Storage Node set, every host in that location goes to that one node. That is by design, and the fix does not change it. To spread the hosts across the group, open the location, clear the Storage Node, and keep the Storage Group set.

      posted in FOG Problems
      Tom ElliottT
      Tom Elliott
    • RE: FOG 1.6.0.127 — efitools unavailable on Oracle Linux 8 and Secure Boot signing failures

      @sgennadi Thanks for the write-up. It matches what I found. --addcert first appears in sbsigntools 0.9.4, so 0.9.4 is the minimum. EPEL 8 ships 0.9.2, so this affects every EL8 install, not only Oracle Linux. The Rocky Linux Core SIG package you used is a good way to get a newer version.

      A dev-branch change (PR #2081) makes the installer test for --addcert before it signs. When the option is missing, the installer now names the required version instead of printing a bare “Failed”.

      posted in Bug Reports
      Tom ElliottT
      Tom Elliott
    • RE: FOG 1.6.0.127 — efitools unavailable on Oracle Linux 8 and Secure Boot signing failures

      @sgennadi We don’t have support for Oracle Linux so I’m unsure how we can help out here?

      I’m attempting to look at the addcert issue, it does seem sbsign only has the addcert argument in 0.9.4 and higher, and we’re attempting to use it, so RHEL based 8.x likely causing the issue you’re seeing.

      posted in Bug Reports
      Tom ElliottT
      Tom Elliott
    • RE: After updating FOG to version 1.6.0.117, the Management Portal returns HTTP 500 Internal Server

      @sgennadi Thanks for the detailed report. Your diagnosis is right.

      Cause: FOG 1.5, and 1.6 builds from before July 2026, stored FOG_MESSAGES in the session as a string. Current code stores a list and appends to it. When a browser still carries one of those old sessions, the inactivity notice tries to append to the string, and every request from that browser returns a 500.

      Fix: https://github.com/FOGProject/fogproject/pull/2080, merged to dev-branch. setMessage() now resets a non-list queue, and getMessage() drops old string entries. Pull dev-branch and re-run the installer to pick it up.

      If you cannot update right away, clear the FOG cookie in the affected browser, or delete that browser’s session file. The error stops for that browser.

      posted in Bug Reports
      Tom ElliottT
      Tom Elliott
    • RE: FOG Server 1.6 Fails to install Secureboot certificates with Custom CA and Secure Boot keys?

      @Shuttleu Thank you for testing on the HP. That confirms the fix on real firmware.

      The task error after a menu enrollment. This is a FOS bug, not the agent. The menu item runs the enrollment with no task scheduled. When the enrollment finishes, FOS tries to close the task. The server answers “No Active Task found”, and FOS shows an error. The enrollment itself succeeded. The fix is in FOS release 20261106-134043. After a menu run, FOS now says that no task is scheduled and ends normally. The server records the enrollment on the host only when you schedule the task from the web UI.

      FOG Agent. You found the cause. Uninstall keeps C:\ProgramData\FOG on purpose. It holds the machine’s key, its certificate and the trusted CA, so a reinstall keeps the same identity. The reinstall kept the CA of your earlier server, so every connection failed and the token was never used. Agent v0.1.21 fixes this. Setup now checks the stored trust against the server. If it no longer verifies, setup settles trust again like a first install, and the host enrolls again with the token. Until you install v0.1.21, deleting C:\ProgramData\FOG before the reinstall is the right workaround.

      Your server certificate comes from your company CA, which Windows already trusts. So no fingerprint is needed, as the probe said. Leave CAFINGERPRINT out on these machines.

      posted in FOG Problems
      Tom ElliottT
      Tom Elliott
    • 1 / 1