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

  K

  @Tom-Elliott
  These are the two machines that were just cloned!

  I deployed the Snap-in three times:
  the two newly cloned machines and one old machine to see if any certificate issues arise with the old computers. All of them were assigned Image B.

  The computer, which has not yet been cloned, did not process the snap-in.

  ec06f2be-575a-48f2-9f68-3a9f156dd330-grafik.png

  ------------------------------------------------------------------------------ --------------------------------Authentication-------------------------------- ------------------------------------------------------------------------------ 28.09.2026 07:38:56 Client-Info Version: 0.13.0 28.09.2026 07:38:56 Client-Info OS: Windows 28.09.2026 07:38:56 Middleware::Authentication Waiting for authentication timeout to pass 28.09.2026 07:40:56 Middleware::Communication Download: http://192.168.0.196/fog/management/other/ssl/srvpublic.crt 28.09.2026 07:40:58 Middleware::Communication ERROR: Could not download file 28.09.2026 07:40:58 Middleware::Communication ERROR: Die Verbindung mit dem Remoteserver kann nicht hergestellt werden. 28.09.2026 07:40:58 Client-Info ERROR: Failed to authenticate, will not run Module Looper.

  78935d01-cc19-4dd8-b5bc-fb03e7885c58-grafik.png
  Resetting the encryption settings, deleting the snap-in that wasn’t running, and restarting it didn’t help…

  Rebooting of the pc helped

• Announcements

  Get the latest news on what's happening.

  Security Advisories
  186 Topics

  827 Posts

  T

  The second release candidate for FOG 1.6.0 is available on the rc-1.6.0 branch. It reports version 1.6.0-RC-2.

  Test it on a lab or non-production server first. The upgrade from 1.5 to 1.6 is one-way: it changes the database schema, and there is no down-migration.

  Upgrade from RC-1 now if your server was upgraded from 1.5. RC-1 left the certificate files of a 1.5 server in the wrong directory. RC-2 prevents this and repairs a server that RC-1 already affected.

  Fixed since RC-1

  A 1.5 upgrade lost its certificates (#1797). FOG 1.5 made /etc/fog a link to /opt/fog/service/etc. The upgrade wrote the new CA and web certificates through that link, then replaced the link with an empty directory. The files stayed in /opt/fog/service/etc/pki, where FOG does not look. Apache kept running on the certificate it had loaded, so the upgrade looked clean. At the next restart or reboot, Apache failed with SSLCertificateFile: file '/opt/fog/pki/web/leaf/.webLeaf.pem' does not exist or is empty. RC-2 converts the link before it writes any certificate. On a server RC-1 already affected, the RC-2 installer copies the files back. It never overwrites a file that exists, and it keeps any differing copy beside the original as pki.recovered-<date>. updatefog.sh --channel rc reported no release candidate when it could not reach the remote (#1793). A failed git ls-remote, for example as root with an SSH remote and no key, read as “No release candidate is currently published”. The installer now names the remote and says it could not reach it. The installer summary showed the netboot protocol of the previous run (#1798). A re-run with --no-public-web-cert showed Netboot (PXE) protocol: https, and then correctly set up HTTP netboot. The summary now shows the protocol the run uses. Versioning (#1796). The RC tag no longer changes the version that 1.5 branches compute.

  If Apache on your RC-1 server does not start

  Your certificates are most likely in /opt/fog/service/etc/pki. Update to RC-2 with bin/updatefog.sh --channel rc. The installer restores the files.

  Before you upgrade

  Back up your database and /opt/fog/.fogsettings. Read the release notes: https://github.com/FOGProject/fogproject/blob/rc-1.6.0/docs/release/1.6.0-release-notes.md 1.6 removes Display Manager, Directory Cleaner, User Cleanup, Client Updater, Green FOG and the persistentgroups plugin. Their data is dropped. The site and accesscontrol plugins move into core. PHP 7.4 or later is required. Plugins built for 1.5 do not load.

  Install or update (as root)

  A 1.6 beta or RC-1 server: run bin/updatefog.sh --channel rc from your FOG checkout. A 1.5 server installed from git: update to the current 1.5 stable, then run bin/updatefog.sh --channel rc from the checkout. A new server, or a 1.5 server installed from a tarball:
  curl -fsSL https://raw.githubusercontent.com/FOGProject/fogproject/working-1.6/bin/bootstrap.sh | bash -s -- --channel rc

  Report problems

  Open an issue at https://github.com/FOGProject/fogproject/issues. Include your FOG version, your OS, and the installer log from bin/error_logs/. Report a security problem through “Report a vulnerability” on the same repository, not in a public issue.

• 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 Yes, FOG writes that boot code, and I can show you where. Your finding holds up against our
  source and against a reproduction here.

  Where it comes from. On capture, saveGRUB() in funcs.sh copies the first 1 MiB of the
  source disk into d1.mbr with dd — LBA0 included, boot code and all. On deploy,
  clearPartitionTables() runs sgdisk -Z, which does clear the MBR, and then restoreGRUB()
  writes d1.mbr straight back over it. The next two commands are sgdisk -z, which destroys
  the GPT structures only and leaves the MBR bytes alone, and sgdisk -gl, which rewrites only
  the protective partition entry. So the captured Windows bootstrap survives the whole
  sequence, and gdisk supplies the entry in its own convention: EndCHS ff ff ff and the exact
  sector count.

  I replayed that sequence here on a loop-backed disk with one of our own Windows 11 resizable
  images. The result matches what you found byte for byte in shape:

  LBA0 : 33 c0 8e d0 bc 00 7c 8e ... (Windows MBR stub) 0x1BE : 00 00 02 00 ee ff ff ff 01 00 00 00 af 32 cf 1d

  Why it is not simply a bug. On a BIOS-booted GPT Linux disk that same region is GRUB’s
  boot.img, and d1.grub.mbr exists precisely so we keep it. We cannot blanket-zero LBA0 on
  every GPT restore. On a Windows GPT image it is dead weight — Windows only boots GPT through
  UEFI — so a targeted change is available to us. But we should change the right bytes.

  Which byte is it? Your diskpart disk differs from ours in three places at once, so we do
  not yet know which one the firmware chokes on. Three one-liners settle it. Start from a fresh
  deploy that hangs, run one of them, power off, power on, press F2. Redeploy between tests so
  each one is measured on its own:

  # 1 - the bootstrap, nothing else dd if=/dev/zero of=/dev/nvme0n1 bs=1 count=446 conv=notrunc # 2 - the size field -> sentinel printf '\xff\xff\xff\xff' | dd of=/dev/nvme0n1 bs=1 seek=458 conv=notrunc # 3 - EndCHS -> the diskpart value printf '\xfe\xff\xff' | dd of=/dev/nvme0n1 bs=1 seek=451 conv=notrunc

  Each writes inside LBA0 only and leaves the GPT untouched. Test 1 is the one I expect to
  matter, on the theory you already stated — a CSM path in that firmware reading or validating
  a bootstrap it should be ignoring.

  Name the byte and the fix is small: for a GPT image whose OS is Windows, clear that field
  during the restore and leave Linux images alone. That also gives the two 2020 reports on this
  hardware an explanation, which is worth having on its own.