FOG menu don't boot Windows - Chainloading failed
-
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.
-
@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
). -
@Sebastian-Roth
The secure boot is disable because when he is enable I can’t access fog menu
Same error :
-
@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.
-
@Sebastian-Roth With your new file:
NBP filesize is 1958 Bytes Downloading NBP file... Succeed to download NBP file.
Then windows boot.
-
@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
-
@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
-
@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
boot
:iPXE>boot No image selected
Sorry for the quality of pictures
-
@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?
-
@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.
-
@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… -
@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. -
@Sebastian-Roth I have a kernel panic on USB boot.
-
@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).
-
@Sebastian-Roth Result of your modify kernel :
After this screen, windows boot normally
-
@thomasdec Once again… try this ipxe.efi
-
@Sebastian-Roth Result :
-
@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
) -
@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!?
-
@thomasdec As well please run the following ipxe.efi (compiled with
DEBUG=efi_image
) to see what the exact error from LoadImage call is.