Categories

  • 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.

  • Get the latest news on what's happening.
    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!

  • View tutorials or talk about FOG in general.
    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.

  • Report bugs, request features, or get the latest progress.
    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!

111

Online

12.7k

Users

17.6k

Topics

156.9k

Posts