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

  F

  Hi everyone I recently setup a FOG server. I added a storage node and I was able to get my FOG server to detect it. The node even stores the images on it properly. The node is working but i am not able to see the storage disk info of the node on the management portal. This is the error i am getting when I try to view the storage node details on the main screen on the portal. 83091a5e-489e-4bef-aa63-37fac7a8f007-image.png. Any help would be greatly appreciated.

• 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

  8

  @Cpasjuste

  Thank you, I appreciate that. And yes, I did spend a lot of time on it.

  I agree that it bypasses the official installer in order to make use of Docker environment variables; however, at this stage, I don’t believe that FOG is going to change so dramatically that it’ll break it often.

  I will add that if this could get adopted as an official docker image, we could work with the FOG team to make sure nothing gets to pushed to the FOG code that would break the container until we can adjust the container as well.

• Developers

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

  General Feature Request Bug Reports
  2k Topics

  21k Posts

  R

  Hi guys,

  Legacy (BIOS) issue I wanted to report in case anyone else experiences the same problem. I’m going on leave for a couple of weeks from today (07/08/2026) so may be slow to respond to any follow-up questions, but happy to test further on my return.

  We noticed a similar thing when upgrading to 1.5.10.1667 last year but found the below workaround. Since upgrading to 1.5.10.2149 we’re unable to use the below workaround.

  Environment:

  FOG Version: 1.5.10.2149 (upgraded from 1.5.10.1667)
  Server: Ubuntu VM on Hyper-V
  DHCP boot file served to Legacy BIOS clients: ipxe.kpxe
  Affected hardware: Dell OptiPlex 390, 3010, 3020 (Legacy BIOS)
  Unaffected: All UEFI devices

  Issue:

  After upgrading from 1.5.10.1667 to 1.5.10.2149, all Legacy BIOS devices fail to exit to the local hard drive after a PXE boot when no imaging task is assigned. UEFI devices are completely unaffected.

  All exit-to-hard-drive methods were tested and failed with the new ipxe.kpxe:

  Exit methods tested with the new ipxe.kpxe – all failed:

  GRUB_FIRST_HDD – Fatal: DHCP_ACK failure! / PXE unload fails: 106
  SANBOOT – Boot from SAN 0x00 … I/O error / hangs on 0x80
  refind_efi – Flashing cursor, no boot (expected as this seems to be the UEFI boot option?)
  GRUB_FIRST_FOUND_WINDOWS – OptiPlex 3010 and 3020 passed, OptiPlex 390 failed to get past PXE boot and presented with a BOOTMGR error

  Fix:

  Restoring ipxe.kpxe from the 1.5.10.1667 stable release commit (aa524d494) resolved the issue completely on all three Legacy BIOS models tested, with GRUB_FIRST_HDD as the exit method:

  Shell
  1
  cd /root/fogproject
  2
  git show aa524d494:packages/tftp/ipxe.kpxe > /tftpboot/ipxe.kpxe
  3
  sudo chown fogproject:root /tftpboot/ipxe.kpxe
  4
  sudo chmod 754 /tftpboot/ipxe.kpxe
  5
  sudo systemctl restart tftpd-hpa
  Show more lines

  Then set Exit to Hard Drive Type back to GRUB_FIRST_HDD in FOG Settings.

  Confirmed working after fix:

  OptiPlex 390 (Legacy BIOS) ✅
  OptiPlex 3010 (Legacy BIOS) ✅
  OptiPlex 3020 (Legacy BIOS) ✅
  UEFI devices (unaffected throughout) ✅

  This appears to be a regression in the ipxe.kpxe binary shipped with 1.5.10.2149, consistent with the UEFI-side binary issues reported in GitHub issue #978.

  Thanks!