FOG menu don't boot Windows - Chainloading failed

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

[george1421]

@Sebastian-Roth Is there any value in seeing if the OP an boot from a live linux image in efi mode, like the ubuntu desktop live?

(Just thinking out loud here)
Now that I think about it, it would also use grub to boot that image, so that wouldn’t be a good test. And having us efi boot ipxe from the flash drive then pull the bzImage from the server, would give us the same results as pxe booting. What would be great is if we could tell the ipxe kernel to load the bzImage from the local flash drive instead of the network.

[thomasdec]

@Sebastian-Roth I have a kernel panic on USB boot.

[Sebastian Roth]

@thomasdec Here is a signature file bzImage.sig for the current kernel image ( @Tom-Elliott I hope you don’t intend to update the official kernel images right now - would break my signature file…).

As well you need a “special” ipxe.efi binary (CA cert included).

[thomasdec]

@Sebastian-Roth Result of your modify kernel :

After this screen, windows boot normally

[Sebastian Roth]

@thomasdec Once again… try this ipxe.efi

[thomasdec]

@Sebastian-Roth Result :

[Sebastian Roth]

@thomasdec This is another very weird thing here LoadImage (EFI) function is not able to lead the bzImage although it seams to be intact (file size and signature checked)! So we need to dig into the EFI calls. Please try this ipxe.efi (compiled with DEBUG=efi_wrap)

[Sebastian Roth]

@thomasdec Have you ever tried booting other UEFI machines?? Please do so! We wanna make sure if this is an issue with FOG/network/setup or if it is a client/Yoga issue!?

[Sebastian Roth]

@thomasdec As well please run the following ipxe.efi (compiled with DEBUG=efi_image) to see what the exact error from LoadImage call is.