@george1421 Like I mentioned above, the Lenovo ThinkPad 13 works perfectly with the same BIOS setup. No need for the USB solution that the Yoga 260 requires for UEFI/Legacy dual booting. I fully believe the problem is entirely with the firmware on the Yoga.
Both work better now than they did 4 months ago with the BIOS version available then.
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.
And now… the 4 magic USB .efi solutions are working again. o_O
@Tom-Elliott Already have. Scroll up to the `More interesting news’. 
@george1421 Yes, scroll up to the `More interesting news’.
@george1421 More than you can shake a several dead cats at.
Alrighty… Murphy just showed for work.
All four good USB-based .efi solutions now hang .
bzimage... ok
init.xz... ok
then nothing
grrr … argh
@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?
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.
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
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?
It also tested fine with a 4GB key formatted to fat32. I don’t see why it wouldn’t also work on a 32GB key.
I pulled ipxe.efi from my RC23 FOG server.
Finding myself testing UEFI booting on Dell OptiPlex 790 I have some observations to post regarding the UEFI USB boot with iPXE.
Here is what I did.
1. CMD: diskpart
2. list disk
3. select disk # -- where # is the number representing your USB key listed by "list disk"
4. clean
5. create partition primary
6. select partition 1
7. format quick fs=fat32
8. active
9. exit
10. COPY <FOG>\tftpboot\ipxe.efi to <USB>:\efi\boot\bootx64.efi
USB Key size is not limited to 2GB. I successfully tested with a 1GB key.
Case does not matter. Never does with Windows.
Beginning with “@ iPXE 1.0.0+ (aa11ff) …” at any point in the process leading up to FOG actually launching, whenever you would expect a progress indicator (##%) or an ‘’… OK" to pop up, keyboard input must be made to continue. I must hold the space bar, enter or backspace key down to ensure the process continues to the next visual refresh.
eg: with a ##% progress, the display halts at say 12% … nothing else will happen until I hit space/enter/backspace. Next it goes to 15%. again, smack a key. etc, etc. So I hold the space bar down and it flies through everything.
Otherwise it works like a charm.
Aha, that’s why I didn’t find that post in a search. Can’t keyword search attached pictures.
Changing mine to
FOG_URL_AVAILABLE_TIMEOUT = 3000
… fixed it for me. Thank you.
Okay, but why did this start happening on RC23?
After upgrading from RC22 to RC23 the Dashboard display for Storage Node Disk Usage offers
Invalid storage node
Free: NaN%
0.00 iB
Used: NaN%
0.00 iB
… and an empty pull down.
To quote the Professor, good news everyone!
The problem is no longer a problem as of RC22.
Thank you again for all of your hard work.
I haven’t had a chance to check against the latest builds. I’ll be looking at it this week.