Several problems with Surface Pro 4

[Tom Elliott]

The has_usb_nic=1 should only be required if you’re running a USB Nic, and that NIC is recognized, but unable to get an IP address. That said, I doubt this is the issue you’re having, just trying to help lead you in the right direction.

This sounds, to me, that you’re not using the same files as suggested in the posts you’ve read thus far. In 1.3.0-RC-7, there are already files available for the Surface pro’s to boot from. They’re labeled in the /tftpboot/ folder and have the 7156 applied to the filenames so as to limit confusion of what they are.

You should also try different files. If ipxe7156.efi isn’t working for you, maybe intel7156.efi or realtek7156.efi may work. There’s also the snp7156.efi and snponly7156.efi files. I don’t know why the surface’s have a hard time booting and I’m fairly certain its something with the drivers from the 7156 version through current but I have not been able to get to a solid method of testing to narrow exactly when the problem occurred. This is primarily because I don’t have any of the surface pro’s myself, so I can’t tell if one file (or another) will or won’t work.

[george1421]

@Tom-Elliott said in Several problems with Surface Pro 4:

This is primarily because I don’t have any of the surface pro’s myself, so I can’t tell if one file (or another) will or won’t work.

I’m sure if someone wanted to donate a new Surface Pro 4 to the FOG Project the developers could figure out what is going wrong here… Just a suggestion…

[jhuesser]

@Tom-Elliott Thank you. Tried eveery *71556.efi file. Here is what I got:

• ipxe7156.efi was able to boot into the menu, Selected perform full host registartion. Got Failed to get an IP via DHCP and with
  has_usb_nic=1 I got Please unplug your device and replug it into the usb port. In both cases the keyboard is not regocnized and nothing happens if i press enter.
  
  

• intel7156.efiAfter loading the bootfile and iPXE starts, it said DCHP failed
  

• realtek7156.efi same as intel7156.efi

• snp7156.efi same as ipxe7156.efi

• snponly7156.efi same as ipxe7156.efi

Btw. the output text is “new” Hadn’t had this with ipxe.efi

Any ideas?

[Quazz]

I’m guessing the issue is due to the ethernet connection going through the keyboard dock thingy.

[george1421]

@jhuesser From the images you are getting into the FOS engine. So iPXE has done its part so no need to mess with iPXE files any more. So if you are getting to that point (in your first image), I would do the following:

1. Manually register that device (it you have not already)
2. Setup a debug capture sequence
3. PXE boot the device. It should launch into capture mode and then after a few enter key presses it will drop you to a linux command prompt. This is the FOS engine command line.

From there we can do some debugging like ip addr show Please post the output of that command here.

Also ensure that the network port this device is connected to has spanning tree turned off (not a good choice) or one of the fast spanning tree protocols enabled. (RSTP, port-fast, fast stp, etc). A quick test would be to place a dumb (unmanaged) switch between your building switch and the target computer. If you can pickup an IP address in this configuration you need to look into your spanning tree configuration on your building switch. What happens when the FOG boots a target device is that as the target boots, it winks (monetarily turns off and back on the network link) as each kernel hands off to the next kernel (i.e. PXE boot ROM-> iPXE and iPXE -> FOS Engine). The issue is that if STP is enabled it takes STP 27 seconds to move from listening to forwarding. By the time the link moves to forwarding, the FOG boot process has already given up.

[jhuesser]

@george1421 thank you. When i PXE boot the surface again with ipxe7156.efi and an active upload-debug tastk, it gets as far as in image 1. Network should be fine, I’ve done some imaging with desktop PCs with the same port.

@Quazz I’m using an ethernet to usb adapter (offical from Microsoft). It’s new, bought 2 days ago.

[Quazz]

@jhuesser Alright, well, it has a Realtek nic in it if I’m not mistaken, r8152. Realtek boot files will most likely give you the largest chance of success.

Is it possible to update the BIOS on the surface pro 4? It might help somewhat.

[jhuesser]

@Quazz If I use realtek7156.efi The same is happening as with intel7156.efi (Third image, or again at the bottom). And no it’s not possible to update the UEFI.

[jhuesser]

@jhuesser said in Several problems with Surface Pro 4:

Boot from harddisk``` REFIND_EFI starts, i need to press a key and then windows tries to boot but get stuck at the windows logo. (no problem if i boot without pxe)

Btw. the problem with the windows boot up is solved if I use ipxe7156.efi as @Tom-Elliott suggested.

[george1421]

@jhuesser I think I lost where we are in this thread.

So for the surface pro 4 you identified that you need to pxe boot ipxe7156.efi (actually that will work just fine for surface pro 4 and traditional uefi systems, so you can have just one efi boot file).

From there are we still running into issues?

[jhuesser]

@george1421 exactly.

If i assign a task via fog web interface or select a menu entry in the fog boot menu, always the DHCP error shows up.

[george1421]

@jhuesser OK where its failing is that the FOS Engine ( the custom linux operating system that captures and deploys images ) doesn’t have the driver required for that nic. If you do a debug capture (when you schedule a capture you select the debug option) does it allow you to continue and get a to a command prompt?

Since you are at this point you have the right iPXE (pxe boot stuff) we have to now find out why the FOS engine is not talking with the network adapter.

[jhuesser]

@george1421 Created an debug upload task. See the same Output as in this image

@jhuesser said in Several problems with Surface Pro 4:

So it downloads the boot file, start iPXE, start FOS and then it breaks…

[george1421]

@jhuesser I’m surprised that it just stops. I assume when you press enter it reboots then?

@Developers Do you know why the FOS engine would stop at this point. From the error message it appears that kernel is not seeing any network adapter since it says interfaces: with no interface name.

[jhuesser]

@george1421 It doesn’t recognize the keyboard at this point. If there is no upload task and the fog menu shows it works, but as soon as the FOS is running, it doesn’t recognize it.

[george1421]

@jhuesser Since I’m ignorant of the surface pro, but is there an option to add extra usb stuff, like a usb nic or keyboard?

If the keyboard is unresponsive then the question is the kernel frozen or is the keyboard not recognized. I’m suspecting some unknown usb 3 controller between the kernel device.

[Quazz]

@george1421 OP is using a USB NIC since it doesn’t have one built-in. It also has a sort of keyboard dock which I’m guessing is what OP is talking about when he says it doesn’t respond.

[jhuesser]

Yeah, I’m using an USB nic. Keyboard is the origiginal surface case keyboard. This is the connector:

As is said, in the boot menu it works fine. But when it stops at the DHCP error and ask to press enter, it doesn’t respond.

[Sebastian Roth]

@jhuesser I’d guess this is either a case of Spanning Tree as George already mentioned (try connecting a dump mini switch between your Surface and the building switch) or we have a driver issue here with the USB NIC you are using. Can you please boot up a normal PC with ubuntu live CD, then after bootup plugin the USB NIC to that PC and run the following commands on a terminal:

lsusb
...
dmesg | tail
...

[jhuesser]

@Sebastian-Roth

I receive this output:

ubuntu-gnome@ubuntu-gnome:~$ lsusb
Bus 004 Device 002: ID 8087:0024 Intel Corp. Integrated Rate Matching Hub
Bus 004 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 003 Device 003: ID 090c:1000 Silicon Motion, Inc. - Taiwan (formerly Feiya Technology Corp.) Flash Drive
Bus 003 Device 004: ID 045e:07c6 Microsoft Corp. 
Bus 003 Device 002: ID 8087:0024 Intel Corp. Integrated Rate Matching Hub
Bus 003 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 001 Device 002: ID 046d:c046 Logitech, Inc. RX1000 Laser Mouse
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
ubuntu-gnome@ubuntu-gnome:~$ dmesg | tail
[   24.138016] cdc_ether 3-1.1:2.0 enx5882a88c3afd: renamed from eth0
[   24.169228] IPv6: ADDRCONF(NETDEV_UP): enx5882a88c3afd: link is not ready
[   24.169330] cdc_ether 3-1.1:2.0 enx5882a88c3afd: kevent 12 may have been dropped
[   24.169334] cdc_ether 3-1.1:2.0 enx5882a88c3afd: kevent 12 may have been dropped
[   24.169949] cdc_ether 3-1.1:2.0 enx5882a88c3afd: kevent 12 may have been dropped
[   24.170093] cdc_ether 3-1.1:2.0 enx5882a88c3afd: kevent 12 may have been dropped
[   24.170115] cdc_ether 3-1.1:2.0 enx5882a88c3afd: kevent 12 may have been dropped
[   25.990587] e1000e: eno1 NIC Link is Down
[   42.564105] cdc_ether 3-1.1:2.0 enx5882a88c3afd: kevent 12 may have been dropped
[   42.564191] cdc_ether 3-1.1:2.0 enx5882a88c3afd: kevent 12 may have been dropped
ubuntu-gnome@ubuntu-gnome:~$ 

I think the network stuff is right. With the same cable / ports etc. I’m able to image the desktop cable. Just put the USB nic in between the surface and the cable and the error shows up…