Categories

• Technical Help

  Get help with your FOG system.

  FOG Problems Hardware Compatibility Windows Problems Linux Problems Mac Problems General Problems
  13k Topics

  115k Posts

  T

  @Mikeee89 Thanks for the detailed report. It pointed straight at the cause.

  Cause: when udp-sender exits, the multicast manager closed the session and marked every host’s task Complete at the same time. The clients were still post-processing (UUID reset, NTFS flag, hostname). So when each client then reported back, its task was already gone: “No Active Task found for Host”. The imaging log row stayed open, which is where the “2026 years” duration comes from. This came in with the fix for #820.

  Fix: the manager still closes the session when the sender exits, but now leaves each host’s task for that host to close itself. PR #1776 (dev-branch), #1777 (working-1.6). I reproduced your exact error against a copy of a 1.5.10 database, and the patched code returns success and closes the imaging log.

  On your other observations:

  msClients is reset to 0 when a session completes, so 0 after the run is expected. -2 is the marker for a session created from Image Management, not a counter underflow. The multicast.log.udpcast.<id> file is deleted at the end of every session, and has been for years. That is a separate question, not part of this bug. “has been killed” is printed even when the sender exited by itself. The wording is misleading, but nothing is actually killed.

  Once it merges, update to the latest dev-branch and the task should close normally.

• Announcements

  Get the latest news on what's happening.

  Security Advisories
  184 Topics

  825 Posts

  A

  @Tom-Elliott I really appreciate that you are putting effort into providing more frequent releases, which makes it easier for everyone to deploy new security fixes in time. Keep up the good work!

• General Topics

  View tutorials or talk about FOG in general.

  General Tutorials
  2k Topics

  19k Posts

  R

  Now I read the AI summary and got what I need:

  It stores one row for each address in the hostNetwork table. Limits of this method The sleeping host must run fog-agent. The server uses the sleeping host’s own last report to find its subnet. A host with the legacy FOG Client, or with no client, has no rows, so the relay cannot help it. The old path still runs for it.

  So If I populate the hostNetwork table for the hosts that I need manually, It will work. Thank you for the details.

• Developers

  Report bugs, request features, or get the latest progress.

  General Feature Request Bug Reports
  2k Topics

  21k Posts

  T

  @servicedesk-pianezza You are right and I was wrong. F2 hanging settles it. “Preparing to enter BIOS Setup” runs
  before any bootloader, so the firmware is the thing that stalls, and my reading of the iPXE
  test was bad. Ignore that whole post.

  Your Windows 10 control is the best evidence in this thread. Same capture pipeline, same
  FOG, same drive, same machine, and it boots. Together with “resizable and non-resizable both
  hang”, that clears our resize path and it clears FOG’s table writing as a general fault: we
  are laying down the captured disk faithfully, and this particular captured disk upsets this
  particular firmware.

  So the question is narrow now: which bytes? Two things, and the first one you can do from
  your desk.

  Diff the two tables. You have a good drive and a bad drive from the same pipeline. In a
  debug task on each, capture:

  sfdisk -d /dev/nvme0n1 sgdisk -v /dev/nvme0n1 gdisk -l /dev/nvme0n1

  Post both sets. Partition count, order, types, attributes and the end-of-disk figures are
  the things the firmware reads at enumeration, and a diff of Win10-good against Win11-bad
  names the difference without any guessing.

  Then bisect the disk, in this order. Start from a deployed drive that reproduces the
  hang, and after each step power off, power on, press F2, and note whether Setup opens.

  Destroy the partition table only, leaving every byte of partition data where it lies:

  sgdisk -Z /dev/nvme0n1

  If Setup now opens, the firmware is choking on the partition table — layout, types or
  attributes — and not on anything inside the partitions. If it still hangs, the data is the
  problem, so redeploy and zero the start of the ESP, which is the only partition the firmware
  reads:

  dd if=/dev/zero of=/dev/nvme0n1p1 bs=1M count=1

  If Setup opens after that, it is the ESP filesystem, and we can bisect it file by file from
  there.

  Three questions while you are at it. Which Windows 11 build is the image, and which build
  was the Windows 10 one? Was the Hyper-V VM Generation 2 with Secure Boot and a vTPM
  attached? And what BIOS version are the 3400s on — Dell’s last for that model is in the 1.3x
  range, and firmware is the component under suspicion now.

  Also worth saying plainly: if this turns out to be the Latitude 3400 firmware choking on a
  partition layout it does not like, there may be nothing for FOG to fix beyond documenting
  it. Two earlier reporters on this hardware ended up rebuilding the image from a clean install
  rather than finding a cause. I would rather find it, and your Win10 control is the first
  thing anyone has produced that makes that realistic.