Dell 7010 Lenovo L530 with UEFI enabled, won't network boot.

[Wayne Workman]

@Sebastian-Roth https://drive.google.com/file/d/0B2BmriqzYEgXSVBoTWhXTkd0RlU/view?usp=docslist_api

That’s with using this particular file:

@Sebastian-Roth said:

Here is a new binary that should bring you to an iPXE shell and have debugging enabled: 0_1447518970841_realtek.efi (DEBUG=realtek,netdevice)

[Sebastian Roth]

@Wayne-Workman Thanks a lot for trying. I am really confused. Why don’t we see any debug messages? Why does it pop straight back to EFI instead of opening iPXE shell?
Have you tried Tom’s latest realtek.efi binary yet? The gotosetserv issue is fixed as far as I can see in the source. Does it jump straight back to EFI as well?

[Sebastian Roth]

Thinking about this and trying different things I somehow got the impression that DELL OptiPlex 7010 does not have realtek but intel NIC. Can you please check and confirm this?

Here is an intel binary with debugging enabled: 0_1447932660735_intel.efi (DEBUG=intel,netdevice,device,pci)

And here is another ipxe binary. Please give this a try as well: 0_1447932787631_ipxe.efi (DEBUG=device,pci,snp,snponly,snpnet,netdevice)

[george1421]

FWIW: All of the 7010 SFF Dells we have have “Intel 82579LM Gigabit Network Connection” according to our inventory tool.

[Wayne Workman]

@Sebastian-Roth Guess what I just figured out?

Changes in Windows Server 2012 DHCP are not immediate.

I have it set to ipxe.efi currently for the vendor class PXEClient:Arch:00007

I just did a packet capture on the dhcp server using wireshark… the client asked for realtek.efi… Oh boy…

[Wayne Workman]

Even after restarting the DHCP Server service, it is still handing out realtek.efi even though it’s set for ipxe.efi

[Wayne Workman]

So - the previous confusion in the last two posts were due to our split-scope configuration, and DHCP coming from offsite. I’ve had that disabled. I’m getting much more consistency with testing, wireshark confirms my settings as well.

I’ve also learned that the problem machine (optiplex 7010) needs fully shut off and re-started in order for it to use the new DHCP settings - even though it says it’s “Starting IPv4” and supposedly gets DHCP info… so… Total shutdown and startup for every change from now on…

That could also explain some other things too…

---

I’ve tried the latest ipxe.efi and intel.efi from trunk and those don’t work. They sit at “initializing devices…” for both.

About to try the binaries @Sebastian-Roth posted.

[Sebastian Roth]

@Wayne-Workman said:

I’ve also learned that the problem machine (optiplex 7010) needs fully shut off and re-started in order for it to use the new DHCP settings

Not only DHCP settings I reckon. I think I even had one of my machines reusing the iPXE binary it still had in memory. Had to switch it off and on again to make it request the file via TFTP again…

Did you get to try out the binaries? Any output??

[Wayne Workman]

https://drive.google.com/folder/d/0B2BmriqzYEgXQk5tbWczVVdZeEE/edit

One video hasn’t uploaded yet. When it does it will appear in this folder. The files are labeled by voice in the video.

[Sebastian Roth]

Can’t stop scratching my head today. EFI is really complex and I am sure I haven’t been able to understand even a tiny bit of it. The PC I am testing EFI PXE boot with is a Fujitsu ESPRIMO P910 E85+ which comes with the exact same NIC as you have in your DELL OptiPlex 7010 (Intel 82579LM!!). But EFI PXE boot is working on my machine (ipxe.efi, intel.efi, snponly.efi)…

So I checked your video again to see what debugging output we see right from the start. And there might be something interesting there:

iPXE initialising devices...Adding 3c509 root bus
Adding EFI root bus
MII PciRoot(0x0)/Pci(0x19,0x0)/MAC(90b11c9bc14f,0x0) is an MII device
MII PciRoot(0x0)/Pci(0x19,0x0)/MAC(90b11c9bc14f,0x0) is an MII device
SNP PciRoot(0x0)/Pci(0x19,0x0)/MAC(90b11c9bc14f,0x0)/IPv4(0.0.0.0) is an SNP device
SNP PciRoot(0x0)/Pci(0x19,0x0)/MAC(90b11c9bc14f,0x0)/IPv4(0.0.0.0) is an SNP device
NETDEV net0 registered (phys SNP-0xd07eb518 hwaddr 90:b1:1c:9b:c1:4f)
NETDEV net0 could not add SNP device: Error 0x7f45e082 (http://ipxe.org/7f45e082)

All the other messages about NETDEV rejecting duplicate ... might just be caused as it tries to re-add the device over and over again.

If I boot the my last uploaded ipxe.efi debug binary on the Fujitsu I get:

iPXE initialising devices...Adding 3c509 root bus
Adding EFI root bus
PCI 00:19.0 (8086:1502) has driver "82579lm"
PCI 00:19.0 has mem f7100000 io f040 irq 11
PCI latency timer is unreasonably low at 0. Setting to 32.
NETDEV net0 registered (phys PCI00:19.0 hwaddr 00:19...)
NETDEV net0 link is up
Adding EISA root bus
Adding ...
...
Adding PCI root bus
ok

So where is the difference? Why is your DELL 7010 not able to register it as an intel NIC and tries SNP which fails (snponly.efi is working on my Fujitsu as well by the way!)??

[george1421]

Well this is either good or bad. I get the same results as Wayne using 7010 bios A18.

Not sure if this has any bering on anything. But I checked into the dhcp discover and the 7010s are sending out arch type 7. I noticed that there are two different arch types. One is 7 and one is 9. There is also a arch 6 for 32bit. I guess the question I have is what is the efi boot kernel that is being built?

Type Architecture Name
---- -----------------
0 Intel x86PC (BIOS pre-OS environment)
1 NEC/PC98
2 EFI Itanium
3 DEC Alpha
4 Arc x86
5 Intel Lean Client
6 EFI IA32 (UEFI 32 pre-OS environment)
7 EFI BC (UEFI 64 pre-OS environment)
8 EFI Xscale
9 EFI x86-64 (UEFI 64 pre-OS environment)

[Wayne Workman]

@george1421 A18 won’t work according to this: http://www.dell.com/support/article/us/en/19/SLN296756/EN

I’m using A12 for the record.

[george1421]

A18 will work as long as you turn off the legacy ROMS. I did see that post too, btw. I just had to try it and it worked with the same results as you. So no better or worse then.

[Sebastian Roth]

Is anyone keen to try another binary (different debug options)? I somehow feel that we are not getting anywhere with this…

[Wayne Workman]

@Sebastian-Roth Sure.

[Sebastian Roth]

According to this http://ipxe.org/7f45e082 the error should be happening within efi_utils.c… 0_1448292948783_ipxe.efi (DEBUG=efi_utils)

[Wayne Workman]

@Sebastian-Roth
https://www.youtube.com/watch?v=hsVUruALX8g

[Wayne Workman]

@Sebastian-Roth I noticed the very first two lines of output are unique.

I’ll try to get a clear picture of those.

[Wayne Workman]

@Sebastian-Roth This is as good as it’s going to get:

https://www.youtube.com/watch?v=DrEReJwsdJc

[george1421]

@Sebastian-Roth I have was able to capture the screen and uploaded it here (since this is the first time I tried this process, the relevant information is about 50% of the way through the video. And the video is quite large because of the cruddy codec I used. As they say better next time:

https://www.dropbox.com/s/7t22wb4354njp56/1448293078345_ipxe_efi.avi?dl=0

One thing I noticed is your description 0_1448292948783_ipxe.efi did not match the downloaded file 1448293078345-ipxe.efi.

[Edit] FWIW this video doesn’t play well in VLC but it does in WIndows Media player. Sorry [/Edit]