Dell OptiPlex 5080 - Fails at connecting with boot.php

[george1421]

@rav What is your uefi boot file for this computer? ipxe.efi or snponly.efi? If you are not using snponly.efi, lets try that. I would think we should see an error message about network before now

Also make sure your firmware is up to date on the 5080.

The booting process goes tftp loads ipxe, ipxe then gets an IP address and chains to the fog server and picks up default.ipxe, which then chain loads boot.php. If 192.168.1.7 is your fog server, if you call that url from a web browser does it give you a bunch of text that makes up the iPXE menu?

You say that other computers work just fine, are they on the same subnet as this computer that is failing.

I can’t understand why dhcp, pxe, tftp are working but its failing for http, unless 192.168.1.7 is not your FOG server.

[RAV]

@george1421 I’m trying to figure out how to answer your questions, but I’m very new with this system so bear with me haha

192.168.1.7 is our FOG server, yeah.

Everything should be on the same subnet. I have several ethernet cables and even tried some of the same ones that worked on other computers, still nothing.

Well, as for pulling up 192.168.1.7, it doesn’t pull up on my own computer but it does on the FOG computer, though it just pulls up the actual FOG dashboard to work from. It isn’t connected to an outside network.

I’ll check that the computer’s firmware is up to date.

I’m not sure how to choose between ipxe and snponly, or where to find either of those, but I’d be willing to try it all the same.

[george1421]

@rav Sorry about my questions being all over the place. This issue is very strange because some of the communications work and other protocols do not. SO I’m approaching the problem from a few different ways to keep the rounds of 20 questions down.

In your screen shot iPXE is running (probably ipxe.efi). So that means the two devices can talk together (target computer and FOG server) because ipxe.efi file made it to the target computer and its running. ipxe.efi is also able to talk a second time to get the file default.ipxe. But the third time now using http its failing to load boot.php.

So connecting to http://192.168.1.7/fog/service/ipxe/boot.php?mac=00:00:00:00:00:00 Connects you to the dash board or the text that makes up the iPXE menu (hint the text should start out with #ipxe)?

Just to be clear all other computers work, its just these 5080 that are failing?

ipxe.efi or snponly.efi these values are set by your dhcp server. What device is the dhcp server for this 5080 target computer?

[RAV]

@george1421 You’re all good with your questions! I’m just kinda feeling my way through this. I inherited FOG from a previous employee who basically left no instructions and very little crosstraining with other employees. I’m in my third week here so this system’s still very new.

I pulled up the ipxe page, starts with #ipxe like you said.

And yeah, it’s just the 5080.

I’ll have to get back to you on the dhcp once I figure that out.

[george1421]

@rav I just thought of something. Did by chance someone setup https on this server? This would have been done when FOG was installed. Look at the browser does it say https when you connect to the web ui of FOG? Someone switching to https protocol incorrectly would cause this exact error. But it should be with every pxe boot not just with the 5080s.

[RAV]

@george1421 Naw, looks like it’s still http. Good thought though! Also sorry I haven’t been able to get you further information, I’ve been working on software all day and my coworker has been busy as well, so we haven’t had any time to test that 5080 machine.

[RAV]

@george1421 Okay, update. We’ve updated the firmware, BIOS, anything my coworker could think to update as far as the actual Dell itself goes. Still not working. We also closed the FOG image and opened a fresh one and tried to see if that would work and still nothing.

My coworker is looking into trying out snponly.efi.

[george1421]

@rav While this is a long shot, if you have one of those cheap 5 port discount network switches, try placing that between the target computer and the building network switch. While I really doubt this is a spanning tree issue, that conditions are similar. We have to be missing something here.

You get the same response if you put the 5080 on the same network switch as the FOG server (thinking something in the infrastructure is doing this)?

You know I didn’t ask what version of FOG you are using?

Lastly if snponly.efi doesn’t work I wonder if we compile ipxe with the latest code to see if that addresses the issue. (understand I’m really reaching for a solution now. This condition should not exist).

[RAV]

@george1421 Man I really appreciate your interest in this issue, thanks for your help with this.

I’ll see if we can try the switch option, though we might have already inadvertently done that. I’ll check if our process meets those conditions.

I know we have an older version of FOG, but honestly… everyone has been afraid to update anything on our FOG imaging machine in case it breaks. We all have pretty rudimentary knowledge of how the system works and how it was initially set up and whatnot. /: And we’re on kind of a time crunch so we haven’t had time to try like… taking a copy of the current versions and trying to update and just restoring the old image if there are problems.

So, about snponly.efi… Could you point us in the right direction for how to actually use snponly.efi?

[Sebastian Roth]

@rav said in Dell OptiPlex 5080 - Fails at connecting with boot.php:

So, about snponly.efi… Could you point us in the right direction for how to actually use snponly.efi?

In your DHCP server there are PXE boot options set, option 66 pointing to the FOG server IP and option 67 is the filename. That’s probably set to ipxe.efi for UEFI machines. Set snponly.efi instead and see if this makes a difference PXE booting the 5080.

[RAV]

@sebastian-roth I’ll bring this up to my coworker and see if he knows enough about the system to try this. However, we may have had a new development…

@george1421 We ended up booting the computer to the OS installed in it and we did some tests and it turns out that there might be something wrong with the physical network port itself. Plugging it into an outside network, there’s no internet connection available, and looking at the port itself it shows an orange light.

On Monday we’re going to open it up first and see if there are any physical connection issues, and if we can’t see any, we’ll use a different process to load a Windows OS onto it and try to see if there are any driver issues or driver updates that might solve the problem.

If the connections look fine and the drivers don’t help, we may just have a dead network port. /: And unfortunately this model only has one network port. Will update after we’ve done further tests.

[george1421]

@rav Interesting. Even if you have an older version of fog (you didn’t mention the version) you should be able to recompile ipxe to get the latest ipxe code (even newer than the latest release of FOG). We’ve had to do that for a few other issues to get iPXE to talk to the hardware properly.

Its interesting that you might have a LOM nic issue. Let us know how it goes with testing next week.

[RAV]

@george1421 So, it’s fixed!

My colleague uploaded a basic version of Windows on it and updated drivers on the computer, and when he went to actually image it with FOG it ended up working.

This model only has one network port, so if that doesn’t work then you’re gonna see some issues, worth keeping in mind for anyone else who may run across this problem with this model of Dell.

[george1421]

@rav said in Dell OptiPlex 5080 - Fails at connecting with boot.php:

My colleague uploaded a basic version of Windows on it and updated drivers on the computer, and when he went to actually image it with FOG it ended up working.

I find this encouraging and perplexing at the same time. How would windows drivers impact imaging at this stage? Windows is not involved with the error in your initial post. If there was a firmware update I might understand. The other possibility is that if you warm restart from windows into FOG imaging its possible that windows left the hardware in a good state where iPXE was able to use the hardware. It is very strange that you have it working this way. But if it works and is repeatable I guess you should run with it. Good job finding a solution!

[RAV]

@george1421 Yeah, it seems it was the drivers for the ethernet port itself that needed to be updated. So weird. You’d think that would have been tested before the device was even shipped out, too, but evidently not… It really is an odd one.

Thanks for sticking it out with us! The help is much appreciated.