Access to Current Working URI (cwuri) about ipxe HOT 12 OPEN

Rational behind this: when we have the option to know where the initial iPXE image came from at runtime of the iPXE script we can load additional ressources from that location without the need to hardcode the server / location in the iPXE script. This provides great flexibility for any dynamic chainloading process. A single image can then be used to have the same install procedure in different geographical locations / on-/off-prem and so on (distributed) where latency and bandwidth would make it hard to serve dynamic data from a single source.

from ipxe.

If you do imgfetch script.ipxe, that should already be relative, no need to get or mangle the URL?

from ipxe.

Well, not quite. This works only for TFP or mounted filesystems (resolved as a relative filepath) but not if the image was loaded from an URL e.g. using EFI HTTP(S) boot.

from ipxe.

In that case, how was the initial script to iPXE provided?

from ipxe.

UEFI HTTP Boot. The URL to the initial image is provided to UEFI as a boot option. The initial image can contain a generic (generic to the extend that it doesn't need to include any static URLs / data but can load anything dynamicly depending on where it was initially loaded from) embedded ipxe script that can then chainload more specific scripts from a path relative to where the image came from.

I had this working about 2 years ago already up to the point where I need to get the cwuri to load additional content from a url relative to the image location. That's what this issue / request is for.

@mcb30 suggested a patch back then that does the groundwork to implement this which I think was implemented a couple of months ago, quote:
having looked at the UEFI specs: I think the loaded image device path should contain the URI from which the iPXE image was booted. We could plausibly use this to set the initial current working URI, which should make relative paths work.

•  diff --git a/src/interface/efi/efi_init.c b/src/interface/efi/efi_init.c
•  index ed9707f2c..a87ecdce7 100644
•  --- a/src/interface/efi/efi_init.c
•  +++ b/src/interface/efi/efi_init.c
•  @@ -100,6 +100,10 @@ EFI_STATUS efi_init ( EFI_HANDLE image_handle,
•          struct efi_protocol *prot;
•          struct efi_config_table *tab;
•          void *loaded_image;
•  +       union {
•  +               EFI_DEVICE_PATH_PROTOCOL *path;
•  +               void *interface;
•  +       } path;
•          EFI_STATUS efirc;
•          int rc;
•   
•  @@ -175,6 +179,22 @@ EFI_STATUS efi_init ( EFI_HANDLE image_handle,
•          DBGC ( systab, "EFI image base address %p\n",
•                 efi_loaded_image->ImageBase );
•   
•  +       /* Get loaded image device path */
•  +       if ( ( efirc = bs->OpenProtocol ( image_handle,
•  +                               &efi_loaded_image_device_path_protocol_guid,
•  +                               &path.interface, image_handle, NULL,
•  +                               EFI_OPEN_PROTOCOL_GET_PROTOCOL ) ) != 0 ) {
•  +               rc = -EEFI ( efirc );
•  +               DBGC ( systab, "EFI could not get loaded image device path "
•  +                      "protocol: %s", strerror ( rc ) );
•  +               /* Treat as non-fatal */
•  +               path.path = NULL;
•  +       }
•  +       if ( path.path ) {
•  +               DBGC ( systab, "EFI loaded device path: %s\n",
•  +                      efi_devpath_text ( path.path ) );
•  +       }
•  +
•          /* EFI is perfectly capable of gracefully shutting down any
•           * loaded devices if it decides to fall back to a legacy boot.
•           * For no particularly comprehensible reason, it doesn't

But as of today it's not possible to access that cwuri from a iPXE script (and relative paths do not work as well when the image was loaded from UEFI HTTP / HTTP boot)

from ipxe.

For what it is worth: I just stumbled upon http://boot.ipxe.org/tinycore.ipxe which has this content:

#!ipxe

set base http://tinycorelinux.net/11.x/x86/release/distribution_files

cpuid --ext 29 && set arch 64 || set arch

kernel ${base}/vmlinuz${arch} initrd=rootfs.gz initrd=modules${arch}.gz
initrd ${base}/rootfs.gz
initrd ${base}/modules${arch}.gz
boot

in ${base} do I see ${cwuri}.

( Now time will tell what the effect is of touching this stalled issue ... )

from ipxe.

@stappersg

no worries. I'm still watching this issue and hoping for it to be implemented.
The example you made does use simple variable definition and access. The variable base is created with a URL hardcoded in the iPXE script we're looking at. Then it's used. We're already doing that and the feature is documented for iPXE in the normal iPXE scripting guide.

The problem with that approach is that you have to hardcode your URI in your iPXE script. This restricts the use of your iPXE script / images to a location. If you want to use the same image in another location you'd have to change the iPXE script so it does point to a different source that's reachable.

This feature request is about providing a method to provide access to a dynamic variable, let's call it cwuri, which will always return the uri the current iPXE script was loaded from. E.g. if the script was loaded from https://my-ipxe-server/base/ then using ${cwuri}/some/next/image.gz would be resolved to https://my-ipxe-server/base/some/next/image.gz. Yet, since the URI is not hardcoded you could place that same image on another server, say https://my-other-ipxe-server/base/ and ${cwuri}/some/next/image.gz would be resolved to https://my-other-ipxe-server/base/some/next/image.gz.

Note that URI doesn't have to be a URL. It could be any URI supported by iPXE such as file://path-to-the-location-this-current-script/was/loaded/from.ipxe

As a addition it would be awesome if you can then access specific parts of the URI such as the protocol using dynamic variables. E.g. cwuri-proto would return http, https or file and so on. Basic URI parsing and making the result available to be used in iPXE scripts.

That's all this feature request is about.

from ipxe.

from ipxe.

@stappersg

didn't know feature requests are ment only for those having the skills to implement them. I'm doing my part here trying to explain as good as I can what the feature is and what benefits it would bring to iPXE. But sure, if that's unwanted in this project then consider this issue as closed.

Suggestion for the project description:
Use it and be happy with it. We're not interested in valuable feedback from users if it's not written in C.

from ipxe.

@omniproc thank you for the request, Not sure if the information is actually available, how is the http url sent to the client in the first place? (DHCP?)

(sorry that you got that bad kind of response)

from ipxe.

Oh never mind you already kind of answered this 😅

from ipxe.

thank you for the request, Not sure if the information is actually available, how is the http url sent to the client in the first place? (DHCP?)

You're very welcome. I think the feature should be (if possible) independent of the way the http URL is set. It could be DHCP but in my case we're using UEFI HTTP boot. I know that many ppl. are still unaware of UEFI HTTP boot (altought the spec is quite old by now) so please let me know if you need more details but basically you can submit the URL to UEFI by whatever means your UEFI firmware supports (e.g. with HP servers you could do that using their OoBM named ILO).

(sorry that you got that bad kind of response)

Nothing to be sorry for. You're not responsible for stuff random GitHub users respond and I know that you guys who actually contributed alot to this project are thankful for feedback (confirmed multiple times in IRC already).

from ipxe.