UEFI imaging
-
Server
- FOG Version: 1.3.5
- OS: Centos 7.2
Client
- Service Version:
- OS: Windows 10
Description
When I try to register a new Dell E 7740 laptop with UEFI enabled, I got an error when they try to register. I follow the guide for UEFI co-existence and make a Policy with UEFI and fix the name to ipxe.efi.
The laptop seems to get an IP address but can’t do Nothing after that.
Here is a snapshot of the error
If I manually register the machine and try to take a capture, it’s stay on “attempting to check in”
Thanks
-
While this is a new one for us, and I don’t think this is the case, can you try pxe booting again on this device, but this time place a dumb (unmanaged) switch between this computer and the building switch. Then try to pxe boot the computer.
The uefi/bios coexistence part IS working, because the FOS Engine (the customized linux OS used to capture and deploy images) has made it to the target computer. So the whole ipxe.efi / undionly.kpxe stuff is behind us.
I guess I have to ask, is 172.20.50.5 and appropriate dhcp address for this pxe booting computer?
Is it safe to assume you have a windows dhcp server that is issuing ip addresses for this pxe client?
-
@george1421
Hi, I try with a different computer who’s not registred. The pxe seems to be fine as you said, I got the PXE menu, when I choose to perform a full registration I got the same error.The IP address obtained is the same as when the computer boot in Windows.
Yes my DHCP server is a Windows 2012 server and is set for all clients, Windows or PXE
-
@gchartrandCRL Can you repeat the process, but place an unmanged switch between the computer and your building switch. I don’t think this will resolve your issue, but we need to rule out spanning tree doing this to us.
-
@george1421
Hi, if I put a unmanaged switch, the network getting up faster. If I leave in on my Cisco managed switch, with spanning tree turning off, I can’t have a DHCP offer, with spanning tree portf I have a DHCP offer.But I’ve just realize too that I recently migrate my fog server to another server because I was unable to perform an in place upgrade of the old one. But at one place in the config, the old ip was still documented. So two problem was present
-
@gchartrandCRL Sorry I’m not grasping the english language here very well.
Part 1
If you install an unmanaged switch between the target computer and the building switch the target computer loads FOS without issue?If this is the case, on your cisco switch turn on one of the fast spanning tree protocols, RSTP, MSTP, FastSTP, etc. This will allow the port to start forwarding data right away then listen for any BPDU announcements. You really shouldn’t disable STP on your switch ports or a loopback may not be detected.
Part 2
You upgraded/created new fog server and there were some old settings left behind in the configuration that pointed to your old fog server?Part 3
Is everything now working with fog? -
@george1421
Hi,
Part 1: Yes it’s working. The setup for spanning tree is pvst (per vlan) I change it for rapid-pvst. My only option is mst, pvst or rapid-pvst.Part 2: Yes the Web and TFTP server was still on the old IP Address
Part 3: Yes.
thanks for your help
-
@gchartrandCRL We provide “10 second delay” ipxe files as well to help with the “slow to receive IP address” issues as well. This isn’t an end-all-be-all fix of sorts, but mainly meant to help in situations that I’m understanding you’re kind of seeing.
Rapid-PVST is helping you with the managed switches but you still require the intermediary switch to connect fully?
-
@Tom-Elliott
No, no need an intermediate switch. If I turn-off spanning tree, yes I need to put a intermediate switch, but if it’s on, it’s working.
