Yep, mcb30 (Michael Brown that wrote or co-wrote the thingy) in the given link seemingly suggested is that is possible INSTEAD of chainloading Wimboot (and use the initrd) to chainload directly the ipxe efi.
This part of direct chainloading the ipxe.efi seems to work just fine, what is not clear in the link is whether the user (that did not follow up) did some mistake in the settings or what created the issue, the relevant part of
Provide access to local files via the "file://" URI scheme. There are
three syntaxes:
- An opaque URI with a relative path (e.g. "file:script.ipxe").
This will be interpreted as a path relative to the iPXE binary.
- A hierarchical URI with a non-network absolute path
(e.g. "file:/boot/script.ipxe"). This will be interpreted as a
path relative to the root of the filesystem from which the iPXE
binary was loaded.
- A hierarchical URI with a network path in which the authority is a
volume label (e.g. "file://bootdisk/script.ipxe"). This will be
interpreted as a path relative to the root of the filesystem with
the specified volume label.
Note that the potentially desirable shell mappings (e.g. "fs0:" and
"blk0:") are concepts internal to the UEFI shell binary, and do not
seem to be exposed in any way to external executables. The old
EFI_SHELL_PROTOCOL (which did provide access to these mappings) is no
longer installed by current versions of the UEFI shell.
Isn't clear (at least to me) and I cannot find actual practical examples of the various syntaxes.
What were the contents of the boot.ipxe in your test?
Should be *something like*
kernel ${boot-url}/wimboot/wimboot gui pause
initrd ${boot-url}/wimboot/bcd BCD
initrd ${boot-url}/wimboot/boot.sdi boot.sdi
initrd ${boot-url}/wimboot/boot.wim boot.wim
boot || goto failed
I suspect that there are two separate things talked about in that thread (one thing is "local access" and another is "chianloading ipxe.efi and have it run the script).
In the screenshot on the given thread, the ipxe.efi loaded just fine, than a "menu.ipxe" failed to load, and seemingly the ipxe attempted to load it from several different (local) paths.
As always I would try to use the ipxe command line to load the (remote) wimboot and other files before attempting to use a script.
Wonko