@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

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

@Tom-Elliott said in Clients (randomly?) boot to Debug Mode on regular deploy or capture:

but working through it is all we can do right?

Got that right.

I’ve verified “isdebug=yes” for the booted client kernel args, so I’m probably just missing something obvious on the other end. Checking…

Result:

MariaDB [fog]> select * from globalSettings where settingKey = 'FOG_KERNEL_ARGS'\G
*************************** 1. row ***************************
      settingID: 51
     settingKey: FOG_KERNEL_ARGS
    settingDesc: This setting allows you to add additional kernel arguments to the client boot image. This setting is global for all hosts.
   settingValue:
settingCategory: General Settings
1 row in set (0.001 sec)

For the client ‘Master-3430’ that I’ve got booted to debug mode right now:

MariaDB [fog]> select hostName,hostKernelArgs from hosts where hostName = 'Master-3430'\G
*************************** 1. row ***************************
      hostName: Master-3430
hostKernelArgs:
1 row in set (0.000 sec)

@Tom-Elliott

I’d already browsed the DB (via phpMyAdmin) for anything debug-ish, but didn’t really know where to look. Anyway:

MariaDB [fog]> select hostID,hostName,hostKernelArgs from hosts where hostKernelArgs like '%debug%';
Empty set (0.001 sec)

MariaDB [fog]> select groupID,groupName,groupKernelArgs from groups where groupKernelArgs like '%debug%';
Empty set (0.001 sec)

For completeness, a BIOS boot client (previously a months-stable FOG client) that booted to debug mode on deploy just yesterday uses ‘undionly.kpxe’ via DHCP. My more recently added UEFI boot client that has booted to debug mode uses ‘snponly.efi’ via DHCP.

Edit: It just occurred to me that I should check the actual kernel args once booted into debug mode. Check logs too? Anything else I can check on the client side at runtime to provide clues?

FOG server: Debian 12
FOG storage nodes (x5): Linux Mint 22.1
All on FOG Stable: 1.5.10.1667

Issue: Clients, seemingly at random (or I just haven’t pinned down the context) boot into Debug Mode instead of automatically deploying or capturing. In those cases, running fog.download or fog.upload works correctly, step-by-step, but obviously isn’t great for mass deployment.

I’m primarily working on deploying Windows 11 to Dell 3430 series PCs, but the Debug Menu problem also occurs with our older, stable Windows 10 / Dell 7010 images.

What I’ve done to get myself into this:

I inherited a network / system that was running FOG 1.5.9 on Debian 9. I used it as-was for several months until I saw a schedule break that made sense for upgrading.

I made new installs of Debian 12 (on the FOG server) and Linux Mint 22.1 (on the 5 storage nodes) on new(er) PCs. Then I copied the old /opt/fog and /images directories to the new PCs, as well as the existing mariadb database. Finally, I ran the 1.5.10.1667 install script on each, it using the pre-existing .fogsettings.

Coming at this upgrade from my oblique and ignorant angle, I did run into several problems with permissions, etc, but learned a fair bit about FOG in the process of head-banging. But now I’m stuck on this Debug Mode issue. I’m really sorry that I haven’t figured out what makes it (deploy/capture) work automatically (no Debug) sometimes and not others. My best guess so far is it might depend on which storage node gets selected for the task.

I think I’ll power down the 2 storage nodes that I know have been used when Debug Mode engaged and work from there. But I’m hoping someone here will immediately recognize this problem and say, “Hey Dummy, just do [this simple thing] right!”

Thanks in advance.

PS: yes, I know Mint isn’t supported, but other than one package install glitch, I’ve seen no obvious problems.

@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

@Afif

It looks like you’re using the latest available FOG Linux kernel (6.12.35) for the client to boot.

It also looks like you’re using an Intel NUC and the kernel crash occurred while partclone was running.

Do you have any other information about the context that might be helpful?

My only suggestion at this point is to try booting the client to an older kernel. You can select a different kernel in the FOG web management GUI by:

(1) click FOG Configuration (wrench / spanner icon)
(2) Kernel Update
(3) select an appropriate older “AMD/Intel 64 Bit” kernel
(4) click “Download” for the selected kernel
(5) click “Install” at the “Save Kernel” page

You might start by verifying the actual stored image name on the storage node at 10.149.50.21:/images

Next you might use some SQL tool (I use phpMyAdmin) to check the ‘fog’ database on your FOG server, table ‘images’ and verify that the values for ‘imageName’ and ‘imagePath’ both look correct.

‘imageName’ could be different from ‘imagePath’, but only if someone has renamed the image in the FOG server web GUI. ‘imagePath’ should be the same as the desired image directory in your storage node(s) /images directory.