Issue imaging with Surface Pro

[jemerson93]

Good morning,

I am having an issue with imaging Surface Pro’s. I am using the Microsoft Ethernet Adapter but once I select either Full Host Register or Deploy an Image, I get the following error. Currently I have Secure Boot off and TPM off. I am stumped on what to do to resolve it but I have had this issue with every Surface Pro we have attempted to image.

Please let me know if you need anymore information.

FOG Version: 1.5.4
Kernel Version: 4.15.2 (To fix the long MBR/GPT issue)

[george1421]

Just to confirm that 192.168.1.55 IS the IP address of your FOG server?

Whoops, I just saw interface wwan0. Isn’t that the 3G/LTE wireless device?

[jemerson93]

@george1421 George, that is the correct IP Address.

Yes, the WWAN0 is what is confusing me. It is booting to the USB Ethernet adapter but booting as WWAN0 instead of ETH0.

If it helps, and I cannot quote this, I believe the specific Surface’s I have been having issues with have built in mobile connection as well.

[george1421]

@jemerson93 OK lets try this.

Manually register this host (if not already registered).
Schedule a debug deploy or capture (doesn’t matter at this point) but check the debug checkbox before you submit the task.
pxe boot the target computer it should try to image right away.
after a few pages of text and enter key presses it should drop you to a linux command prompt on the target computer.
Once at the linux command prompt key in ip addr show See if eth0 is listed.

[jemerson93]

@george1421 George, I do not see eth0 listed.

Below is the image.

[george1421]

@jemerson93 OK I should have asked this first, what ethernet adapter are you using? Is it in the dock or a usb adapter? Since you are getting this far, the adapter has to be supported by both the surface firmware AND iPXE kernel. It just appears that FOS (the customized linux) doesn’t have the driver for the network adapter.

If you don’t know, lets see if the lspci command sees it, key in lspci -nn|grep etwork to see if it sees the network adapter (other than wwlan).

[jemerson93]

@george1421 I am using the USB Adapter

When inputting the command, I just get another input. Nothing displays.

[jemerson93]

@george1421 Basically this is what happens

[Wed Aug 15 root@fogclient /]# lspci -nn|grep etwork

• Press enter
  [Wed Aug 15 root@fogclient/]#

[george1421]

@jemerson93 OK I’m going to shoot from the hip on the next command. lsusb to display any detected usb devices.

The next bit of info is getting the manufacturer and model number of the usb network adapter. Then from inside windows see if we can get a hardware ID like we can for physical stuff [USB\VEN_3426&DEV_4388] (that was a totally made up ID, but that is what I’m looking for). I have been doing a lot of kernel debugging for another thread, so I know about where in the kernel settings to look to see if its supported.

Also what model number of Surface device is this? We will need that for data completeness.

On the other (DIY/not a real solution) side, if you also insert any old generic USB nic, FOS should see it. So one might boot from the MS NIC and then when FOS starts it will detect the generic NIC and use that.

[jemerson93]

@george1421 Okay going to go in order from your post.

When inputting lsusb, I receive the following
Bus 002 Device 002: ID 045e:0927
Bus 001 Device 002: ID 045e:09c0
Bus 001 Device 001: ID 1d6b:0002
Bus 002 Device 003: ID 045e:094a
Bus 002 Device 001: ID 1d6b:0003

Manufacturer & Model: Microsoft USB Ethernet Adapter Model 1821
Hadware ID: USB/VID_045E&PID_0927&REV_3100
USB/VID_045E&PID_0927
Surface Pro Model 1807 (Looks to be the 2017 model)
All of the Surface Pro’s I have had issues with are either the 2017 model or 2018 model. All had LTE support enabled

If I use a generic usb nic, it does not even PXE boot on a Surface. I have had success using a generic USB nic with other tablets though.

[george1421]

@jemerson93 Well the sloppy fix is to plug in both usb ethernet adapters. Once to pxe boot the computer and one once FOS starts. Both plugged into each wall jack ahead of time. I said its not a nice solution, but in a pinch it should work.

I’ll dig into the device since you provided a quality hardware ID.

For translation to linux [045E:0927] for the hardware ID.

[jemerson93]

@george1421 George, this Surface only has 1 USB.

Here is what I attempted. Connect Microsoft usb nic, boot to FOG, select deploy image
As soon as I selected the image, I unplugged it and connected the generic one. I received the wwan error but after it failed a few times, it went into eht0 (this is with the generic usb nic) but I received a new error.

If I can get this error fixed, at least while you look into the microsoft nic (which I appreciate so much as this is out of my knowledge), this may work as you said as a sloppy fix

[george1421]

@jemerson93 Back on point here. I looked and that usb ethernet adapter is not currently supported by the Linux kernel at least as of 4.17.13 (which is pretty new). I did find a FOG forum post ( https://forums.fogproject.org/topic/10943/surface-pro-4-registration-issues ) that discusses that exact network adapter. So it appears that the FOG Project may have a patch that enables that network adapter.

Please try this development kernel: https://drive.google.com/open?id=1WPv4HeMrWdWu9uyOyVaoJkBX3A9EGi-t

1. Download that file as bzImage41713m and place it in /var/www/html/fog/service/ipxe directory on your fog server.
2. Goto the fog gui and locate the the computer in host management where this ethernet adapter is connected. There is an entry for Host Kernel enter bzImage41713m into that field.
3. Pxe boot the target computer to run your capture/deployment.
4. Note any error messages in regards to getting a dhcp address.

I really don’t know if this will work (the FOG Project patch) or not for your install. This development kernel has quite a bit more hardware support added than previous releases of the FOS kernel. Will something else break? Probably…??, but it shouldn’t.

[jemerson93]

@george1421 said in Issue imaging with Surface Pro:

bzImage41713m

Did as you said, kicked in the eth0 interface and got further. Now running into this issue.

[Tom Elliott]

@jemerson93 unable to find image store means fos cannot see your image files anywhere. Do they exist? If you have other nodes, do those nodes also have the image?

[jemerson93]

@tom-elliott I have 1 storage node and I just tested that specific image (which used to work) on another laptop and it had the same issue.

When checking /images, I am finding all of my images except for that one listed. I will re-upload it now and test.

[jemerson93]

@tom-elliott @george1421

Update. I tested another one of our images just to test imaging and it successfully imaged. I appreciate the assistance so much.

I do have 2 questions. First question, I noticed when using this kernel compared to the current kernels I am using, I am back to the issue with the long erasing MBR/GPT partitions. Anyway to fix that with this custom kernel or just need to deal with it?

Secondly, is there a way for me add other usb nics as I find issues, or how to find a kernel that supports them instead of opening a forum post if I run into issues. Reason I ask is we have a Dell USB nic for some of the new XPS models and I have yet to test it.

[george1421]

@jemerson93 said in Issue imaging with Surface Pro:

I am back to the issue with the long erasing MBR/GPT partitions

Well that tells me the kernel patch I applied didn’t address the slow gpt partition creation (same issue with FOS 4.17.0)

@tom-elliott The nic was enabled by adding

    {REALTEK_USB_DEVICE(VENDOR_ID_MICROSOFT, 0x0927)}

to drivers/net/usb/r8152.c

@jemerson93 To your adding other usb nics. The answer is sure, all you need to do is patch the linux kernel source from http://www.kernel.org and then compile the linux kernel.

[jemerson93]

@george1421 George I’ll look into that for other USB nics (my Linux knowledge is not the greatest but growing)

I can deal with the longer erasing mbr/gpt partition for those specific devices (hoping newer kernels may resolve it)

Thanks again for the help! So greatly appreciated.

[jemerson93]

@george1421 Also I’m not sure how to change this to solved.