UEFI booting with Surface book 4

[m144]

Hello,

I have been following a few posts on UEFI booting Surface books / Lenovo laptops…

I have successfully gotten a Surface book 4 to PXE boot and take an image, boot windows, etc using one of the ipxe.efi files that are in the FOG repository.

My current problem is it only gets past “Starting eth0 interface and waiting for the link to come up” about 10-20% of the time(This is only happening on UEFI devices) Is there a different .efi file somewhere that I should be using instead… is the ipxe.efi file even the problem?

Please let me know whatever needs testing… I will test whatever I can to the best of my ability. I have been using FOG since back in the 0.32 days. FOG has saved me so much time and I appreciate all that the FOG team does. We have many different devices I can test for you devs and would love to do whatever I can to get FOG & UEFI playing nicely with each other

Background Information:

FOG Server:
OS = Debian 9.1
FOG Version = 1.4.4
bzImage Version: 4.11.0
bzImage32 Version: 4.11.0

Surface Book 4:
Surface dock being used to PXE boot
Image is Win 10 Pro 64bit UEFI
Secure Boot = off

Network: (Note… I am not a network person, just systems)
Cisco Meraki everything
We have a separate DHCP scope setup just for FOG UEFI testing so we can change the Bootfile Name whenever without affecting others.

Not sure if I am forgetting anything? Please let me know if you have any suggestions or would like some testing done.

Thanks,

[george1421]

For fog 1.4.4 and the surface pros please try this pxe boot file: ipxe7156.efi With the kernels included with FOG 1.5.0 (not out yet) the iPXE guys (different open source project) addressed the issue where ipxe.efi wasn’t working with the surface pros.

[Avaryan]

For mine, I use the USB NIC that came with the Surface 3. After selecting image to boot and restarting into another iPXE boot I have unplug it right after you get the message about random number generation. Wait a second then plug it back in.

With those docking stations, I could get to the FOG menu, but couldn’t get the device to image.

[Sebastian Roth]

@Avaryan For the USB plugin/plugout issue there is a kernel parameter you wanna set in the host settings: has_usb_nic=1

@m144 said:

My current problem is it only gets past “Starting eth0 interface and waiting for the link to come up” about 10-20% of the time

Possibly try the same kernel parameter I mentioned above. As well grab an old mini switch (dumb, unmanaged) and hook that up as an intermediate switch just for the surface. In case spanning tree or auto negitiation or EEE are an issue the intermediate switch will mask that. Just for testing of course.

[m144]

@george1421 I went ahead and updated to kernel Version: 4.12.3 and switched back to ipxe7156.efi.

I am still getting the same message (altho the keyboard works now)… I have tried the kernel parameter has_usb_nic=1 and adding an old, dumb, unmanaged switch that @Sebastian-Roth mentioned but NOT with the new kernel.

I will give it a go this morning and report back.

[george1421]

@m144 said in UEFI booting with Surface book 4:

“Starting eth0 interface and waiting for the link to come up”

Just for clarity, you are seeing this message before the FOG iPXE menu is displayed?

[m144]

@george1421 Its right after “Initializing random number generator…”

[george1421]

@m144 Ah, OK. This is in FOS not iPXE. Well that gets my head screwed on right now.

OK so you can ignore any of the iPXE (ipxe.efi) issues.

This is an issue with the FOS kernel, not supporting the hardware.

What device are you using for the network adapter? Exact mfg and model?

Also, I need you to collect some info for us.

1. Manually register this computer and network adapter (you will need the mac address of the adapter for this).
2. In the FOG Webgui schedule a capture or deploy, at this point we don’t care. Before you hit the submit button, check the debug check box and then submit the task.
3. PXE boot the target computer after a few screens of text on the target computer it should dump you to a linux command prompt.

[george1421]

@george1421
4. From here key in ip addr show and see if the FOS engine picked up an IP address.
5. If no IP address is collected then key in lspci -nn|grep net and post a screen shot of the data.

[m144]

@george1421 Attached is the requested screenshots.

I repeated steps 4 & 5 a few times over and it was a 50/50 on getting an IP address. (is it just me or is that a bit odd?)

Note: This is through the dumb switch + spanning tree & auto-negotiation off. I could not find any EEE settings in the Cisco Meraki dashboard… I wish we had just normal Cisco switches!

(Image 1 No-IP addr)

(Image 2 Yes-IP addr)

(Image 3 Surface Book 4 Dock Model 1661)

[george1421]

@m144 This IS really strange. Without knowing what you went through, I would say this is a spanning tree issue, where one of the fast protocols isn’t being used. But at the same time I’m confused why the wireless adapter is being displayed, unless the wireless and ethernet adapter are one and the same.

Are you sure that unmanged switch is really dumb? If its a business class unmanaged switch it may have spanning tree enabled by default. I also may be trying to apply logic to where there is none.

With default spanning tree the port will start forwarding data after 27 seconds from the last transition of the link light if that has any bearing on the success of the ip addr show command or not.

[m144]

@george1421 Attached is a picture of the current setup with a:

TP-Link TL-0SG1008D switch (Not the new model they have out rn, also the dumbest switch I could find in the office… works about 90% of the time now)
A Surface Book Dock (Model 1661)
A Surface Book 4 (Model 1703 according to the Surface UEFI about page)
The white cable coming into the TP-Link switch is the uplink from a Cisco Meraki MS-22 switch
The blue cable just goes from the TP-Link to the Surface Book dock.
Then Dock to Surface Book through Microsofts proprietary connector

As for: @george1421 said in UEFI booting with Surface book 4:

But at the same time I’m confused why the wireless adapter is being displayed, unless the wireless and ethernet adapter are one and the same.

I feel the same about this… Not sure why only the wireless adapter is being displayed! The only LAN connection that I know of is coming from the Surface Dock. Also, I have not seen anything saying that the surface has a passthrough NIC built into it like a lot of newer Lenovos have. So for some reason lspci -nn|grep net is not showing the NIC for the Surface Dock.

I think at this point we are going to purchase and test a few dumb switches along with this usb 3.0 gigabit ethernet adapter that “Supports Legacy PXE (eHCI and xHCI) & UEFI PXE” (we will see about that! :))

Anyways, Those new toys should be in some time next week… I will test things out and let you know what I come up with. Let me know if you have any other suggestions in the meantime.

Thanks for all the help

[Sebastian Roth]

@m144 said in UEFI booting with Surface book 4:

Then Dock to Surface Book through Microsofts proprietary connector

I guess this is key to why we don’t see the NIC in lspci output! It’s not connected through PCI that’s for sure. You might see it in lsusb. Let’s hope it’ll show up there!

[m144]

@sebastian-roth Sorry for the late reply, Looks like it is “045e:07c6”

The first lsusb is with no doc the second lsusb is with doc.

[Sebastian Roth]

@m144 Thanks for that. OMG, how many new USB devices are there just by plugging into the dock. Yeah the ID 045e:07c6 seems about right. Though this has been added to the kernel (official and our custom build one) source code long ago.

Re-reading what you said before I feel this is a really hard one to nail down. Seems like we have the driver right in the kernel and it does come up with an IP part of the time but not always. Not really sure where to go from here. Hmmmmm