@cjiwonder It may help if you tell us what model of PC you’re trying to boot. There may be a BIOS setup option that needs adjustment.

For example, my Dell 3430s’ BIOS setup requires the following boot options:

General -> Boot Sequence: Onboard NIC(IPV4) (checkmark to enable)
General -> Boot Sequence: UEFI (checkmark to enable)
AND “Onboard NIC(IPV4)” must be the first device in the boot sequence list

But I must also have the following options in different menu set:

System Configuration -> IntegratedNIC: Enable UEFI Network Stack
System Configuration -> IntegratedNIC: Enabled w/PXE

@cjiwonder said in UEFI is not booting with Windows DHCP:

@george1421 There is no error message, “>>Start PXE over IPv4” message and after a minute booting to HDD. Fog Server and PXE boot client are in the same VLAN but DHCP server is in a different VLAN. Tried with snponly.efi, intel.efi and pexe.efi but no luck. There is no issue with the DHCP IP release if I boot the PC in Windows, and there is no issue in booting with undionly.exe on the same PC. I am new to Wireshark, please guide me to run the capture filter. Thanks.

I just remembered that I had pretty much the same problem recently.

My problem was that the Ethernet link negotiation was taking too long on the Cisco 3850 switch I had the client connected to. The link negotiation took about 30 seconds and the IPXE wait for DHCP also took about 30 seconds, but always failed. This problem only happened for me when booting UEFI - worked fine booting BIOS / Legacy.

The solution for my case was to add this to the client port configuration on my Cisco switch:

spanning-tree portfast

@RAThomas Confirmed the very last tweak to be working, as expected.

@Tom-Elliott I’ve tested it with a deploy task scheduled for 15:30 and it fired off the active task at 15:30:34, which is a big PASS in my book.

Now, are you going to make me do a pull request?

PS: I will, pro forma, test your last tweak, but that looks fine too.

@Tom-Elliott I do like me some simplification. I will try your suggestion and report back.

@RAThomas screencap showing the above proposed change working correctly (scheduled task above, resulting active task below, shown at ~15:00:10

Ie. my proposed code change is working for me. My php.ini still does not explicitly set a timezone, but FOG settings does set my CDT timezone.

@Tom-Elliott Thank you for pointing me in the right direction. I’ve corrected it for myself, but after looking around in the PHP code, I’d like to ponder a change in defaults/settings priority.

Right now the FOG timezone selection logic is: If php.ini specifies a timezone (and PHP 8.2 appears to “specify” UTC if there’s nothing explicitly set in php.ini), then use that timezone. Ie, FOG will always use UTC or what is specified in php.ini, and FOG will never use $fogsettings[4].

I propose (only if my above analysis is correct) that we flip the priority logic to favor $fogsettings[4] timezone setting.

fogcore.class.php::setEnv() existing logic:

        $defTz = ini_get('date.timezone');

        if (empty($defTz))
        {
            if (empty($fog_settings[4]))
            {
                $GLOBALS['TimeZone'] = 'UTC';
            } else
            {
                $GLOBALS['TimeZone'] = $fog_settings[4];
            }
        } else
        {
            $GLOBALS['TimeZone'] = $defTz;
        }

Proposed logic:

    $defTz = ini_get('date.timezone');

    if (empty($fog_settings[4]))
    {
        if (empty($defTz))
        {
            $GLOBALS['TimeZone'] = 'UTC';
        } else
        {
            $GLOBALS['TimeZone'] = $defTz;
        }
    } else
    {
        $GLOBALS['TimeZone'] = $fog_settings[4];
    }

Problem:

• I scheduled a task to begin at 15:30 (CDT)
• The task began at 10:30 (CDT) instead

Background:

• I am in US Central time zone (CDT, aka UTC -5)
• On the FOG server web GUI, in FOG Settings->General Settings “TZ INFO” is set to “America/Chicago [CDT -05:00]”
• The FOG server is set to use CDT:

lrwxrwxrwx   1 root root      30 Apr 22 10:16 localtime -> /usr/share/zoneinfo/US/Central

• Time according to my fog server when the above cron scheduled task kicked off:

root@masterfog-1-5-10:~# date
Wed Oct 15 10:00:10 AM CDT 2025

My understanding is if a Linux computer’s localtime is set different from UTC, the cron should use the local time automatically.

@pilipp_edv

Maybe try stepping back to older kernels via the web GUI, FOG Configuration -> Kernel Update

That way you can test if it is purely a kernel issue without downgrading anything else.

@shieldsj

By “10.149.50.21:/images” I was referring to the “images” directory in the filesystem on the storage node at the IP address 10.148.50.21

So to check the actual contents of the “/images” directory, you’ll need to either:

1 - have a display and keyboard directly connected to that storage node (PC) to log into it and view the filesystem with whatever File Explorer type app its GUI desktop supplies OR

2 - open a terminal / command line on that storage node PC, either at a display/keyboard connected to the storage PC or across the network with SSH.

In any case, the contents of the storage node’s /images directory should be (mostly) subdirectories that are named exactly the same as your saved/captured images.

Example:

If you intended to capture an image called “Teacher_Pc”, the storage node’s /images directory should contain a subdirectory named “Teacher_Pc”

In my case, I have captured an image I named “20250319-7010-adult-builder”. Here is a truncated directory listing on one of my storage nodes:

root@node25-0:/images# ll
total 140
drwxrwxr-x 32 fogproject fogproject  4096 Aug 12 11:19 ./
drwxr-xr-x 25 root       root        4096 Aug 12 09:33 ../
drwxrwxr-x  2 fogproject fogproject  4096 Jul 31 10:05 20250319-7010-adult-builder/
drwxrwxr-x  2 fogproject fogproject  4096 Jul 31 10:06 20250327-7010-deploy-test/

If somehow you have managed to get the image name (directory name) to be “, Image name Teacher_Pc” then I’ll not be surprised if parsing (text handling) errors happen within FOG when you try to use that image name. In that case, the directory can be renamed to “Teacher_Pc”, BUT that directory name must match in one field recorded in the fog database on the FOG server.

Let’s see what you’ve got in the “/images” directory first.

I bet if I had gone into the web “FOG Boot Settings” and toggled the check box for “Kernel Debug” to ON and then back OFF if that would have fixed it for me too. Instead of me editing the database directly.

@Tom-Elliott

I’m ready to call this one “Solved” for my own purposes. I do wholeheartedly thank you for pointing me in the right direction!

@Tom-Elliott

I think I’m onto it. Browsing the table ‘globalSettings’ I found FOG_KERNEL_DEBUG which was empty:

MariaDB [fog]> select * from globalSettings where settingKey = 'FOG_KERNEL_DEBUG'\G
*************************** 1. row ***************************
      settingID: 133
     settingKey: FOG_KERNEL_DEBUG
    settingDesc: This setting allows the user to have the kernel debug flag set. Default is off.
   settingValue:
settingCategory: FOG Boot Settings
1 row in set (0.001 sec)

So I changed its value to 0:

MariaDB [fog]> select * from globalSettings where settingKey = 'FOG_KERNEL_DEBUG'\G
*************************** 1. row ***************************
      settingID: 133
     settingKey: FOG_KERNEL_DEBUG
    settingDesc: This setting allows the user to have the kernel debug flag set. Default is off.
   settingValue: 0
settingCategory: FOG Boot Settings
1 row in set (0.001 sec)

Then I canceled and restarted my deploy task to client Master-3430 and it went straight into deploying, no debug mode.

Assuming this is my ‘global’ fix (Edit: looks like it is. 2 auto deploys to Master-3430 and 2 to an older BIOS boot client), it leaves some questions. Is “empty” supposed to be a valid value for FOG_KERNEL_DEBUG? If not, did my db miss some upgrade step because I fumbled my way through copying files? How did this problem crop up just in my case / is it likely to happen to other upgraded installations?

I could resurrect my old server and inspect its database if that is helpful to you.