UEFI booting with Yoga 370
-
So last update from me. The device dump did get displayed now, nicely halting at EFI. Hope this gives a good insight into the problem. As i’m leaving my current job i’m handing this issue over to my boss. I explained the efi testing steps and he’s been following it for some time so he is up to date.
Thanks for all the help and support, its great to see dedication to an open project like this. I’ll be around on the forum still as i’ll keep using fog from now on personally.
-
@Iceman344 It’s been great to work with you. All the best to you.
TCP is pretty amazing! I’ve seen lots of packet dumps but it’s always a bit different and you see new things when taking a deep dive in. On first sight this looks as if the client (Realtek USB NIC) is just a bit slow processing the data it gets from the server. In this case it has to handle quite a lot of it as kernel/initrd is more than just a few HTTP bytes. So for when one end is slower than the other TCP has a good set of “regulative” algorithms. One is “flow control” (a.k.a. “window size” or “sliding window protocol”). Both ends can tell the other to send more or less data in one frame. Smaller window size slows down the transfer. But from what I can see the client does not make use of this.
I found an interesting post (https://ask.wireshark.org/questions/17730/retransmissions) that states:
Packets get lost for any number of reasons. Here are a few likely candidates for large number of retransmissions:
- Full Duplex / Half Duplex mismatch (check the configuration of the network card and switch interfaces)
- The server transmits data with a high speed (say 1 GBit) and the receiver is connected with a lower speed (say 100 MBit). Drops occur if the receiver is signalling a large TCP window size, found in the TCP header.
- One of your routers is configured with a quality of service rule that enforces a certain the bandwidth
- A broken cable offers very poor signal quality
- A wireless network is busy or suffers from interference
My first guess is server and client are going at different speeds. Could you please force the connection speed on the switch port on both server and client side to 100MBit/s! In case you cannot alter switch configuration you could also just take an old 100MBit/s mini switch and connect it in between. Again take a packet dump on the FOG server and see if you get see
TCP Dup ACKandTCP Retransmissionpackets.The device dump did get displayed now, nicely halting at EFI.
Although I am not sure I kind of hope that this is just caused by skipping the tcp cleanup stuff. Let’s see if we can get the connection/transfer play nicely first and then see if we still hang on removing EFI…
-
Yay me. I’m on this ship now too. I just received a Yoga 370 ( 20JJS2F200 ) and I’m also unable to perform operations after a UEFI network boot.
I thought it may have been due to the new hardware this model has, Thunderbolt and WiGig but disabling them has no effect.
-
@sudburr Sorry to say this but yeah!! I am real happy that you join the team. Hope you are willing to keep this up with me and keep the debugging going. Could you please get a packet dump using this command on you FOG server while booting up one of the Yogas:
tcpdump -w output.pcap host x.x.x.x and port 80(just replace the x.x.x.x with the client’s IP). The capture file will be about 30-40 MB because the transfered kernel and initrd are within that capture file. But we need all this information to see if you have the same issue with retransmissions and such.I haven’t heard from @Iceman344 or his boss yet. Hope they’ll be back again as well.
-
I don’t have a lot of spare time just now for much testing; on the road; but I do have a USB-C adapter coming in and I have hooked Lenovo on the line to hopefully help out too.
-
@sudburr Did you get to test this yet?
@Iceman344 Are you still around? Who’s your boss? How would he get in touch with us?
@Brian-Hoehn Are you still onto this topic? -
Was able to squeeze in a baseline observation before I go onto other things and I’ve informed Lenovo as well.
I have the following:
1.Lenovo ThinkPad OneLink+ to RJ45 Adapter ( p/n: SC10J34224BB FRU: 00JT801 )
2.Lenovo ThinkPad USB 3.0 Ethernet Adapter ( p/n: SC10H30171/RTL8153 FRU: 03X6903 )
3.Lenovo USB-C to Ethernet Adapter ( p/n: SC10L66919/RTL8153-04 FRU: 03X7205 )All three work as desired on a Lenovo ThinkPad 13 (20GKSOA700 BIOS 1.24) for both Legacy and UEFI network boot. I also tested 1&2 on a Lenovo Yoga 260 (20FES0VJ00 BIOS 1.59) successfully.
Since there isn’t a OneLink+ connector on a Yoga 370 (1.17) here are my findings for the two USB models.
2a. Using the Lenovo ThinkPad USB 3.0 Ethernet Adapter ( p/n: SC10H30171/RTL8153 FRU: 03X6903 )
- Legacy mode (no secure boot, CSM, Legacy only)
- Selecting PCI LAN > Realtek PXE B000 D14
- PXE boots okay, FOS environment hands off successfully and process succeeds
2b. Using the Lenovo ThinkPad USB 3.0 Ethernet Adapter ( p/n: SC10H30171/RTL8153 FRU: 03X6903 )
- UEFI mode (no secure boot, no CSM, UEFI only)
- Selecting PCI LAN > Thinkpad USB LAN-IPv4
- PXE boots okay, but FOS environment then hangs on black screen after loading their inits for performing the selected action
3a. Using the Lenovo USB-C to Ethernet Adapter ( p/n: SC10L66919/RTL8153-04 FRU: 03X7205 )
- Legacy mode (no secure boot, CSM, Legacy only)
- Selecting PCI LAN > IBA CL Slot 00FE v0109
- Attempts to PXE boot but fails with: PXE-E61: Media test failure, check cable ; PXE-M0F: Exiting Intel Boot Agent.
3b. Using the Lenovo USB-C to Ethernet Adapter ( p/n: SC10L66919/RTL8153-04 FRU: 03X7205 )
- UEFI mode (no secure boot, no CSM, UEFI only)
- Selecting PCI LAN > Intel
Gigabit 0.0.18-IPv4 - goes directly to a blank screen for 5 seconds then returns to the F12 boot menu
There is clearly something amiss with the 370’s code.
Lenovo says that the 4X90E51405 should work, but I don’t have one … yet 8).
-
@sudburr Nice, thanks a lot for testing and posting all those many details here!!
Do you think you can squeeze in another short test to capture a packet dump for us to look at? Run
tcpdump -w output.pcap host x.x.x.x and port 80on the server, and boot up the client. When it hangs jst quit tcpdump (Ctrl-C), upload and post a link here. -
Lenovo is shipping me a 4X90E51405 for testing. I hope to be back into testing it soon.
-
Alrighty then, I have successfully UEFI and Legacy network booted a Lenovo ThinkPad Yoga 370 (20JJS2F200) with BIOS 1.17 using a Lenovo Mini-Ethernet Extension Adapter (p/n: sc10a39882aa, fru: 04x6435)
Yay another proprietary interface! (here’s the modern version).
-
@sudburr Thanks for testing! So does that mean you don’t see the same issue (hang on init.xz) that was reported initially?
-
That’s right. It works exactly as desired.
-
@sudburr You still have the other USB NIC adapters by any chance? Would you give those a try as well?
-
I already tested the others (see above) with the same BIOS and fog server configuration (1.4.4 / 4.12.3).
-
@sudburr Sorry, didn’t figure you had tested those on that very same model. Now I got it.
So that means the issue is gone. Most probably because of a new hardware release or firmware version?!?
-
No. Nothing changed on the laptop.
To get past the inits in UEFI network boot I had to use the Lenovo Mini-Ethernet Extension Adapter ( p/n: sc10a39882aa, fru: 04x6435 ) that I just acquired.
To get past the inits in Legacy network booting I can use the Lenovo ThinkPad USB 3.0 Ethernet Adapter ( p/n: SC10H30171/RTL8153 FRU: 03X6903 ) or the Lenovo Mini-Ethernet Extension Adapter ( p/n: sc10a39882aa, fru: 04x6435 ) that I just acquired.
All tests were conducted with BIOS 1.17 and fog server configuration (1.4.4 / 4.12.3).
-
@sudburr Ok, thank you very much again for all the tests and detailed information! So I mark this solved (on my todo list) now.
Hope that all the other Yoga 370 users out there find this!
-
I can now confirm that the Lenovo Mini-Ethernet Extension Adapter (p/n: sc10a39882bb, fru: 04x6435) also works in both UEFI and Legacy network boot.
