Lenovo Thinkpad Yoga 260 w/Lenovo ThinkPad USB 3.0 Ethernet Adapter FRU:03x6903

[sudburr]

My turn!

Okay, the scenario:

• CentOS 7.2.1511

• FOG build 7394

• Kernels 4.5.1

• UEFI/BIOS set to Legacy mode only

• Secure Boot is disabled

• F12 Booting from PCI LAN > Realtek PXE B00 D14 ( Realtek RTL8153 USB Ethernet Controller (xHCI) v2.00 (05/20/15) )

Using undionly.kpxe it stalls at iPXE initialising devices.
Using ipxe.pxe it stalls at iPXE initialising devices, then eventually fails to DHCP.
Using undionly.kkpxe it stalls at http://172.19.244.13/fog/service/ipxe/bg.png… 12% or 39%

I have verified that each of the iPXE boot processes still work on other systems.
I can web browse to http://172.19.244.13/fog/service/ipxe/bg.png and see the graphic fine.
I have tried both USB3 ports on the Yoga with the same results.
I have updated the Yoga’s BIOS to UEFI (n1get62w - 1.41), Embedded Controller (n1ght44w - 1.21) just released 04/27.

'elp!

[Wayne Workman]

[george1421]

No real answers, just a few more questions…

Are there any usb 2.0 ports on the yoga?

Because what I think I’m seeing is the PXE Rom is working correctly in that it does transfer the iPXE kernel to the target computer, just it iPXE kernel can’t init the network adapter. The adapter is behind a USB 3.0 interface and not a USB 2.0 interface. I seem to recall they are structured differently requiring different drivers. Just something else to stat, is that Realtek RTL8153 a usb 2.0 or usb 3.0 device?

[sudburr]

It is pure USB3.0 controller no USB 2.0.

But PXE booting is not the issue. It is indeed PXE booting with undionly.kkpxe. It is explicitly hanging on xfering the bg.png file; which is not the first thing that is transferred.

Reminds me of when the background image kept tripping up PXE booting Hyper-V 2012r2 VMs.

[george1421]

@sudburr I think its a bit of a fluke that it made it that far. I can’t explain why I think that.

But for grins, I wonder what would happen if someone replaced that png file with a new background image (as a test) that is 1 pixel in size. Would the booting continue or just crash a bit later?

[sudburr]

I was going to try something like that tomorrow.

[Wayne Workman]

Is the main server on a different subnet than the one your trying from?

[sudburr]

No; same subnet, same switches, all same works with every other client platform I have in same room, on same switches, on same subnet with same files with same …

[george1421]

@sudburr Just thinking out loud here. Right now there is questions if iPXE is able to initiazle the hardware. But once we get past iPXE there is still the FOG client OS (FOS) to ensure that it will work with your hardware.

A while ago I wrote a tutorial [https://forums.fogproject.org/topic/6532/usb-boot-target-device-into-fog-os-live-fosl-for-debugging] on how to create a FOS-L usb boot drive. This would boot the FOS client OS via USB instead of transferring it via PXE. If you have time to test and a spare USB Flash drive, create a FOS_L boot image and see if the FOS client can pick up an IP address. We may have to add a kernel parameter since you are using a usb NIC. But lets start with the out of the box instructions. What this will tell us is that once we get past the iPXE issue FOG will function as expected. If the FOS doesn’t support the nic then working on iPXE is only the beginning of a long process.

[Sebastian Roth]

@surbud said:

Using undionly.kpxe it stalls at iPXE initialising devices.

Most probably caused by a faulty UNDI PXE stack implementation

Using ipxe.pxe it stalls at iPXE initialising devices, then eventually fails to DHCP.

Stalls and then still goes ahead and does DHCP? Maybe try ipxe.kpxe or ipxe.kkpxe?

Using undionly.kkpxe it stalls at http://172.19.244.13/fog/service/ipxe/bg.png… 12% or 39%

Maybe we can get some more information by enabling debugging in iPXE. Please look into generating your own iPXE binary and add the following in the debug field: ipv4:2 (that’s just a first quick idea to see some more debugging output - will be a lot. Possibly there will be better options than enabling ipv4 debug but it’s a start. I will look into that when I get home)

[Wayne Workman]

another idea - although unlikely to help - is to put a dumb-switch between the adapter and the rest of the network… see what happens.

[sudburr]

Okay, I’m back in the office, and quickly tried something else with undionly.kkpxe .

mv /var/www/html/fog/service/ipxe/bg.png /var/www/html/fog/service/ipxe/bg.png.old

I can get to the FOG menu!

Host is NOT registered!

Menu Selection Results:

Boot from hard disk = Booting from SAN device 0x80 + hang
run Memtest86+ = memdisk... 10% + hang
Quick Registration and Inventory = bzimage... 0% + hang
Quick Image = http://172.19.244.13/fog/service/ipxe/boot.php... 37% + hang
Client System Information (Compatibility) = bzimage... 0% + hang

I’m also entertaining the idea that this may be a bad USB Ethernet adapter; so I’m getting another to be sure.

[sudburr]

I have successfully booted from USB FOS FOG 64-bit Debug Kernel.

I have eth0 (1c394713aa5e) and eth1 (the USB Ethernet) (3c18a006dfa1)

eth1 has a valid ip address .

[sudburr]

If I replace the version 4.3.2 bzImage and init.xz on the USB key with 4.5.1 variants, it still boots fine.

[george1421]

@sudburr Well on the plus side once we get past the iPXE booting issue FOG will work.

The down side is that we still need to get the iPXE kernel to work with that nic correctly. It is too bad changing the png file didn’t work. But as I expected it just moved the problem to the next large transfer.

[Tom Elliott]

@george1421 What about switching the bootfile? Using undionly.pxe/ipxe.pxe or if UEFI, using snp.efi/snponly.efi?

[george1421]

@sudburr said

If I replace the version 4.3.2 bzImage and init.xz on the USB key with 4.5.1 variants, it still boots fine.

What do you mean by this??

The trunk version should be already running 4.5.1

Just for clarity, when the ipxe kernel boots it should say a version number and some hex characters after the version. Can you please post the version and hex characters here.

[sudburr]

@Tom-Elliott unidonly.pxe can’t dhcp, ipxe.pxe hangs at iPXE initialising devices.

Okay, setting to UEFI boot and snp.efi . It works.

Re-instating bg.png. It still works.

Sigh… so UEFI it will be. Time to upgrade the DHCP server.

btw, iPXE is 2d42d

[george1421]

@sudburr Well it was worth a shot on checking the build number. The version if iPXE you are using is only 2 commits old. So the point is its fairly new. So upgrading iPXE probably will not resolve the issue.

Your other option is to find a usb network adapter that IS supported by iPXE and the Thinkpad.

[Sebastian Roth]

@sudburr said:

Okay, setting to UEFI boot and snp.efi . It works.

But only if you switch to UEFI in “BIOS” I suppose! Well then, UEFI is not too bad after all… Just wondering of you need to reinstall your client OS. Have you tried ipxe.efi as well?