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

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

[sudburr]

I finally got my hands on a Lenovo ThinkPad OneLink+ to RJ45 Adapter ( model SC10J34224 ).

Using FOG RC10, kernel 4.7.3, it connects and fogs quite happily in UEFI mode using ipxe.efi and Legacy mode using undionly.kpxe.

Tested on a Lenovo ThinkPad Yoga 260 and a Lenovo ThinkPad 13.

[george1421]

@sudburr Thank you for posting back there is another FOG user that is having a problem with similar hardware. Your insights may be valuable with his issue too.

[sudburr]

Revisiting this using the newly released 1.51 BIOS and these settings:

UEFI/Legacy Boot = BOTH
UEFI/Legacy Boot Priority = Legacy First
CSM Support = YES
Secure Boot = disabled

I am able to undionly.kpxe boot via the Lenovo ThinkPad OneLink+ to RJ45 Adapter ( model SC10J34224 ).

Atttempts to undionly.kpxe boot the Lenovo ThinkPad USB 3.0 Ethernet Adapter ( Realtek RTL8153 USB Ethernet Controller (xHCI) v2.00 (05/20/15) ) results in detection and iPXE loading, but hanging at:

iPXE initialising devices...

Strangely this same setup now works happily on the Lenovo ThinkPad 13 with BIOS 1.15, so there is something odd about the Yoga 260.

Booting instead with a UEFI USB with ipxe.efi or snp.efi at least, works if I change the BIOS setting:

UEFI/Legacy Boot Priority = UEFI First

My intent then is to USB boot, but I can only find instructions for UEFI for USB booting. I’d like to test .*pxe booting by USB. Is this possible and how?

[sudburr]

It looks like finding a way to .KPXE USB boot is moot since playing directly with the DHCP results in:

undionly.pxe
= fails through to hdd

undionly.kpxe
= hangs at iPXE initialising devices …

undionly.kkpxe
= hangs at bg.png 25%

ipxe.pxe , ipxe.kpxe , ipxe.kkpxe
= only looks for link up on net0 (the onboard nic) twice

ipxe.krn
= hangs after loading

realtek.pxe , realtek.kpxe , realtek.kkpxe
= exits after loading

[Wayne Workman]

@sudburr said in Lenovo Thinkpad Yoga 260 w/Lenovo ThinkPad USB 3.0 Ethernet Adapter FRU:03x6903:

I’d like to test .*pxe booting by USB. Is this possible and how?

It’s possible. ipxe’s website has a quickstart area that has an image you can burn to cd or USB, and you can boot from that. Of course, in the chainloading area you could replace that with the file on your fog server /tftpboot/default.ipxe and I’m also sure you could replace the actual file they are using with one from the FOG server too so that it just looks for default.ipxe on it’s own.
http://ipxe.org/

[sudburr]

More interesting news.

Booting Legacy by Network

undionly.pxe
= fails through to hdd

undionly.kpxe
= hangs at iPXE initialising devices …

undionly.kkpxe
= bg.png 25%

ipxe.pxe , ipxe.kpxe , ipxe.kkpxe
= only looks for link up on net0 (the onboard nic) twice

ipxe.krn
= hangs after loading

realtek.pxe , realtek.kpxe , realtek.kkpxe
= exits after loading

Booting UEFI by Network

ipxe.efi , ipxe7156.efi
= good

realtek.efi , realtek7156.efi , snp.efi , snp7156.efi , snponly.efi , snponly7156.efi
= hangs after gateway ip display

=-=-=-=-=-

Booting UEFI by USB

ipxe.efi , ipxe7156.efi , snp.efi , snp7156.efi
= good

realtek.efi , realtek7156.efi , snponly.efi , snponly7156.efi
= doesn’t detect nic; dhcp fails

=-=-=-=-=-

It’s interesting to see the very different behavior of USB launching vs network.

[sudburr]

@Wayne-Workman But what I’m really looking for is a FOG-specific answer to building a Legacy Boot USB.

To build a UEFI USB it’s a simple matter of formatting a key to FAT32, active, then copy your .efi of choice to /efi/boot/bootx64.efi.

Is there an equally simple solution for a .*pxe and what is it?

[Wayne Workman]

@sudburr said in Lenovo Thinkpad Yoga 260 w/Lenovo ThinkPad USB 3.0 Ethernet Adapter FRU:03x6903:

Is there an equally simple solution for a .*pxe and what is it?

I can’t say I’m an expert on this, and @george1421 probably knows how to do this already. But I would think you’d create a partition on a usb drive that is marked as bootable using fdisk and then format that partition fat32, and then take those for files from ipxe’s image and put them there, and just modify them as needed. Like changing out the kernel file with the desired rom file, and replacing the script with the stuff from default.ipxe.

[sudburr]

Alrighty… Murphy just showed for work.

All four good USB-based .efi solutions now hang .

bzimage... ok
init.xz... ok
then nothing

grrr … argh

[Tom Elliott]

@sudburr And if you use the 7156 labelled file?

[Tom Elliott]

I suppose you could also try working-RC-26 files. I updated ipxe files yesterday I believe.

[george1421]

@sudburr I guess I would have to ask the question, how many of these weird systems that will not pxe boot do you have to deal with? The answer may be to just dig a hole and fill it with these devices.

For efi devices building a boot drive is pretty simple. It would also be interesting to see if you can skip iPXE entirely by using grub to boot into FOS via https://forums.fogproject.org/topic/7727/building-usb-booting-fos-image

[sudburr]

@george1421 More than you can shake a several dead cats at.

[george1421]

@sudburr Have you tried the magical 7156 version that Tom talked about? That actually is a legacy iPXE kernel that seems to work well with the surface pros.

[sudburr]

@george1421 Yes, scroll up to the `More interesting news’.

[sudburr]

@Tom-Elliott Already have. Scroll up to the `More interesting news’.

[sudburr]

And now… the 4 magic USB .efi solutions are working again. o_O

[george1421]

@sudburr ok so I’m a bit confused. It appears that you can network efi boot these devices. Is your goal to legacy boot these devices?

I can understand why the usb booting would work over network booting the same iPXE kernel if the netboot code is fault in the yoga’s firmware. We have seen the hand-off between firmware and iPXE fail on some of these lenovos in the past.

[sudburr]

Just trying to find the path of least resistance given our environment. The 4 USB .efi solutions are now working again. Murphy has passed out in the corner.