[ipxe-devel] bootmgfw.efi and simple filesystem support

Jarrod Johnson jarrod.b.johnson at gmail.com
Sat May 18 23:16:34 UTC 2013


I was thinking about an optional script command to uninstall PxeBaseCode
from the device handle.  I haven't gotten to experiment/ask exactly how
bootmgfw.efi detects network versus fielesystem device.  I'm also not
positive it will work without subdirectory support yet.  My hope would be a
script seeking to 'spoof' a block device could do so without perturbing the
network aspect of the device handle.

The issue I see if always subjecting the chained efi executable to a brand
new (presumably non-pxe) device is that it would break working clients of
the ipxe download protocol.  This was my challenge with Geoff Lywood's
patch in the beginning, elilo broke pretty badly.  I suppose the argument
would be in this case you trick elilo, and esxboot in the same manner as
I'm trying to trick bootmgfw.efi.  However both esxboot and elilo support
for injecting the boot interface mac address would break...

I maintain that the best fix for snponly.efi breakage is to fall back to
device handle indicated by loaded handle if that handle provides SNP (or
check for PxeBaseCode).  This should retain the behavior when the full
stack is IPXE of using the generally better ipxe drivers, but also restore
snponly.efi.
Still haven't sat down to actually implement the check protocol support,
but it gives the general idea:
https://git.ipxe.org/vendor/xcat/ipxe.git/commitdiff/19447d9c39e06c3d5aabd198736cd23d8e40c870


On Wed, May 15, 2013 at 10:59 AM, Michael Brown <mcb30 at ipxe.org> wrote:

> On 13/05/13 20:20, Jarrod Johnson wrote:
>
>> Has anyone tried to get windows to do http transfer of wim using simple
>> filesystem support?  It seems that bootmgfw.efi has it's heart set on
>> tftp loading content if the loaded image suggests the boot device is
>> PXE-capable.
>>
>
> Haven't tried it yet.
>
> I'm wondering if efi_image.c needs to always create a new handle and
> install a new device path.  This would avoid some of the problems currently
> breaking snponly.efi, and might also persuade bootmgfw.efi to use the
> simple filesystem (since the handle would no longer also be an SNP device).
>
> Michael
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ipxe.org/pipermail/ipxe-devel/attachments/20130518/8dace935/attachment.htm>


More information about the ipxe-devel mailing list