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

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

[sudburr]

Not yet. I’m pulling an image from it right now.

But I did try snponly.efi and it was unhappy.

[sudburr]

ipxe.efi also works.

[sudburr]

I’m hoping to acquire a ThinkPad OneLink+ to RJ45 Adapter ( pn: 4X90K06975 ) which should leverage the Yoga’s onboard ‘Intel Ethernet Connection I219-V’ through the OneLink+ connector to see how that pans out.

[Sebastian Roth]

@sudburr Please let us know when you succed using this adapter! As well it would be great to know which NIC chip is in that adapter… so I can add it to the wiki.