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

@george1421 I was able to boot into a debug session on the surface go with this new kernel.
I don’t have the lenovo l390 to test on at the moment but should be able to test it today. I’ll test it on my lenovo x390 too, but gotta make sure they all work.

Here is the lsusb of the surface go usb-c ethernet adapter

lsusb
Bus 002 Device 002: ID 045e:0955
Bus 001 Device 020: ID 045e:096f
Bus 001 Device 001: ID 1d6b:0002
Bus 001 Device 003: ID 0cf3:e302
Bus 001 Device 002: ID 045e:0957
Bus 002 Device 003: ID 045e:0927
Bus 002 Device 001: ID 1d6b:0003

@george1421 I believe that is a different dongle, the one I have is model 1860, that post references 1821 and 1663, but it’s a fair guess that it’s the same or similar driver. I’m troubleshooting a different problem on one at the moment, but will have it boot into a debug fog session and run lsusb on it on my next reboot.

@george1421 Let the fun begin then, I have 4 of these that I need to setup today.

the hardware ID in windows is USB\VID_045E&PID_0927&REV_3100
I’ll get the linux bit shortly

@george1421 I did do a test on a normal device (intel ethernet desktop type) and it did boot to the fog menu and started an image deploy without a problem on the new kernel. I set the surface go to use the old kernel (I have so many now I’m not actually 100% sure which one it is, but pretty sure its the one that shipped with 1.5.7) and it is now imaging properly, meaning that the new kernel does indeed fix one usb-c adapter and breaks a different one. I’ll get the details on the microsoft ethernet adapter if you want them tomorrow.

@george1421 so some odd things to report with the new kernel as the default…
One almost plus, I found that an acer switch 3 recognized the lenovo usb-c ethernet adapter as one that could pxe boot. It even almost worked but it is now frozen at ipxe initialising devices... In the past, no usb-c ethernet adapter would do a native pxe boot on this device, so that’s something. I guess I still don’t have one that will do a pxe boot.

I went to image a new surface go with the microsoft usb-c ethernet adapter that was working in the past.
I got this message after pxe boot completed and FOS was starting…

Sorry that it’s blurry, basically it says that the kernel is probably missing the correct driver. Doesn’t make a ton of sense that the fix for one usb-c ethernet adapter would break another. It isn’t impossible that microsoft’s adapter also uses a realtek chip and this chip doesn’t like the new driver. Why can’t they all just get along?

I will try testing the old kernel and other things tomorrow.

@george1421 I’m making it my default kernel now then, I backed up the old one of course. I’ll report back if there are any problems, but I would assume all will work as expected.

@george1421
I would probably bet that adding usc-c support helped more than we know. I’ve just never had this good of an experience with a usb-c adapter and fog. Just my 2 cents.

Do you see any reason that one shouldn’t use this kernel for all devices?

Also, another side note to my Fellow Lenovo L390 owners. If you set the Mac Address Passthrough option in the bios to “Second Mac Address” you can get a unique mac address for each device that uses that usb-c adapter or dock to image with fog so you won’t have issues with duplicate macs. However if you set it to “Internal Mac Address” it replicates the internal card which confuses ipxe that there are 2 network cards with the same mac address and it tries a ‘net0’ device twice failing both times.

@george1421 I posted your solution on two other posts that appear to be related issues

https://forums.fogproject.org/topic/13203/l390-yoga-lenovo
https://forums.fogproject.org/topic/13909/can-t-find-network-interface-kernel

There they are for reference for anyone finding this or those in the future.

@george1421 said in issue with netcard of dock gen2 of lenovo l390:

@JJ-Fullmer The r8152.c from the torvalds github site failed to compile on 4.19.65, I’m suspecting its for a later release of linux. The version from the torvalds site was 1.10.10. The version in 4.19.65 was 1.9.9 of the realtek driver.

I was able to compile the realtek driver from the wget github site. This version is 2.12. Here is a link to that kernel with the 2.12 driver built in. I also enabled the usb-c code in the kernel that appears to have not been set. I don’t know if its relevant, but it should be on for other applications. https://drive.google.com/open?id=1wZwwOwbEr0nR3mnPLKg7AsulwJaGhO0A

Download this as bzImageRT (watch your case) and copy it to the ipxe directory with the other kernel images. Manually register the host and then in the host definition add in bzImageRT as the kernel for that host. Then pxe boot into FOS Linux debug mode to see if the network adapter inits correctly with this updated driver.

@John-L-Clark I realize that this is a few months old, but this problem sounds similar. Give this solution a try, download the kernel @george1421 made and set it on that host. It worked for me with the lenovo usb-c ethernet adapter, I imagine you’re using that or a similar adapter, this kernel fixed the issues we were having with the L390 and X390

@george1421 said in issue with netcard of dock gen2 of lenovo l390:

@JJ-Fullmer The r8152.c from the torvalds github site failed to compile on 4.19.65, I’m suspecting its for a later release of linux. The version from the torvalds site was 1.10.10. The version in 4.19.65 was 1.9.9 of the realtek driver.

I was able to compile the realtek driver from the wget github site. This version is 2.12. Here is a link to that kernel with the 2.12 driver built in. I also enabled the usb-c code in the kernel that appears to have not been set. I don’t know if its relevant, but it should be on for other applications. https://drive.google.com/open?id=1wZwwOwbEr0nR3mnPLKg7AsulwJaGhO0A

Download this as bzImageRT (watch your case) and copy it to the ipxe directory with the other kernel images. Manually register the host and then in the host definition add in bzImageRT as the kernel for that host. Then pxe boot into FOS Linux debug mode to see if the network adapter inits correctly with this updated driver.

@Interrupt Give this solution a try, download the kernel @george1421 made and set it on that host. It worked for me with the lenovo usb-c ethernet adapter, it stands to reason it will work for the dock too.