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

Reply via email to