I’m running v1.5.10.1826

Secure boot is meant to be… well, secure.

There are people attempting to get there, but I can say, right now, FOG just isn’t there right now.

On the forums you can see this at:
https://forums.fogproject.org/topic/17949/fog-secure-boot-with-shim

Which might help lead you in the direction as well hopefully.

@Jamaal The client lives on the Machine itself. not on the fog server.

Those logs live on teh Windows machine I forget the exact path but something like:

c:\program files\fog client\fog-error.log or something like that?

Yes, it’s c:\program files (x86)\fog\fog.log

I figured out the issue, lol. I was having a moment, but thanks for helping me out.

I think I’ve found the issue and pushed a code change to try to fix this.

There is a FOS image experimental release that is building currently (2025-12-21) that should contain this once it’s complete. Please download the inits and install them and run a test to see if this is correcting the issue of capture/deploy Multi Partition Image - All disks and let us know if this new version fixes the issue you’ve reported.

Thank you!

Thank you, that clarifies a lot. I now understand that hostSecTime represents the expiration time, not the creation time, which fully explains the consistent +30 minute offset I was seeing. That part now makes sense and resolves my question.

The only remaining actual issue I’m trying to understand is the snapin behavior: in several cases, snapins did not execute on some hosts. I don’t see any errors in the logs. Only that the snap-in task doesn’t start, but I will work on this and gather some more data. Thank you!

i’m not sure what caused it but glad it has since been addressed/fixed.

Thank you! And yes, I gave an upvote!

If there are any other solutions for this problem please let me know!
Cheers.

48c096ca-5f09-42d1-84dc-647e5bc6e22d-image.png

And I can see the same button for the group, so I guess I can handle this. Thank you very much @Tom-Elliott ! 😄

Well, the errors I can see in the /var/log/apache2/other_vhosts_access.log are:

Regarding the /var/log/apache2/error.log are:

The php version the server is running is:

I edited ‘addsubnetgroup.hook.php’ which simplified getting the client IP and adding the host to the respective group. I understand this also removes certain checks that were in place but for my environment it is now working as intended.

Old ‘addSubnetgroupHost’ function:

New code:

Thanks in advance!

http://forums.fogproject.org/post/122702

effectively your boot menu likely needs to be:

Replacing as appropriate:
<storageIPHere>
<imageNameHere>
<imageOSIDHere>
<imageFormatHere>

with your relevant information.

Ultimately finding these pieces of data relevant to your specific image will be the hardest part, but once done I believe this will do what you are wanting/hoping.

I have decided to run both servers on the same network. With DHCP switched off on AikenWorkbench, I’m able to boot intoFOG menu.

Your entries aren’t quite right, or I’m doing something wrong. If I use it as is, I’m getting something like "Could not boot: Not found (https://ipxe.org2d12618e)

I have decided to exclude some of the commands and narrowed it down to:

And I’m trying to run it on EFI EFI-capable machine, but I’m only getting to the grub console and no further.

I understand my best bet is to learn how iPXE works and study its documentation.

There is more config from Aken if this helps:

And grub.cfg

And here is the whole dhcp.conf but we don’t use Apple class as they dropped PXE support.

Now with Windows 11 24H2 we experiencing some strange issue.

after getting the image to the computer our postdownloadscripts start working, mounting the ntfs partition where windows resides and copying the drivers to a specific location.

We have noticed, that with a new golden master (with audit mode) the mount of the ntfs partition isnt working anymore the right way. We noticed that as we are checking some specific files in the windows folder as it is x86 or x64 architecture. In debug mode we had trouble to manually mount the partition with the ntfs-3g drivers. So we cannot check or copy anymore the drivers into the partition.

Bitlocker is disabled in the golden master as with oobe it cannot seal with it activated. So this cannot be the problem.
Maybe Windows did something to the NTFS Partitions in their new Windows 11 ISO ?

I also checked if the new filesystem (reFS) is active but we have a classic NTFS partition.

Anyone has the same problems ? Or does anyone have a solution for it ? New NTFS-3G drivers for the PXE or something like that ?

Florian

We need to redo our golden image, so we will check at that time if we still get the same behavior.

Thx for the help !

I’m new to FOG and I started learning how to leverage it because I want to deploy ChromeOS Flex at scale, to devices that are currently not managed via other tools. I’ve successfully configured an Ubuntu Server with FOG and I’ve managed to capture a Win10 image (that I can deploy to the same device I captured it from) and a ChromeOS Flex image (after converting the Win10 device to Flex using a USB). Deploying the ChromeOS Flex image to my device seems to get it into a bad state (PXE is the default boot method, but the menu times out and I get a black screen). I’ve tried this only once but before I repeat my whole process I wanted to reach out to the community to see if anyone has successfully deployed ChromeOS Flex using FOG.

I followed the settings in this post for my ChromeOS Flex image capture.

I’ve reinstalled FOG, using the in-built DHCP server instead of the router.
Worked perfectly first time, after setting the router as a relay instead.

Thank you very much for all your help! 🙂

Could having “multicast settings - UDPCAST INTERFACE” set to eth0 while the server’s network interface is eno1 be a potential source of problems?

Best regards.

Unfortunatily i cant manage, to get the Snapins installed to the host, after the Windows 11 Deployment is finished.
I already tried to create a second task with install only install snapins.
This is not Possible because the other deployment tast is still active after creating with script.

I just wan to write a script which is creating the host in FOG.
Then i want to connect to notebook to the Network and wait for the installation to be finished.

Would be awesome if someone can help me with a hint.

This is the Script i am Using:

#!/bin/bash

FOG_SERVER_ADDRESS=“http://10.0.96.10/fog”
GLOBAL_API_TOKEN=“token1”
USER_API_TOKEN=“token12”

HOSTNAME_NEU=“Test123”
MAC_ADRESSE_NEU=“10:20:30:40:50”
IMAGE_ID_NEU=8

SNAPIN_IDS_ZUZUWEISEN=(1 2 3 4 5 6)
DEPLOY_TASK_TYPE_ID=1
SHUTDOWN_AFTER_TASK=“false”

echo “Schritt 1: Erstelle Host mit aktivierten Modulen…” ( Create Host with modules enabled )

MODULE_IDS=“[1,2,3,4,5,6,7,8,9,10,11,12,13]”

JSON_PAYLOAD_CREATE=‘{
“name”: "’“${HOSTNAME_NEU}”‘“,
“macs”: [”’“${MAC_ADRESSE_NEU}”‘“],
“imageID”: ‘${IMAGE_ID_NEU}’,
“modules”: '”${MODULE_IDS}"’
}’

CREATED_HOST_RESPONSE=$(curl -s -X POST
-H “Content-Type: application/json”
-H “fog-api-token: ${GLOBAL_API_TOKEN}”
-H “fog-user-token: ${USER_API_TOKEN}”
-d “${JSON_PAYLOAD_CREATE}”
“${FOG_SERVER_ADDRESS}/host”)

HOST_ID=$(echo “${CREATED_HOST_RESPONSE}” | jq -r ‘.id’)

if [ -z “$HOST_ID” ] || [ “$HOST_ID” == “null” ]; then
echo “Fehler beim Erstellen des Hosts. Antwort: ${CREATED_HOST_RESPONSE}”
exit 1
else
echo “Host erfolgreich erstellt mit ID: ${HOST_ID}”
fi
######################## This option is not renaming computer#####################
echo -e “\nSchritt 1b: Setze chgHostname + forceReboot…”

JSON_AD_REBOOT=‘{
“chgHostname”: 1,
“forceReboot”: 1
}’
######################## This option is not renaming computer#####################
curl -s -X PUT
-H “Content-Type: application/json”
-H “fog-api-token: ${GLOBAL_API_TOKEN}”
-H “fog-user-token: ${USER_API_TOKEN}”
-d “${JSON_AD_REBOOT}”
“${FOG_SERVER_ADDRESS}/host/${HOST_ID}” > /dev/null

echo “Hostname-Änderung und erzwungener Reboot wurden aktiviert.”

echo -e “\nSchritt 2: Weise Snapins zu Host ${HOST_ID} zu…”
SNAPIN_JSON_ARRAY=“[”
FIRST_SNAPIN=true
for SNAPIN_ID in “${SNAPIN_IDS_ZUZUWEISEN[@]}”; do
if [ “$FIRST_SNAPIN” = false ]; then SNAPIN_JSON_ARRAY=“${SNAPIN_JSON_ARRAY},”; fi
SNAPIN_JSON_ARRAY=“${SNAPIN_JSON_ARRAY}${SNAPIN_ID}”
FIRST_SNAPIN=false
done
SNAPIN_JSON_ARRAY=“${SNAPIN_JSON_ARRAY}]”

JSON_PAYLOAD_UPDATE_SNAPINS=‘{
“snapins”: ‘${SNAPIN_JSON_ARRAY}’
}’

UPDATE_SNAPIN_RESPONSE=$(curl -s -w “\nHTTP_STATUS_SNAPIN:%{http_code}\n” -X PUT
-H “Content-Type: application/json”
-H “fog-api-token: ${GLOBAL_API_TOKEN}”
-H “fog-user-token: ${USER_API_TOKEN}”
-d “${JSON_PAYLOAD_UPDATE_SNAPINS}”
“${FOG_SERVER_ADDRESS}/host/${HOST_ID}”)

echo “Snapin Update Antwort: ${UPDATE_SNAPIN_RESPONSE}”
if [[ $(echo “${UPDATE_SNAPIN_RESPONSE}” | grep “HTTP_STATUS_SNAPIN:2”) ]]; then
echo “Snapins erfolgreich zugewiesen oder Anfrage verarbeitet.”
else
echo “Fehler oder unerwartete Antwort beim Zuweisen der Snapins.”
fi

echo -e “\nSchritt 3: Starte Image Deployment auf Host ${HOST_ID}…”

JSON_PAYLOAD_DEPLOY_TASK=‘{
“taskTypeID”: ‘“${DEPLOY_TASK_TYPE_ID}”’,
“shutdown”: ‘“${SHUTDOWN_AFTER_TASK,}”’,
“pending”: false
}’

DEPLOY_TASK_RESPONSE=$(curl -s -w “\nHTTP_STATUS_DEPLOY:%{http_code}\n” -X POST
-H “Content-Type: application/json”
-H “fog-api-token: ${GLOBAL_API_TOKEN}”
-H “fog-user-token: ${USER_API_TOKEN}”
-d “${JSON_PAYLOAD_DEPLOY_TASK}”
“${FOG_SERVER_ADDRESS}/host/${HOST_ID}/task”)

echo “Deploy Task Antwort: ${DEPLOY_TASK_RESPONSE}”

if [[ $(echo “${DEPLOY_TASK_RESPONSE}” | grep “HTTP_STATUS_DEPLOY:2”) ]]; then
echo “Image-Deploy-Task erfolgreich gestartet.”
else
echo “Fehler beim Starten des Deploy-Tasks.”
fi

Cheers
Chris

In the packet you may need to expand the dhcp section. You should see the image similar to below. What is important is the next server IP address should point to IP address of your fog server. and boot file name should be ipxe.efi. You see in this example that the boot file name was not given, this is the error with this packet. The next server and boot file are in the ethernet header. This is the legacy bootp pxe section.

The next place you need to check is the dhcp options below. You should see dhcp options 66 which should be the IP address of the fog server and dhcp 67 should be the boot file name of ipxe.efi. In this picture this packet is also in error since the dhcp server is not sending out all of the pxe booting info. So if your offer packet looks like this you have a problem.

Screenshot from 2025-05-07 17-14-20.png