@Sebastian-Roth Sadly I am out of surface go’s to test at this time. Gotta get the ones we have in production.

@Sebastian-Roth While not impossible, that is very unlikely. We have only 2 people with access to do that and we were both watching this happen.
It did go away in the webui though, so perhaps something caused it to cancel.

@george1421
Did another test of the surface go with the surface usb-c adapter on the new kernel.
It did technically finish the image but at the very end of imaging this db error stuff happened

The image got to 100% complete and thus far everything looks like it’s working, the only thing I can see thus far that didn’t work was writing the image history to the host. Could be unrelated to the kernel and such but this didn’t happen on the other 2 surfaces I imaged today with the lenovo usb-c adapter and a usb 2.0 ethernet adapter.

Another fun side note for anyone interested that also has both the microsoft usb-c adapter for the surface devices and the lenovo usb-c type adapters for lenovos. I know that the microsoft adapter will Not pxe boot the lenovo. However I just discovered that the lenovo usb-c adapter will pxe boot the microsoft surface go. So if there is a problem with the kernel and the microsoft adapter, you could just use the lenovo adapter instead. Or theoretically a device with the same realtek ids mentioned earlier on.

@jps Have you had a chance to try the kernel @george1421 made?

@george1421 I re-imaged the device with the original fog 1.5.7 kernel and it worked as normal again. So Although I can boot into fog on the new kernel, imaging freezes. It is not impossible that it was a network problem though, so the next surface I test, I’ll use the new kernel and a different switch.

@george1421 So I made the new one the default kernel and am Re-imaging the same surfacego that worked this morning and found something odd.
For reference when I imaged it with the same image before it took 3 minutes (according to the image history).

This is where it is at now…

The speed has progressively dropped and is still dropping a little at a time. It’s been running for nearly an hour. It’s using the same storagenode and all that. Only difference is the kernel. Sadly I’m not actually 100% sure which kernel I used that was successful. Pretty sure it was the fog 1.5.7 shipped kernel though. I should really give them better names and take extra notes when testing kernels, so easy to mix them up. At any rate though, this is not a normal behavior.

also, side note that I just noticed, it is frozen in the gui task progress bar at 65% which I assume is when it must have started to crazy slowdown, I had optimistically left it to run.

edit : We discovered a network issue that may have caused the computer to lose its dhcp address and or connection during imaging (rouge dhcp server), will test again when that’s worked out.

@george1421 Any reason you didn’t want to try compiling kernel version 5.1.16 ? Noticed that there’s one of those in the kernel update screen of fog configuration.

@george1421 So this one is good to be tested as the default kernel now?

@george1421 I was able to nab an L390 I put into production before the user got here and do a quick test with the adapter on this new kernel. Great success it worked! So this kernel appears to be working on both the usb-c ethernet adapters I have that are manufacturer specific Microsoft and Lenovo.

Which thing did you change then?