Surface Go Imaging - bzimage DHCP

[Minxster]

Fog Version : 1.5.5
Kernel : 4.19.6
init.xz : manually updated : date modified - 2018/12/16

My company has been used FOG for around 5 years now, we’ve only been using it for existing laptops/desktops. Only now are we planning to use it for a full tech refresh of the business. We’ve been using UEFI/PXE/Windows 10 images on other laptops (Dell) without any problems.

So now I’m attempting to use the Microsoft Surface Dock 1661, to PXE boot our Surface Go. So far the initial PXE boot (ipxe.efi) seems to work as normal, the menu appears, I request it to perform a full registration, but then after bzimage load, I just get the udhcp: sending discover messages and the it will not get an IP address.

The initial boot

It’s only worked twice in over 2 days of constant rebooting/testingm, which is actually odd it did work for 2 reboots (a day apart!). The Dock and the tablet are (as of today) fully up-to-date with firmware which has made no difference.

According to Windows device manager the NIC device id = USB\VID_045E&PID_07C6&REV_3000

I also found this interesting: msux64w10.inf:USB\VID_045E&PID_07C6&REV_3000,RTL8153.ndi.NT

It would seem that the NIC is actually a RTL8153?

I’ve attempted to boot with FOS on a usb drive, it boots up fine, but still has the issue with the bzimage/DHCP. From using the debug option in FOGs menu, I’ve been able to run ifconfig to see that the NIC is available, with MAC, just no IP address.

We’ve got a USB 2.0 Ethernet adapter, this works perfectly fine with the Dock, and we can FOG the tablet with no issues other than it’s taking nearly 30minutes to do it!

I’m no Linux guru, but I’m more than happy to follow instruction. I’ve already been asked to maybe look at compiling test kernels to see what happens. I’ll see about getting onto this, it’s a shame it’s a Friday and I have no way of doing this from home, otherwise I would!! So it may be next week before I can get down-and-dirty to with FOG

[Sebastian Roth]

@Minxster Ok this is a different stage to what I had expected when I said you might need to get into compiling a debug kernel.

The kernel seems to boot nicely (does not hang at loading bzImage) and you see it fail on requesting the IP. I think we’ve had this with Surface devices in the past a lot. Please search the forums.

[Minxster]

@Sebastian-Roth Thanks for taking the time to respond. I’ve actually spent quite a bit of time going over the forum already as I’ve been working on this for a good few days now.

I even started to look at the spanning-tree situation that someone else had. My snap decision was this can’t be the case since all other computers (around 140) but new testing kit, all work fine. This only exception is the Surface Go.

From what I can tell, this is more about the dock than the surface go. The Go doesn’t natively have a NIC chip/board within it (from what I can tell, only WiFi), so it’s purley in the dock… This is different for things like Dell docks with certain laptops: there you sometimes have the NIC MAC from the laptop itself but can also have the NIC MAC from the dock. So you can end up with two different MAC addresses for a singe laptop/computer.

The dock NIC is recognised as a Microsoft Surface NIC, even though it seems clear that it’s actually a Realtec NIC. I’m guessing its a driver issue, but this is only a hunch!

[george1421]

I did some checking and Linux supports that network interface 3.14.0. I also confirmed that the network adapter is included in FOG’s linux kernel (bzImage). Looking at linux 4.19.30 I see the driver version in linux is 1.9.09. From the github site, I see the latest available version is 2.11: https://github.com/wget/realtek-r8152-linux

[george1421]

@george1421 I’ve slid the current realtek 8153 drivers into my kernel build environment. I’ll have a debug version of bzImage in a few minutes.

[Minxster]

Just to post back, as I’ve been pretty quiet for a while…

We’ve done little testing until today. We’ve tried a a test bzimage from @george1421 which doesn’t seem to have made a difference. For now I’ve change the Host Kernel back to default.

Strangely enough, looking at dmesg, I see a kernel error for r8152 kernel tx status -71… The interesting part is its being referred to as r8152, but the Windows .inf file stated rtl8153? I don’t know if this makes any difference at all though, just pointing out that it looks a little odd

I did see a similar post on here that talked about use the Kernel Argument of “has_usb_nic = 1”. I’ve inserted this in the host config on the server, but this has made no difference.

I think the following is a red-herring since @george1421 checked out the latest driver already … That said, when I type in lsusb I don’t see any devices listed like in the post below?
I have found this article though, about Linux and rtl8153 drivers; also how sometimes the r8152 drive can get confused?
https://www.pcsuggest.com/install-rtl8153-driver-linux/

[Sebastian Roth]

@Minxster said in Surface Go Imaging - bzimage DHCP:

The interesting part is its being referred to as r8152, but the Windows .inf file stated rtl8153? I don’t know if this makes any difference at all though, just pointing out that it looks a little odd

Might sound odd but it’s all the same thing as far as I see it. Find information on the Linux kernel driver here:

This option adds support for Realtek RTL8152 based USB 2.0 10/100 Ethernet adapters and RTL8153 based USB 3.0 10/100/1000 Ethernet adapters.
… the module will be called r8152

@Minxster said:

That said, when I type in lsusb I don’t see any devices listed like in the post below?

I am still not exactly sure what we see in the pictures you posted. It seems to find an interface called enp0s20f0u2u2 which I am not familiar with. A quick web search reveals other posts with such an interface name but it seems kind of rare. No idea what that is.

I did see a similar post on here that talked about use the Kernel Argument of “has_usb_nic = 1”. I’ve inserted this in the host config on the server, but this has made no difference.

It definitely should make a difference! The client should wait on bootup and tell you to unplug and re-plug the USB NIC. Make sure you have the option set without spaces, like this: has_usb_nic=1

[Minxster]

@Sebastian-Roth Thanks for the info…

Out of interest, here’s what I see when I run lsusb, I’ve seen other posts where the name of the device is listed to the right?

I don’t know if there is any significance to this.

I’ll update our settings for has_usb_nic=1 as it did indeed have spaces around the =. I’ll report back on how I get on.

[Minxster]

Ok, so the has_usb_nic=1 is now showing up during the boot-up.

Un-plugging and re-plugging hasn’t made a difference though. I tried this just with the hub interface, and then again by fully powering down the whole dock and starting it up again before re-connecting the hub to the Surface.

[george1421]

I’ve been chasing this rabbit a bit too.

It looks like at kernel 4.10.<something> the Kernel developers change how this network adapter was detected. Before 4.10.x the network adapter was handled by the cdc_ether driver. After that release it was by the r8152 (which appears to be broken for that device).

I found references to a kernel patch that hasn’t made it into the main stream to unblacklist it from the cdc_ether driver so its detected again. I can’t seem to find the patch or how to unblacklist hardware.

ref: https://bugs.launchpad.net/ubuntu/+source/linux-hwe/+bug/1742922

[Sebastian Roth]

@george1421 said:

adapter was handled by the cdc_ether driver

Got to be careful with this. I do remember we have had issues with this cdc_ether driver in the past. Please search the forum for this. I think we even tossed it out of our kernel builds for some reason…