iPXE discussion forum

Hello,

our project (http://www.theforeman.org) provides functionality to generate bootdisk for individual hosts. These are either iPXE or SYSLINUX based without or with embedded linux kernel. The iPXE version does load the kernel/initramdisk directly via HTTP, users love this feature :-)

Now, we had no UEFI support, until now. I am able to implement SYSLINUX bootdisk type (we call it Full host image) with Grub2 and that was pretty simple. This should work even with SecureBoot.

I would like to add ipxe.efi into the image and be able to boot it, which is also doable either directly, or via chainbooting from Grub2. But the problem is, with SYSLINUX we've been able to provide the script via initramdisk:


This worked fine, but I am unable to do the same with chainloading from Grub:


Is there a way to tell iPXE where the script is located?

If I want to boot iPXE directly, is there any way (e.g. hardcoded path like /EFI_SCRIPT) that would work out-of-box? What I want to avoid is building iPXE from scratch (with embedded script).

Thanks for help!

The efi version should probably take a script in the same way as legacy but might not be as easy. ipxe should also take cmdline parameters and run them as a script so something like ipxe.efi echo Im Alive should show that message and then exit, maybe not a so useful version, but then there is the file:// uri extension in ipxe.efi
so together you might be able to do something like ipxe.efi chain file://script.ipxe
Don't know if you need to initrd script.ipxe to have it loaded or not tho.

I suppose this all should work via linuxefi command, right? I tried this via chainloader and it does not seem to work.

I am getting "error: invalid magic number" when I attempt to boot it via linuxefi:


I am using latest http://boot.ipxe.org/ipxe.efi and also tried with build from recent Fedora.

just tested to start ipxe.efi and then running:
dhcp && chain http://boot.ipxe.org/ipxe.efi echo test
does not show test
so ipxe efi version does not take cmdline as of yet.

however an embeded script with something like
Should probably work in your case, what is it that makes you not want to build ipxe yourself?

Yeah, this is indeed possible workaround. It's not as bad as compiling this everytime we generate an image.

Thanks, I am asking our colleagues at Red Hat how to handle that. https://bugzilla.redhat.com/show_bug.cgi?id=1401491

just sent a possible patch for efi cmdline to the mailinglist: http://lists.ipxe.org/pipermail/ipxe-dev...05306.html

And after that i looked on the redhat ticket and saw a similar implementation - the end result should be the same.

So does the chain file: approach work out?
And did the "error: invalid magic number" issue you mentioned on the mailing list get solved?

I've recompiled latest ipxe.efi today and attempted to use with grub2 efi from pxe
Still getting "error: invalid magic number" when booting via linuxefi
Also gets stuck at iPXE initialising devices if booting via chainloader

It may work better with booting from HDD, but I haven't tested as of yet

menuentry "Chainload iPXE - error: invalid magic number" {
linuxefi /ipxe/ipxe.efi
initrdefi /ipxe/menu.ipxe
}

menuentry "Chainload iPXE - pxeboot stuck at iPXE initialising devices" {
chainloader /ipxe/ipxe.efi
}

Not to detract from OP but if compiled with DEBUG=device,pci
iPXE initialising devices...Adding 3c509 root bus
Adding EFI root bus
0000:00:19.0 (8086:1502) has driver "825791m"
0000:00:19.0 has mem d07000000 io 2080 irq 255
0000:00:19.0 latency timer is unreasonably low at 0. Setting to 32.

(2016-12-18 02:07)ndog Wrote: [ -> ]I've recompiled latest ipxe.efi today and attempted to use with grub2 efi from pxe
Still getting "error: invalid magic number" when booting via linuxefi
Also gets stuck at iPXE initialising devices if booting via chainloader

It may work better with booting from HDD, but I haven't tested as of yet

Which version of ipxe is that? (git commit)

(2016-12-18 02:07)ndog Wrote: [ -> ]menuentry "Chainload iPXE - error: invalid magic number" {
linuxefi /ipxe/ipxe.efi
initrdefi /ipxe/menu.ipxe
}

Don't know why you would get a error (from grub!) from that but ipxe does not support script file loading via initrd loaded script (yet)

(2016-12-18 02:07)ndog Wrote: [ -> ]menuentry "Chainload iPXE - pxeboot stuck at iPXE initialising devices" {
chainloader /ipxe/ipxe.efi
}

Not to detract from OP but if compiled with DEBUG=device,pci
iPXE initialising devices...Adding 3c509 root bus
Adding EFI root bus
0000:00:19.0 (8086:1502) has driver "825791m"
0000:00:19.0 has mem d07000000 io 2080 irq 255
0000:00:19.0 latency timer is unreasonably low at 0. Setting to 32.

The debug output is normal so gives us nothing?
Does it work if you boot ipxe over the network without going via grub?

Hi NiKiZe
Thanks for your reply, ipxe efi works fine without going through grub. I think that magic number error has to do because grub efi is signed for secure boot. I will do further testing hopefully.

(2016-12-19 08:58)ndog Wrote: [ -> ]I think that magic number error has to do because grub efi is signed for secure boot.

To make sense in a secure boot environment a signed grub should only be able to boot efi executables that is signed by a key that grub approves of. So in that case yes it makes sense that you get a error - but one can hope that it would generate a bit more informative error message.

which version(s) is it of ipxe in those 2 files? (git commit id)

Folks,

I know this is a realitily old post, but I am on the same topic... I am trying to "chain" a ipxe script, but am unable to have success.

I have compiled the ipxe.efi with an "embed" script, the embedded script is meant to launch a more dynamic ipxe script in the ISO.

So - I am trying something like this within the embed script (simulare to the earlier post), trying to launch my ISO based script - which is in the same directory as the ipxe.efi module (launched by "chainloader" in grub2).


I have also tried the three mentioned
- relative: file:script.ipxe
- hierarchical : file:/efi/boot/script.ipxe
- with volume: file://MYISO/efi/boot/script.ipxe

Along with other variations.... no luck. With a debug flag turned on for the efi module when recompiled, I get this type of message:

iPXE> chain file:script.ipxe
LOCAL 0x77287d68 could not open filesystem on PciRoot(0x0)/Pci(0x1D,0x0)/USB(0x0,0x0)/USB(0x0,0x0):
Error 0x7f4de083 (http://ipxe.org/7f4de083)
LOCAL 0x77287d68 found no matching handle
Could not start download: No such file or directory (http://ipxe.org/2d4de08e)

I have tried several other syntax items using the iPXE shell.

Also - looking at other post, it does not appear I can pass the "script" with the chainloader command.

I am looking to see if from within a iPXE script, I can invoke another script, which is located at the same location as the ipxe.efi is located.

Note: my ISO is a virtual mounted iso, via iLO.

Hope to get a pointer/hint on what I am doing wrong, or other possible method. Re-compiling the second script into the ipxe.efi is not a viable option for me.

Thanks!

(2018-08-01 20:00)kd4 Wrote: [ -> ]I am trying to "chain" a ipxe script, but am unable to have success.

I have compiled the ipxe.efi with an "embed" script, the embedded script is meant to launch a more dynamic ipxe script in the ISO.

So - I am trying something like this within the embed script (simulare to the earlier post), trying to launch my ISO based script - which is in the same directory as the ipxe.efi module (launched by "chainloader" in grub2).

Code:

#!ipxe
prompt --key 0x02 --timeout 2000 Press Ctrl-B for the iPXE command line... && shell ||
chain file:script.ipxe

I have also tried the three mentioned
- relative: file:script.ipxe
- hierarchical : file:/efi/boot/script.ipxe
- with volume: file://MYISO/efi/boot/script.ipxe

What is the errors you get? (without having any debug enabled)
You do need to have an open network interface for iPXE to be able to chain anything. This is so it has anything to bind to. (but again which error messages do you get?, and make sure to include any urls that is displayed in that error message)

Not sure if grub makes any magic, but I wouldn't be surprised if you end up in a virtual mode, where there simply is no file in the same place.

Another thing to check is that you actually do have a valid FS where the file can be found, the efi shell can be quite useful for this.