UEFI Network Boot: loop and exec format error

[altsysrq]

Is there a resource I am overlooking for compiling and setting up a UEFI network boot through PXE? Otherwise, I am not sure what I am doing wrong. Any ideas?

Compiling myself:
When attempting to compile iPXE I don't get any errors, but when booting to the ipxe.efi file on the client I get a loop where it tries to download the file, succeeds and then tries to download again. There does not seem to be an error message or I am missing it. Compiled master from last change (Wed, 6 Jan 2016 12:55:08 -0600 (18:55 +0000)). Changing the config in config/general.h does not seem to make a difference, although, I have tried with changes and without. I may be missing something there.

Precompiled:
ipxe.efi downloaded from the bottom of the page here: http://ipxe.org/howto/chainloading

When I ctrl-b and run chain ipxe/menu.ipxe, then select CentOS 6.5 I get "Could not select: Exec format error (http://ipxe.org/2e008081)." Searching for the error I did not find anything. I tried this with a test CentOS menu item with http:// and nfs://.

Hardware:
HP DL60 Gen9
HP Ethernet 1Gb 2-port 361i Adapter
(up to date firmware as of 11/2015)

menu.ipxe:

Code:

#!ipxe

:start
menu PXE Client Menu
item centos65   CentOS 6.5
item netbootall Network Boot Multiple OS Test
choose target && goto ${target}

:centos65
kernel http://10.10.10.1/installs/centos-65-net/images/pxeboot/vmlinuz initrd=http://10.10.10.1/installs/centos-65-net/images/pxeboot/initrd.img
initrd http://10.10.10.1/installs/centos-65-net/images/pxeboot/initrd.img
boot

:netbootall
chain http://boot.salstar.sk

dhcpd.conf:

Code:

# The ddns-updates-style parameter controls whether or not the server will
# attempt to do a DNS update when a lease is confirmed. We default to the
# behavior of the version 2 packages ('none', since DHCP v2 didn't
# have support for DDNS.)
ddns-update-style none;

# If this DHCP server is the official DHCP server for the local
# network, the authoritative directive should be uncommented.
#authoritative;

ddns-domainname     "domain.company.com";
ddns-rev-domainname    "in-addr.arpa.";
option domain-search "test.company.com";
option domain-name "test.domain.company.com";
option domain-name-servers 172.16.0.179, 172.16.0.177;
default-lease-time 604800;
max-lease-time 604800;
ignore client-updates;
authoritative;

## EFI options
option architecture-type code 93 = unsigned integer 16;

##iPXE Options
option space ipxe;
option ipxe-encap-opts code 175 = encapsulate ipxe;
option ipxe.priority code 1 = signed integer 8;
option ipxe.keep-san code 8 = unsigned integer 8;
option ipxe.skip-san-boot code 9 = unsigned integer 8;
option ipxe.syslogs code 85 = string;
option ipxe.cert code 91 = string;
option ipxe.privkey code 92 = string;
option ipxe.crosscert code 93 = string;
option ipxe.no-pxedhcp code 176 = unsigned integer 8;
option ipxe.bus-id code 177 = string;
option ipxe.bios-drive code 189 = unsigned integer 8;
option ipxe.username code 190 = string;
option ipxe.password code 191 = string;
option ipxe.reverse-username code 192 = string;
option ipxe.reverse-password code 193 = string;
option ipxe.version code 235 = string;
option iscsi-initiator-iqn code 203 = string;

# Feature indicators
option ipxe.pxeext code 16 = unsigned integer 8;
option ipxe.iscsi code 17 = unsigned integer 8;
option ipxe.aoe code 18 = unsigned integer 8;
option ipxe.http code 19 = unsigned integer 8;
option ipxe.https code 20 = unsigned integer 8;
option ipxe.tftp code 21 = unsigned integer 8;
option ipxe.ftp code 22 = unsigned integer 8;
option ipxe.dns code 23 = unsigned integer 8;
option ipxe.bzimage code 24 = unsigned integer 8;
option ipxe.multiboot code 25 = unsigned integer 8;
option ipxe.slam code 26 = unsigned integer 8;
option ipxe.srp code 27 = unsigned integer 8;
option ipxe.nbi code 32 = unsigned integer 8;
option ipxe.pxe code 33 = unsigned integer 8;
option ipxe.elf code 34 = unsigned integer 8;
option ipxe.comboot code 35 = unsigned integer 8;
option ipxe.efi code 36 = unsigned integer 8;
option ipxe.fcoe code 37 = unsigned integer 8;
option ipxe.vlan code 38 = unsigned integer 8;
option ipxe.menu code 39 = unsigned integer 8;
option ipxe.sdi code 40 = unsigned integer 8;
option ipxe.nfs code 41 = unsigned integer 8;

# Use this to send dhcp log messages to a different log file (you also
# have to hack syslog.conf to complete the redirection).
log-facility local7;

subnet 10.10.10.0 netmask 255.255.255.0 {
  option routers 10.10.10.1;
  option subnet-mask 255.255.255.0;
  option broadcast-address 10.10.10.255;

## remove this when on dhcp proxy/relay
    option ipxe.no-pxedhcp 1;

  option domain-name "test.mbx.com";
    range 10.10.10.21 10.10.10.254;
    default-lease-time 1300;
    if option architecture-type = 00:09 {
      filename "ipxe/ipxe.efi";
      next-server 10.10.10.1;
    } elsif option architecture-type = 00:07 {
      filename "ipxe/ipxe.efi";
      next-server 10.10.10.1;
    } else {
      filename "bios/pxelinux.0";
      next-server 10.10.10.1;
    }
    option root-path "/srv/fsroot";
    ddns-update-style none;
  }

[NiKiZe]

(2016-01-06 22:01)altsysrq Wrote:  Is there a resource I am overlooking for compiling and setting up a UEFI network boot through PXE? Otherwise, I am not sure what I am doing wrong. Any ideas?

Compiling myself:
When attempting to compile iPXE I don't get any errors, but when booting to the ipxe.efi file on the client I get a loop where it tries to download the file, succeeds and then tries to download again. There does not seem to be an error message or I am missing it. Compiled master from last change (Wed, 6 Jan 2016 12:55:08 -0600 (18:55 +0000)). Changing the config in config/general.h does not seem to make a difference, although, I have tried with changes and without. I may be missing something there.

Precompiled:
ipxe.efi downloaded from the bottom of the page here: http://ipxe.org/howto/chainloading

When I ctrl-b and run chain ipxe/menu.ipxe, then select CentOS 6.5 I get "Could not select: Exec format error (http://ipxe.org/2e008081)." Searching for the error I did not find anything. I tried this with a test CentOS menu item with http:// and nfs://.

The boot loop sounds like the one described at http://ipxe.org/howto/chainloading#break...inite_loop

How does the precompiled ipxe.efi behave differently from the one you compiled yourself?

Efi environment only supports booting efi executables. To boot a Linux kernel in EFI mode it needs to be compiled with EFI_STUB enabled. A recent thread with this issue on CentOS 6.5: http://forum.ipxe.org/showthread.php?tid=7726

Edit: Sorry, missed part of your dhcpd.conf
you want something like this :

Code:

next-server 10.10.10.1;
if exists user-class and option user-class = "iPXE" {
      filename "ipxe/menu.ipxe";
  } elsif option architecture-type = 00:09 {
....

First we move out next-server since it is set to the same for all cases.
Next we add an if at the top that runs if it is iPXE that starts, and in that case we send the path to the script instead of the ipxe executable itself.
That way it will stop loop booting

[altsysrq]

Thank you for the quick response.

I left out the command I used to compile. The bootloop should have been disrupted with my EMBED setting. But I could have done something wrong of course. I was unable to get a prompt to come up or a simple shell using either a prompt command, shell, or pause command inside the script.ipxe. It seems like it downloads the file and then errors, but if there are any errors it is too fast to see. Here is the compile command:
make bin/undionly.kpxe EMBED=../../script.ipxe

The precompiled gives me a ctrl-b option where I can manually dhcp and chain to my menu.ipxe file. This works, but I would like to automate this without any typing. Ideally, I would like to compile it myself as I am sure this will make things easier in the future as updates are applied to iPXE.

[NiKiZe]

(2016-01-06 23:34)altsysrq Wrote:  make bin/undionly.kpxe EMBED=../../script.ipxe

The precompiled gives me a ctrl-b option where I can manually dhcp and chain to my menu.ipxe file. This works, but I would like to automate this without any typing. Ideally, I would like to compile it myself as I am sure this will make things easier in the future as updates are applied to iPXE.

When you embed a script the ctrl+b prompt is disabled.
Note that make command will create an legacy file, that won't work in efi mode. Do you see the iPXE version header printed on screen with this file at all? (or atleast "iPXE initialising devices...")

To compile a 64bit ipxe.efi file use make bin-x86_64-efi/ipxe.efi EMBED=../../script.ipxe

If you post contents of your embeded script we can check if there might be anything wrong there.

There is also script debugging that can be enabled with a command like:
make bin-x86_64-efi/ipxe.efi EMBED=../../script.ipxe DEBUG=script

script in this case refers to that scripts is handled by the script.c source file.

[MultimediaMan]

iPXE is working for you...

The problem is CentOS 6 (As well as Scientific Linux 6 and RHEL6) do not have the "EFI_STUB" option compiled into their kernels... i.e. they are not valid EFI Binaries.

You need to boot (on the ISO) EFI/BOOT/BOOTX64.efi

You can use iPXE to do it... but it's hardly worth it.

Another recent relevant thread: Here.

[altsysrq]

Thank you for the responses.

Here is one example of my script.ipxe:

Code:

#!ipxe

chain ipxe/menu.ipxe

## provide a prompt in the event that the menu is not accessible or there are other issues.
prompt --key 0x02 --timeout 10000 Press Ctrl-B for the iPXE command line... && shell ||

As a test I have also tried simply:

Code:

#!ipxe
shell

Quote:The problem is CentOS 6 (As well as Scientific Linux 6 and RHEL6) do not have the "EFI_STUB" option compiled into their kernels... i.e. they are not valid EFI Binaries.
You need to boot (on the ISO) EFI/BOOT/BOOTX64.efi
You can use iPXE to do it... but it's hardly worth it.

It seems I have 2 issues here. Lets bypass the CentOS 6.5 issue in this thread. I will look at the other threads recommended to fix that and if I run into further issues I can create a new thread.

Quote:Note that make command will create an legacy file, that won't work in efi mode. Do you see the iPXE version header printed on screen with this file at all? (or atleast "iPXE initialising

I did not get any of that.

Quote:There is also script debugging that can be enabled with a command like:
make bin-x86_64-efi/ipxe.efi EMBED=../../script.ipxe DEBUG=script

No change with the ixpe.efi compile. I get as far as Downloading the NBP successfully but nothing else shows up.

Quote:script in this case refers to that scripts is handled by the script.c source file.

Thank you for the clarification.

Quote:There is also script debugging that can be enabled with a command like:
make bin-x86_64-efi/ipxe.efi EMBED=../../script.ipxe DEBUG=script

The above suggestions plus installing (for reference to others):

Code:

apt-get install binutils-dev lib32z1-dev libiberty-dev

This is the kicker for me. I was not doing this. When I tried it it worked. Consider this thread solved.

I have other issues, but I will need to research those and find out what I am doing wrong.

[MultimediaMan]

Quote:

Code:

:centos65
kernel http://10.10.10.1/installs/centos-65-net/images/pxeboot/vmlinuz initrd=http://10.10.10.1/installs/centos-65-net/images/pxeboot/initrd.img
initrd http://10.10.10.1/installs/centos-65-net/images/pxeboot/initrd.img
boot

You may have a syntax error; if you are invoking the initrd with vmlinuz you need to specify you are using initrd loaded into memory: UEFI is ~really~ picky about explicitly specifying the initrd in the vmlinuz arguments. PCBIOS would "figure it out", but in UEFI, it just craps out and panics the vmlinuz kernel when vmlinuz attempts to locate the initrd.img; vmlinuz doesn't have a network stack yet, so this is crucial.

Amended code:

Code:

:centos65
initrd http://10.10.10.1/installs/centos-65-net/images/pxeboot/initrd.img
kernel http://10.10.10.1/installs/centos-65-net/images/pxeboot/vmlinuz initrd=initrd.img
boot

[altsysrq]

Quote:You may have a syntax error; if you are invoking the initrd with vmlinuz you need to specify you are using initrd loaded into memory: UEFI is ~really~ picky about explicitly specifying the initrd in the vmlinuz arguments. PCBIOS would "figure it out", but in UEFI, it just craps out and panics the vmlinuz kernel when vmlinuz attempts to locate the initrd.img; vmlinuz doesn't have a network stack yet, so this is crucial.

Thank you for bringing that up. I struggled with that a little bit.