[ipxe-devel] Bug in http boot with uefi chainload

[Vishvananda Ishaya]

Hello everyone,

The fix for the efi timers that was pushed up
(commit 5cf5ffea2874434ffdc64c3242f2c53ed7ec1d40) fixes this issue. Thanks
Michael!

Vish

On Thu, Dec 1, 2016 at 2:45 PM Vishvananda Ishaya <vishvananda at gmail.com>
wrote:

> 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 <mcb30 at 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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ipxe.org/pipermail/ipxe-devel/attachments/20161207/8a67af27/attachment.htm>