Hi everyone,

I’ve been trying to follow this awesome tutorial (thank you to @george1421, btw ) because it looks promising, and I’ve got my setup partially working as I’m able to boot iPXE and refind, I’m even able to take an image of my added host, I’m able even to boot Windows from the firmware boot menu… However… the default entry in refind (“Boot from hard disk”) is not working, not sure what’s actually running this entry, … but it’s not able to boot the actual hard disk. In fact it has a weird behavior … because apparently that entry is trying to load refind, but you can see in this video it’s not able to fetch refind.conf.

Anyway … I’m a little bit confused … because if I press s to get into de iPXE shell, and run manually

imgfetch http://<my-fog-ip>/fog/service/ipxe/refind.conf
chain -ar http://<my-fog-ip>/fog/service/ipxe/refind_x64.efi

It seems to work… but I have again the very same menu. So … some idea about what could be happening or how may I debug this behavior?

Thank you very much!

PS: I’d suggest some minor fixes for @george1421 tutorial, but it’s a closed topic … so not sure if those might be fixed

@george1421 well, after some tests … The problem is apparently I have to sign also the refind_x64.efi binary, not sure if refind.efi is actually loading refind_x64.efi … but I’d suggest also to include this point in your tutorial. In fact I’m guessing you should also sign refind_ia32.efi and refind_aa64.efi as your whole environment could include also another archs.

Not sure if you’ll edit your tutorial with my suggestions … but I’ll write a little document for myself also … I think the signing process (with sbsign) may be automated in a bash script with a for loop, but your tutorial is still very valuable and helpful. This would be just a minor improvement. However … I think I’m going to write some script to try to automate the whole process, I could send it to you if you are interested in

Thank you again @george1421 and I hope you find also useful my suggestions

Hi @george1421! Thank you for your answer

Well, I think the very same, so not sure if I should repeat the whole process (including FOG initial deployment/install), but sure, this wouldn’t seem a SecureBoot problem if it weren’t because of this setting in the firmware

I can see your firmware hasn’t that Secure Boot submenu, so … not sure how this could be interfering … but I’m having this issue when I set this in Deployed Mode. However, Audit Mode works as I expect, and … according to the description in my screenshot I’d say the proper value for production is Deployed Mode, and this should work in a very similar way Audit Mode does.

So not sure if this has something to do with some kind of network misconfiguration.

The most important fixes I’d suggest to your tutorial are the following, btw:

• You actually don’t need to mv dbx.esl dbx-fog.esl as you are not generating any dbx.esl, you cannot even run that command successfully as dbx.esl file doesn’t exist
• Also the param chain tftp:/${fog-ip}/EnrollKeys.efi for fog.keyenroll should actually be chain tftp://${fog-ip}/EnrollKeys.efi

Aside this … the tutorial is so helpful so … congratulations @george1421 and thank you a lot for your answer again.

@Tom-Elliott oh, sorry, I didn’t notice this big yellow button in the General tab

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

@Tom-Elliott

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

172.120.1.253:443 172.120.1.195 - - [09/Oct/2025:18:47:03 +0800] "POST /fog/service/Pre_Stage1.php HTTP/1.1" 500 3891 "-" "curl/8.14.1"
172.120.1.253:443 172.120.1.195 - - [09/Oct/2025:18:47:08 +0800] "POST /fog/service/Pre_Stage1.php HTTP/1.1" 500 3891 "-" "curl/8.14.1"
172.120.1.253:443 172.120.1.195 - - [09/Oct/2025:18:47:13 +0800] "POST /fog/service/Pre_Stage1.php HTTP/1.1" 500 3891 "-" "curl/8.14.1"
172.120.1.253:443 172.120.1.195 - - [09/Oct/2025:18:47:18 +0800] "POST /fog/service/Pre_Stage1.php HTTP/1.1" 500 3891 "-" "curl/8.14.1"

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

[Thu Oct 09 18:48:29.019424 2025] [proxy_fcgi:error] [pid 1662:tid 1662] [client 172.120.1.195:59922] AH01071: Got error 'PHP message: PHP Fatal error:  Uncaught ValueError: min(): Argument #1 ($value) must contain at least one element in /var/www/html/fog/lib/fog/image.class.php:396\nStack trace:\n#0 /var/www/html/fog/lib/fog/image.class.php(396): min()\n#1 /var/www/html/fog/lib/reg-task/taskqueue.class.php(112): Image->getStorageGroup()\n#2 /var/www/html/fog/service/Pre_Stage1.php(24): TaskQueue->checkIn()\n#3 {main}\n  thrown in /var/www/html/fog/lib/fog/image.class.php on line 396'
[Thu Oct 09 18:48:34.062774 2025] [proxy_fcgi:error] [pid 790:tid 790] [client 172.120.1.195:52762] AH01071: Got error 'PHP message: PHP Fatal error:  Uncaught ValueError: min(): Argument #1 ($value) must contain at least one element in /var/www/html/fog/lib/fog/image.class.php:396\nStack trace:\n#0 /var/www/html/fog/lib/fog/image.class.php(396): min()\n#1 /var/www/html/fog/lib/reg-task/taskqueue.class.php(112): Image->getStorageGroup()\n#2 /var/www/html/fog/service/Pre_Stage1.php(24): TaskQueue->checkIn()\n#3 {main}\n  thrown in /var/www/html/fog/lib/fog/image.class.php on line 396'
[Thu Oct 09 18:48:39.106621 2025] [proxy_fcgi:error] [pid 1461:tid 1461] [client 172.120.1.195:52776] AH01071: Got error 'PHP message: PHP Fatal error:  Uncaught ValueError: min(): Argument #1 ($value) must contain at least one element in /var/www/html/fog/lib/fog/image.class.php:396\nStack trace:\n#0 /var/www/html/fog/lib/fog/image.class.php(396): min()\n#1 /var/www/html/fog/lib/reg-task/taskqueue.class.php(112): Image->getStorageGroup()\n#2 /var/www/html/fog/service/Pre_Stage1.php(24): TaskQueue->checkIn()\n#3 {main}\n  thrown in /var/www/html/fog/lib/fog/image.class.php on line 396'

The php version the server is running is:

# php --version
PHP 8.2.29 (cli) (built: Jul  3 2025 16:16:05) (NTS)
Copyright (c) The PHP Group
Zend Engine v4.2.29, Copyright (c) Zend Technologies
    with Zend OPcache v8.2.29, Copyright (c), by Zend Technologies

@Tom-Elliott sure, I’m forcing the task and this is causing the issue, just the ability or feature “force task” by itself doesn’t cause the issue, is just when I use it, if I let the task to be run by itself in the scheduled time or if I reboot the machine manually the capture is performed as expected.

Let me check the apache logs when this issue arises.

@Tom-Elliott Thank you for your reply … Could you provide more info on how to do this with a group? I’ve created a new group but can’t find any feature like “resetting the encryption data” anywhere, I’ve been looking into the HOST features and cannot find anything like that there either.

Thank you again

Unfortunately I had to reinstall FOG recreating the CA cert so … I’m forced to reinstall the clients in all my machines, the thing is … I’ve noticed when I reinstall the client I can see authentication problems due to the token.dat file … The only way I found to fix this problem is by deleting the HOST in the FOG web UI and letting the client to recreate it to be approved in the web UI. Is there a clean/proper way to reinstall the client (to refresh the CA) without having this issue?

Thank you very much guys

Ok, definitely I think I’ve found the issue. Apparently the problem is caused by this feature of forcing the task,

if I let the client to restart the machine at the time the task is scheduled or if I restart manually the machine … this problem doesn’t arise.

Why do you this this feature is causing these attempts to check in to fail?

Hi everyone, I’m trying to upgrade my FOG server instance, but particularly I also need to recreate my CA and server cert, so what I’ve tried is:

• git fetch --all in my fogproject clone of the github repo
• git merge (over the stable branch, ofc)
• then I’ve run bin/installfog.sh -C -K

All seems to work properly, I can even register HOSTs without problem, but … When I try to capture an image of some HOST I just can see a lot of

* Attempting to check in............................Failed

I’ve been searching for similar issues in the forum and I saw a few posts, of course I’ve checked my FOG_WEB_ROOT is properly set to /fog and indeed it is. In fact, I’ve not touched this setting and before upgrading it was working properly, so I’m not sure what could be happening in the upgrade process.

Thank you very much guys.

@Tom-Elliott said in Fog iPXE Menu no input:

Either way, similar to the post about bisect, below, might help us out as well.

I’d need more details, some article or document on how to perform this bisect, but I’m interested in contributing, sure

@Tom-Elliott said in Fog iPXE Menu no input:

@jfernandz next-server comes from the dhcp server option 66 (I think that’s what it is in Windows DHCP at least?)

That said, often when next-server is empty it’s usually because there’s multiple dhcp servers trying to tell the same single client their next-server and it doesn’t know which one to use, so it just goes blank. That’s not to say it couldn’t be a firmware issue, but just expressing my past experiences.

Hmm … my problem isn’t an empty value for next-server, rather … it comes with an IP, but its the DNS server IP address! …

Regarding the keyboard issue … we are working with Dell Precission 3930 Rack machines, but we also have in the same cluster a couple of Dell Precission 7960 Rack machines where I didn’t tested, I can say a couple of days ago, we upgraded the BIOS of the 3930 which are the ones I can detect this issue, that’s why I was guessing this could be a problem between iPXE and upgraded firmware

I’m experiencing the same problem with keyboard input, in fact the keyboard input doesn’t work either till the OS boots, it doesn’t work in Grub, I feel like if iPXE were having a kind of issue with the firmware.

Also I’ve noticed … I’ve had to replace ${next-server} in the ipxescripts files with the actual FOG Server IP as it seems iPXE isn’t able to retrieve this value from the DHCP service in the FOG Server. Not sure if the firmware issues could be causing this also.