There was a bug introduced earlier this year booting grub in uefi mode. Our setup looks like the following:
ipxe script: #!ipxe chain http://192.168.0.1/script.ipxe 192.168.0.1 is a webserver that serves up a grub.efi file and another script at /script.ipxe: #!ipxe chain grub.uefi This successfully chains into grub, but attempting to boot in grub fails: insmod net insmod efinet insmod http net_add_addr eno0 efinet0 192.168.10.10 set net_default_server=192.168.10.1 echo 'Loading kernel' linux (http)/kernel initrd=initrd console=ttyS0,9600 console=tty0 echo 'Loading initrd' initrd (http)/initrd boot The boot just hangs. With debug on, grub prints out a bunch of memory mapping statements like "mmap/efi/mmap.c:66: EFI memory region 0xff000000-0x100000000: 11" but eventually stops . This same process worked with an older version of ipxe. Git-bisect shows that the following commit as the offender: commit *757ab983811ac8d3f65efb65b8309738bd33bea3* Author: Michael Brown <mc...@ipxe.org> Date: Wed May 4 13:04:33 2016 +0100 [efi] Use a timer event to generate the currticks() timer For further verification if we git-revert both 694c18addc0dfdf51369f6d598dd0c8ca4bf2861 (which made a small modification to the timers) and 757ab983811ac8d3f65efb65b8309738bd33bea3 the boot process works again. We have tested using edk2 in qemu/kvm and real x86_64 hardware with the same result. This leads me to believe there is something wrong with the timer code, but it isn't obvious what it might be. Adding DEBUG=efi_timer:3 only seems to print the line "EFI timer started at 20 ticks per second". For now we have just reverted the patches since we don't need ARM support, but we would be happy to help test if anyone has an idea what might be causing the freeze. Vish
_______________________________________________ ipxe-devel mailing list ipxe-devel@lists.ipxe.org https://lists.ipxe.org/mailman/listinfo.cgi/ipxe-devel
