I also tried going back to master branch and rebuilding iPXE, utilizing kernel 5.15.93 that it came with as well as the latest 6.12.25 kernel and both are giving me the same error as well.

@george1421 Thank you for your response. The following is what I completed this morning. I switched my FOG environment from master branch to dev-branch so that I could utilize the 6.12.35 kernel. I then marked down my iPXE build code as “g47159”. I worked through your steps of rebuilding iPXE and then re-ran the installation script. I rebooted and confirmed the Dell laptop I’m trying to image is getting iPXE build code “g634d9” now, but I still get the same error message as before.

I’m going to swap back to the master branch and do this all over again to see if that works better or not, but I imagine I’ll see the same issue. Thank you again for your continued support on resolving this.

I would like to hopefully piggy back off this thread because I am getting the same error in the screenshot when trying to image or register the machine, but if I need to create a new thread I will.

I have some Dell Pro 13 Plus with Intel Core Ultra 5 processor and get this same error. I have tried the current master branch 1.5.10 with kernel 5.15.93 and also tried master branch 1.5.10 with 6.12.25 kernel. I then tried the dev-branch 1.5.10.1667 with no luck and then did dev-branch with kernel 6.12.35 with no luck.

Can anyone recommend some other things to try? I’m running out of ideas and time. Any ideas or help is greatly appreciated.

The issue looks to be fixed since I changed the boot file name. This thread can be marked as closed/solved. Thanks again for everyone’s help.

@george1421 Got it. I’ll be sure and put all this down in my notes if I see another issue down the road. I appreciate your help.

@george1421 Thank you for your help and insight. I confirmed with the models that don’t work (as well as the models that do to compare BIOS’s) that they are using legacy mode and not using secure boot etc. I am using the built in Ethernet port into the laptop or desktop, no kind of docking station. In response to @Sebastian-Roth post, I changed my bootfile name from undionly.kpxe to ipxe.pxe and got at least the E6440 model to boot into the Fog menu. So i’m off to try the others.

@sebastian-roth You are THE man. I changed my DHCP option from undionly.kpxe to ipxe.pxe and my E6440 booted right into the FOG menu. I’m going to try the other models later this morning to see if they are working as well. I’ll reply back to this thread if it gets everything working. This is a promising start!

Server

• FOG Version: 1.5.0-RC-6
• OS: Ubuntu

Client

• Service Version: ?
• OS: Windows 7

Description

I’m having issues booting some of my machines into Fog. But some work. For instance, I have a ThinkPad L440 model that boots into the Fog menu fine. My VM’s I use for creating images still boot into Fog fine. But I have a Dell Latitude E6440 and another model that do not boot.

For troubleshooting, I updated my Fog environment to 1.4.4 (latest stable release) and that did not help. So I went ahead and upgraded it to 1.5.0-RC-6 (latest trunk version) and that did not help either. I also tried upgrading the BIOS on the Latitude E6440 to the latest and that didn’t help either. I’ve tried different cables, different networks, different computers with the same model etc.

Posting here is my last resort. I’m not sure if there are logs on the Fog/Ubuntu server that will tell me why it won’t boot into the Fog menu or if there is something else with legacy/UEFI boot modes. Or if the iPXE boot menu or boot exit settings need to be something different. I need help. Picture attached is what my machines get when trying to PXE boot into Fog.

Good morning, Tom. The .msi file for Google Chrome is roughly 43 MB. Although I did follow the wiki on editing the php.ini file and increasing the “memory_limit”, “post_max_size”, and “upload_max_file_size” to 1900 M.

Could I have screwed up the php.ini file and it’s causing this issue somehow? I (of course) didn’t make a backup before editing it, but i’m sure I can find a default, out-of-the-box php.ini to replace it with.

Thanks for the reply Joseph. I have tried that as well, but it still says queued, so I don’t think it’s my syntax causing the issue.