FOG menu don't boot Windows - Chainloading failed

[thomasdec]

Hi,
when I choose “Boot from hard disk” I get error “chainloading failed” with “Exit” option, and when I use other option (sanboot, grub …) fog menu loop. I can’t access to windows.

If I choose “Quick registration” I get error :
“bzImage… ok”
“Could not select: Exec format error (http://ipxe.org/2e008081)”
“Could not boot: Exec format error (http://ipxe.org/2e008081)”
“Could not boot: Exec format error (http://ipxe.org/2e008081)”
“Chainloading failed, hit ‘s’ … reboot in 10 seconds”

I tested with the other file.efi in DHCP option on Windows 2012 with no result

I use FOG git version 7001 on Centos 7
Computer : Lenovo ThinkPad Yoga 11e, Windows 10, UEFI only, disable secure boot

FOG works fine with my other computer (Lenovo ThinkPad E550, legacy)

Thanks and sorry if my english is not good !

[Sebastian Roth]

@thomasdec said:

“bzImage… ok”
“Could not select: Exec format error (http://ipxe.org/2e008081)”

To me this sounds like your bzImage and/or init.xz file is corrupt. This should not happen with the new installer! Maybe it’s a network problem? iPXE NIC driver issue? The boot from hard disk problem could be related to this as well.

When you see the “Chainloading failed, hit ‘s’ … reboot in 10 seconds” message, please do so (hit s on your keyboard) and type exit. Does this boot to windows? If yes, then exit style EXIT should work as well!
Go to the ipxe shell again and try loading the kernel/init by hand:

ifstat
kernel bzImage loglevel=7 initrd=init.xz root=/dev/ram0 rw ramdisk_size=127000
imgfetch init.xz
boot

Please take a picture so we can see where exactly the errors happen.

[george1421]

@Sebastian-Roth Should the ipxe kernel know the root path to those files or do you need to specify the full http url to those files? The only reason why I ask is that by default ipxe should use tftp and (I don’t know if you don’t specify a path) will it look in the root directory of the dhcp (next-server) variable?

[Sebastian Roth]

@george1421 Good question! It’s not obvious but iPXE does remember the last used protocol, server and path! The menu came from http://x.x.x.x/fog/service/ipxe/boot.php and so it will request http://x.x.x.x/fog/service/ipxe/bzImage if you don’t specify differently.

[george1421]

@Sebastian-Roth Prefect answer. I just wanted to make sure there wasn’t any kind of magic going on in the kernel that wasn’t obvious.

[thomasdec]

Thanks for reply !

Type “exit” in iPXE -> return in Boot Menu, from this menu I can choose “Windows Boot Manager” and Windows start but not
automatically.

@Sebastian-Roth said:

Please take a picture so we can see where exactly the errors happen.

[Sebastian Roth]

@thomasdec I just tested loading kernel and init without the full URL again and it is working for me. This is kind of weird. Can you please try again using the URL (put your FOG server IP instead of x.x.x.x):

ifstat
kernel http://x.x.x.x/fog/service/ipxe/bzImage loglevel=7 initrd=init.xz root=/dev/ram0 rw ramdisk_size=127000
ifstat
imgfetch http://x.x.x.x/fog/service/ipxe/init.xz
ifstat
boot

[thomasdec]

@Sebastian-Roth

[thomasdec]

Result command :

[Sebastian Roth]

Those receive errors in the picture (“Operation not supported” and “The socket is not conected”) should not cause the problem. Those usually mean packet dropped because of unknown protocol (e.g. IPv6) or wrong destination (e.g. ignoring spanning tree broadcasts).

Sizes of bzImage and init.xz seam ok to me. As well the installer does checksums nowadays and we should not see corrupted kernels on the FOG server anymore.

[Sebastian Roth]

@thomasdec Are you absolutely sure secure boot is disabled?? I just remembered the imgstat command - please see what you get from:

kernel http://x.x.x.x/fog/service/ipxe/bzImage loglevel=7 initrd=init.xz root=/dev/ram0 rw ramdisk_size=127000
imgstat
imgfetch http://x.x.x.x/fog/service/ipxe/init.xz
imgstat
boot

If this is not giving us enough hints we might need to compile a debug enabled binary for you… Just noting down the debug flags here for later (realtek,netdevice,image).

[thomasdec]

@Sebastian-Roth
The secure boot is disable because when he is enable I can’t access fog menu
Same error :

[Sebastian Roth]

@thomasdec It seams like it is able to load the kernel via HTTP as imgstat shows correct file size as well. But it is not able to select it for booting. Usually this only happens if that kernel is older than version 3.16 because EFI_STUB was added then. But from what I have seen so far you are using the normal kernel that FOG installed for you and therefore should not have an issue with EFI_STUB!! So here is a debug enabled ipxe.efi binary for you to test - install on the FOG server like this:

sudo -i
cd /tftpboot
mv ipxe.efi ipxe.efi.orig
wget -O ipxe.efi https://forums.fogproject.org/uploads/files/1459426655465-ipxe.efi

Then boot your client. This will bring you straight to the shell now as I did not embed the full iPXE script we usually have. As well you will see colored debugging output. Try the exact same commands then last time and take picture(s) along the way.

[thomasdec]

@Sebastian-Roth With your new file:

NBP filesize is 1958 Bytes
Downloading NBP file...
Succeed to download NBP file.

Then windows boot.

[thomasdec]

@Sebastian-Roth Warning, I forgot the first line because it’s write on right side of sreen.
First line :
IMAGE shell.ipxe at [73470d8d) registered

[Sebastian Roth]

@thomasdec Looks good! What about the commands??

kernel http://x.x.x.x/fog/service/ipxe/bzImage loglevel=7 initrd=init.xz root=/dev/ram0 rw ramdisk_size=127000
imgstat
imgfetch http://x.x.x.x/fog/service/ipxe/init.xz
imgstat
boot

[thomasdec]

@Sebastian-Roth I add commande dhcp before the others command, without this command I get error “Network unreachable”

I think you have an error in your file.efi, when I execute dhcp, the same message loop appears (“NETDEV” in yellow) about dhcp command.

Result commad kernel http://x.x.x.x/fog/service/ipxe/bzImage loglevel=7 initrd=init.xz root=/dev/ram0 rw ramdisk_size=127000 :

Result command imgstat:

Result command imgfetche:

Result command imgstat:

Result command boot:

iPXE>boot
No image selected

Sorry for the quality of pictures

[Sebastian Roth]

@thomasdec Thanks for all the effort you put into debugging this! The pictures are perfect! Good that you found out about the dhcp command. I forgot to tell you. The yellow NETDEV messages appear because packets from your network arrive that iPXE is ignoring (as described in one of my earlier posts). So that’s ok.

Interestingly enough it seams to boil down to “bzImage is not an EFI”. In a chat session we downloaded and checksum tested the bzImage by hand again but run into the same error!! To me this feels like the bzImage is being corrupted when transfered from the FOG server to the client. We have talked about adding the trusted check to iPXE but we never did because pretty much all those issues disappeared right after Tom added the checksums to the installer not long ago! I am really wondering if I am going blind here or if the bzImage is actually being corrupted on the wire? Any ideas?

[george1421]

@Sebastian-Roth I still wonder if there IS an issue with iPXE transferring the FOS kernel to the client. You are right we did testing not to long ago where the bzImage would not load on a vmclient in efi mode. Then Tom did something (not related to checksum) and it started working in my test environment. I think that was FOS kernel 4.5.0 (or about there).

For this Lenovo Yoga, would having the OP build a grub boot flash drive give us any useful intelligence? I think it would give us an idea if the bzImage is at fault. The issue is the handoff between grub and ipxe to the bzImage is a bit different so it wouldn’t be a true like for like test.

[Sebastian Roth]

@george1421 I thought about flash drive testing as well but as you already said this is quite different in how the kernel is loaded in UEFI mode. The only test that makes any sense from my point of view is loading the kernel straight from a usb key. None of the other methods would actually enter the kernel trough the EFI_STUB. I really hope that we haven’t found another UEFI firmare bug (like with the HP x2 210 - which is still not solved although I have a direct contact to those firmware guys now!!)

@thomasdec I know you are in the weekend already but could you please try this when you get back next week? Get a usb key, empty, format with FAT/VFAT/FAT32 and put the bzImage from your FOG server on the usb key. The path and filename need to be exactly like this: EFI\BOOT\BOOTX64.EFI (windows) - EFI/BOOT/BOOTX64.EFI (if your prepare the usb key on a linux machine, both should work!). Then boot your Yoga from this usb key in (UEFI mode). Either you will see an error from the firmware or plain reboot or hang. Then I guess we have a firmware bug. Otherwise you will see some kernel boot messages and then a kernel panic - which is totally fine because booting the bzImage on its own does not work. But at least we see that the kernel is loading…