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

  @kratkale Two separate things. The first gets your PCs booting today.

  PXE boot, now. The installer stopped before it rewrote the boot file, so the file still says https. Change it by hand:

  sed -i 's#^chain https://#chain http://#' /tftpboot/default.ipxe grep chain /tftpboot/default.ipxe

  The line must now start with chain http://192.168.0.196/. Boot one PC to test it. The next complete installer run writes this file again, with http.

  The installer failure. Your certificates were not changed. The installer stopped before it created anything. The Secure Boot signing files that your settings name are not on disk, so it tried to create new ones. That needs the private key of your FOG root CA, and the key is not at /etc/fog/pki/root/ca/.fogCA.key. Your root certificate is still there, so your FOG clients are not affected.

  Please do not delete anything, and do not run the installer with --recreate-CA. That replaces the CA that all your FOG clients trust.

  Please post the output of these commands. They show only file names and paths, no key contents:

  ls -la /etc/fog/pki /etc/fog/pki/root/ca /etc/fog/pki/secureboot /etc/fog/pki/secureboot/ca /etc/fog/pki/secureboot/leaf /opt/fog/snapins/ssl/CA ls -ld /opt/fog/pki grep -E '^PKI_(root|sb)_' /opt/fog/.fogsettings find / -xdev -name '.fogCA.key' 2>/dev/null
• 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 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.