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.

@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.

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 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!

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 Thanks for this… I think I’ll start a new thread, I can then spell out whats happening with images :-).

I’m happy to go down the compiling route as long as I can follow it But I’ll be back in-touch if I’m stuck, but hopefully I can come back with some conclusions and/or some feedback on what to try next?

@george1421 Thanks for that… We’ll get straight on an double check the UEFI version and make sure it’s the latest!.. I did see mention of using boot devices with bzimage+inits, I think I’ll try this last as it would be great to help and an diagnose this.

Hi, we’re in the exact same situation here. We’ve got a number of Surface Go’s that just refuse to get beyond the bzimage/init.xz.

The dock we’re using is for the Surface Go. The initial PXE boot seems to work, we’re using ipxe.efi just now. But it just seems like the NIC is dead in the dock even thought it initially started to boot.

We’re using the latest version of FOG, along with the latest kernel and I just updated the init.xz (and init_32.xz) that george1421 mentioned below.

Is there anything I can do to help speed up diagnostics? How do I drop to a console window on the client computer to help run commands?