Thank you. I updated working-1.6 today and re-ran installfog.sh.

The server is now running:

• FOG 1.6.0-beta.5362
• iPXE v2.0.0-fog.8

I can also confirm that the agent enrollment fix works. Before the update /fog/agent/v1/enroll was returning HTTP 308. After the update it returns HTTP 202 and the agent appears under “Pending agents” in the FOG web interface.

However, I can still reproduce the UEFI boot problem, and I was able to narrow it down further.

The newly generated /tftpboot/default.ipxe from beta.5362 is 979 bytes. With this file the UEFI client successfully downloads default.ipxe but then stops immediately after:

default.ipxe... ok

I tested this with both:

• ipxe.efi
• secureboot/snponly-shimx64.efi

The result is the same with both.

I then replaced only default.ipxe with my older copy from 2026-07-24 (479 bytes), without changing the current FOG installation or iPXE binaries.

With the old default.ipxe:

• secureboot/snponly-shimx64.efi boots correctly
• ipxe.efi also boots correctly
• the FOG menu appears normally
• after the timeout the machine continues into Windows normally
• Legacy BIOS clients also continue to work normally

So the problem appears to be reproducibly related to the contents of the newly generated default.ipxe, rather than the EFI boot binary itself.

For reference:

Working default.ipxe from 2026-07-24:

• Size: 479 bytes
• SHA256: 8e19bb03144b530567f08d2c0c173ab5b7c2df3e013e484b6ef19cf4f805e503

New beta.5362 generated default.ipxe:

• Size: 979 bytes
• SHA256: 11e0b7aa8c3cee380756bd6903fa149a9b7a3e3a58386aa2e8a62908106fa1a1

The diff shows several additional parameters in the new file, including serial/asset/Secure Boot parameters, additional NIC parameters, and this line:

isset ${netX/mac} && param macboot ${netX/mac} ||

For now I have left the old 479-byte default.ipxe in place because it restores normal booting.

If useful, I can provide both complete default.ipxe files or test a patched version if you would like me to test a specific change.

One additional observation after the update: the FOG web UI currently shows 243 pending MAC addresses.

For example, host 107PC10 has the real/primary MAC 60:6d:3c:d7:ff:48, but FOG has added the following as pending MACs for the same host:
b8:1e:a4:75:93:8d
b8:1e:a4:75:93:8e
ba:1e:a4:75:93:8d
be:1e:a4:75:93:8d

Other hosts show the same pattern. I have not approved or deleted these pending MACs yet.

I don’t know whether this is related to the default.ipxe regression, but I noticed that the new generated default.ipxe also contains the expanded netX/net1…net7 MAC parameter handling, so I wanted to mention it in case it is relevant.

Hello,

I am running the FOG 1.6 working branch on Ubuntu with Apache.

Current server details:

• FOG branch: working-1.6
• Commit: 47ea627c9
• Database schema: 436
• Apache: 2.4.66
• New client: fog-agent 0.1.6 x64
• Windows 11 clients

The new agent is installed with this server address:

https://192.168.1.100/fog

fog-agent status shows:

{
“enrolled”: false,
“has_key”: true,
“host_id”: 0,
“server”: “https://192.168.1.100/fog”
}

The Windows client is definitely reaching the server.

Apache access log:

192.168.102.20
POST /fog/agent/v1/enroll HTTP/1.1
308
Go-http-client/1.1

A manual test from the FOG server gives the same result:

POST https://192.168.1.100/fog/agent/v1/enroll

Response:

HTTP/1.1 308 Permanent Redirect
Location: https://192.168.1.100/fog/management/index.php

I already re-ran installfog.sh successfully.

The active Apache vhost contains:

<Location /fog/agent/>
SSLOptions +StdEnvVars +ExportCertData
</Location>

and:

RewriteRule ^/fog/(.*)$ /fog/api/index.php [QSA,L]

Apache is listening on 443 and apache2ctl -S shows:

*:443 fog (/etc/apache2/sites-enabled/001-fog.conf:38)

The issue remains after re-running the installer.

Additional information:
The legacy FOG Client 0.13.0 clients on the same server also recently stopped authenticating properly. They repeatedly call:

/fog/management/index.php?sub=requestClientInfo&authorize&newService

but do not continue normally.

Before the recent working-1.6 updates, the legacy clients were communicating normally.

I would prefer an upstream fix rather than manually modifying Apache or PHP files.

Is this a known regression in the current working-1.6 branch affecting the fog-agent /agent/v1/enroll route or the API router?

Thank you.