ipxe / ipxe Goto Github PK

i believe a feature similar to Systemd's efi creation would be helpful. The official instructions for embedding an image are here, and require compiling the binary from scratch.

Systemd allows for creating bootable EFI kernels by doing something like:

objcopy \
        --add-section .osrel=/etc/os-release --change-section-vma .osrel=0x20000 \
        --add-section .cmdline="$cmdline" --change-section-vma .cmdline=0x30000 \
        --add-section .linux="$kernel_image" --change-section-vma .linux=0x40000 \
        --add-section .initrd="$initramfs_image" --change-section-vma .initrd=0x3000000 \
        "linuxx64.efi.stub" "$combined_image".efi

This is the source code for that.

It would be awesome f the code could check for a ".script" section, and if it exists, run that script. This would mean that no re-compilation is needed. Especially for an EFI binary.

Currently failing to EFI pxe boot a HP Z840. I believe it to be a IPV6/EFI issue. When booting legacy I am able to pxe boot no problem but when switching to UEFI, iPXE initialize devices. I currently have these debug build flags DEBUG=efi_driver,snpnet,pci,efi_pxe,efi_pci,ipv6

I have tried commenting out this include from this MR. https://github.com/ipxe/ipxe/pull/84/files#diff-8d5c900320c89e96f4a0e5efbf4ae6450ee32eafb5189890897fb00830959bfbR26 But still run into the above error. Any assistance would be greatly appreciated.

git pull origin master

If I leave //#define CONSOLE_SERIAL then the snp.efi and ipxe.efi compile just fine, the menu loads on my ARM64 SoC, but the serial input is disabled.

However, when I edit src/config/console.h to enable console

#define CONSOLE_SERIAL          /* Serial port console */

And run make on an SoC with ArmV8 (Arm64) with the latest aarch64 tool chain

make ARCH=arm64 bin-arm64-efi/snp.efi -j8

The failure is

  ... snip ...
  [VERSION] bin-arm64-efi/version.snp.efi.o
  [HOSTCC] util/elf2efi64
  [AR] bin-arm64-efi/blib.a
ar: creating bin-arm64-efi/blib.a
  [LD] bin-arm64-efi/snp.efi.tmp
ld: bin-arm64-efi/blib.a(serial.o): in function `serial_init':
/ipxe/src/core/serial.c:145: undefined reference to `uart_select'
ld: bin-arm64-efi/blib.a(serial.o): in function `uart_data_ready':
/ipxe/src/include/ipxe/uart.h:112: undefined reference to `uart_read'
ld: /ipxe/src/include/ipxe/uart.h:112: undefined reference to `uart_read'
ld: bin-arm64-efi/blib.a(serial.o): in function `uart_receive':
/ipxe/src/include/ipxe/uart.h:124: undefined reference to `uart_read'
ld: bin-arm64-efi/blib.a(uart.o): in function `uart_transmit':
/ipxe/src/core/uart.c:54: undefined reference to `uart_read'
ld: /ipxe/src/core/uart.c:61: undefined reference to `uart_write'
ld: bin-arm64-efi/blib.a(uart.o): in function `uart_flush':
/ipxe/src/core/uart.c:75: undefined reference to `uart_read'
ld: /ipxe/src/core/uart.c:76: undefined reference to `uart_read'
ld: bin-arm64-efi/blib.a(uart.o): in function `uart_exists':
/ipxe/src/core/uart.c:95: undefined reference to `uart_write'
ld: /ipxe/src/core/uart.c:96: undefined reference to `uart_read'
ld: /ipxe/src/core/uart.c:98: undefined reference to `uart_write'
ld: /ipxe/src/core/uart.c:99: undefined reference to `uart_read'
ld: bin-arm64-efi/blib.a(uart.o): in function `uart_init':
/ipxe/src/core/uart.c:124: undefined reference to `uart_read'
ld: /ipxe/src/core/uart.c:126: undefined reference to `uart_write'
ld: /ipxe/src/core/uart.c:131: undefined reference to `uart_write'
ld: /ipxe/src/core/uart.c:132: undefined reference to `uart_write'
ld: /ipxe/src/core/uart.c:138: undefined reference to `uart_write'
ld: /ipxe/src/core/uart.c:141: undefined reference to `uart_write'
ld: bin-arm64-efi/blib.a(uart.o):/ipxe/src/core/uart.c:144: more undefined references to `uart_write' follow
ld: bin-arm64-efi/blib.a(uart.o): in function `uart_init':
/ipxe/src/core/uart.c:134: undefined reference to `uart_read'
ld: /ipxe/src/core/uart.c:135: undefined reference to `uart_read'
ld: bin-arm64-efi/snp.efi.tmp: hidden symbol `uart_select' isn't defined
ld: final link failed: bad value

From https://github.com/ipxe/ipxe/search?q=uart_select I can see that these missing UART methods are present in the x86 version of uart.c: src/arch/x86/core/x86_uart.c but no where else.

The problem I'm trying to solve is the iPXE menu doesn't recognize keyboard commands like up, down, nor enter. Even chain booting to an iPXE shell doesn't allow typing at all. Suggestions?

uname -a
Linux sopine 3.10.105-bsp-1.2-ayufan-136 ipxe/ipxe#1 SMP PREEMPT Sat Oct 27 21:18:35 UTC 2018 aarch64 Linux

I'm trying to build ipxe efi for x86_64 and came across this build failure. I first came across this with gcc version 9.3.0 (GCC) and can reproduce with newer GCCs also. I haven't tried going back to see when it broke but can do so if needed.

I can reproduce as follows:

[manny@dellnix:~/cloned/ipxe/ipxe]$ git status
On branch master
Your branch is up to date with 'origin/master'.

nothing to commit, working tree clean

[manny@dellnix:~/cloned/ipxe/ipxe]$ git describe --tags
v1.21.1-6-ga5fb4187

[manny@dellnix:~/cloned/ipxe/ipxe]$ cat ../shell.nix | tee shell.nix
let _pkgs = import <nixpkgs> { };
in { pkgs ? import (_pkgs.fetchFromGitHub {
  owner = "NixOS";
  repo = "nixpkgs";
  #branch@date: nixpkgs@2020-11-24
  rev = "6625284c397b44bc9518a5a1567c1b5aae455c08";
  sha256 = "1w0czzv53sg35gp7sr506facbmzd33jm34p6cg23fb9kz5rf5c89";
}) { } }:

with pkgs;

mkShell {
  buildInputs = [
    gcc
  ];
}

[manny@dellnix:~/cloned/ipxe/ipxe]$ nix-shell
bash: /home/manny/.fzf/shell/key-bindings.bash: No such file or directory

[nix-shell:~/cloned/ipxe/ipxe]$ cd src

[nix-shell:~/cloned/ipxe/ipxe/src]$ make bin-x86_64-efi/ipxe.efi -j$(nproc)
make: /bin/echo: No such file or directory
make: /bin/echo: No such file or directory
rm -f bin-x86_64-efi/*.*  bin-x86_64-efi/.certificate.* bin-x86_64-efi/.certificates.* bin-x86_64-efi/.private_key.* bin-x86_64-efi/errors	bin-x86_64-efi/NIC	./util/zbin ./util/elf2efi32 ./util/elf2efi64 ./util/efirom ./util/efifatbin ./util/iccfix ./util/einfo TAGS bin-x86_64-efi/symtab
  [DEPS] arch/x86/transitions/librm.S
  [DEPS] arch/x86/transitions/libkir.S
  [PARSEROM]
  [DEPS] arch/x86/transitions/libpm.S
  [DEPS] arch/x86/prefix/usbdisk.S
  [DEPS] arch/x86/transitions/liba20.S
...
  [BUILD] bin-x86_64-efi/mca.o
  [BUILD] bin-x86_64-efi/pcibackup.o
  [BUILD] bin-x86_64-efi/pci.o
  [BUILD] bin-x86_64-efi/pciea.o
drivers/bus/isa.c: In function ‘isabus_probe’:
drivers/bus/isa.c:52:4: error: array subscript [-2147483648, -1] is outside array bounds of ‘isa_probe_addr_t[0]’ {aka ‘short unsigned int[0]’} [-Werror=array-bounds]
   52 |    *( isa_extra_probe_addrs + (ioidx) + ISA_EXTRA_PROBE_ADDR_COUNT ) )
      |    ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
drivers/bus/isa.c:113:18: note: in expansion of macro ‘ISA_IOADDR’
  113 |    isa->ioaddr = ISA_IOADDR ( driver, ioidx );
      |                  ^~~~~~~~~~
drivers/bus/isa.c:34:25: note: while referencing ‘isa_extra_probe_addrs’
   34 | static isa_probe_addr_t isa_extra_probe_addrs[] = {
      |                         ^~~~~~~~~~~~~~~~~~~~~
cc1: all warnings being treated as errors
make: *** [Makefile.housekeeping:943: bin-x86_64-efi/isa.o] Error 1
make: *** Waiting for unfinished jobs....

[nix-shell:~/cloned/ipxe/ipxe/src]$ 

This requires having nix installed, alternatively with docker:

[manny@dellnix:~/cloned/ipxe/ipxe]$ docker run --rm -ti -v $PWD:/ipxe -w /ipxe -e NIX_PATH=nixpkgs=https://github.com/NixOS/nixpkgs/archive/6625284c397b44bc9518a5a1567c1b5aae455c08.tar.gz nixos/nix:2.3.6

f732121730e2:/ipxe# nix-shell -p gcc
unpacking 'https://github.com/NixOS/nixpkgs/archive/6625284c397b44bc9518a5a1567c1b5aae455c08.tar.gz'...
these paths will be fetched (54.75 MiB download, 243.85 MiB unpacked):
  /nix/store/1n34g5xxfy395xzh8d5xk6dq2c2rnx2b-glibc-2.32-dev
  /nix/store/20i4573zsrxagw7mcn5adyd5m4f6a11l-ncurses-6.2
  /nix/store/31hnbrb3b3j6wlp43shjwa688mfzif2r-bzip2-1.0.6.0.1
  /nix/store/53nwh281zm213kg505mrp3g5qwdsnjbs-patch-2.7.6
  /nix/store/58q0ygc01jba5cf5zghc0dlhx187mskk-gcc-9.3.0
...
copying path '/nix/store/79rshjqnibwcx468m4i31wnmasaj6nf4-binutils-2.31.1' from 'https://cache.nixos.org'...
copying path '/nix/store/58q0ygc01jba5cf5zghc0dlhx187mskk-gcc-9.3.0' from 'https://cache.nixos.org'...
copying path '/nix/store/rqhvcy5zmlypr9qfa43npsyxsxjg7jxa-binutils-wrapper-2.31.1' from 'https://cache.nixos.org'...
copying path '/nix/store/n3r351j7vfr2bv95fp6miz3l8741jdb4-gcc-wrapper-9.3.0' from 'https://cache.nixos.org'...
copying path '/nix/store/frh7ir9rcv19b3ym33ck64s813yr3xrr-stdenv-linux' from 'https://cache.nixos.org'...

[nix-shell:/ipxe]# make -C src/ bin-x86_64-efi/ipxe.efi
make: Entering directory '/ipxe/src'
/bin/sh: git: not found
/bin/sh: perl: not found
rm -f bin-x86_64-efi/*.*  bin-x86_64-efi/.certificate.* bin-x86_64-efi/.certificates.* bin-x86_64-efi/.private_key.* bin-x86_64-efi/errors	bin-x86_64-efi/NIC	./util/zbin ./util/elf2efi32 ./util/elf2efi64 ./util/efirom ./util/efifatbin ./util/iccfix ./util/einfo TAGS bin-x86_64-efi/symtab
  [PARSEROM]
/bin/sh: perl: not found
make: *** Deleting file 'bin-x86_64-efi/.rom.defs'
  [DEPS] arch/x86/transitions/librm.S
  [DEPS] arch/x86/transitions/libpm.S
  [DEPS] arch/x86/transitions/libkir.S
  [DEPS] arch/x86/transitions/liba20.S
  [DEPS] arch/x86/prefix/usbdisk.S
  [DEPS] arch/x86/prefix/unlzma16.S
...
  [BUILD] bin-x86_64-efi/cdc.o
  [BUILD] bin-x86_64-efi/eisa.o
  [BUILD] bin-x86_64-efi/isa.o
drivers/bus/isa.c: In function 'isabus_probe':
drivers/bus/isa.c:52:4: error: array subscript [-2147483648, -1] is outside array bounds of 'isa_probe_addr_t[0]' {aka 'short unsigned int[0]'} [-Werror=array-bounds]
   52 |    *( isa_extra_probe_addrs + (ioidx) + ISA_EXTRA_PROBE_ADDR_COUNT ) )
      |    ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
drivers/bus/isa.c:113:18: note: in expansion of macro 'ISA_IOADDR'
  113 |    isa->ioaddr = ISA_IOADDR ( driver, ioidx );
      |                  ^~~~~~~~~~
drivers/bus/isa.c:34:25: note: while referencing 'isa_extra_probe_addrs'
   34 | static isa_probe_addr_t isa_extra_probe_addrs[] = {
      |                         ^~~~~~~~~~~~~~~~~~~~~
cc1: all warnings being treated as errors
make: *** [Makefile.housekeeping:943: bin-x86_64-efi/isa.o] Error 1
make: Leaving directory '/ipxe/src'

Description

As a user, I would like the option of accessing the URI the current iPXE was loaded from (cwuri) from an iPXE script.

Acceptance criteria

• Have a IPXE script variable to access the cwuri when booting iPXE over EFI HTTP boot
• Split the URI into it's components (protocol, hostname, port, path, query) which can be accessed individually

Cross-posting from iPXE forum for added visibility

Issue

Using the setup below, I'm trying to chainload iPXE from U-Boot on a small ARM32 board (ODroid MC1). iPXE is able to see the SNP interface with ifstat, but running ifopen net0 shows NETDEV net0 failed to receive 0x0: The socket is not connected and the iPXE shell freezes. Full log is shown here and iPXE config page is here and here.

Any tips for debugging this further? Thanks y'all!

Setup

Board: ODroid MC1
CPU: ARM32 Samsung Exynos5422
iPXE build: bin-arm32-efi/snp.efi with lots of DEBUG enabled, script
iPXE source: latest master but had to disable a couple optional features to avoid freezes, diff
U-Boot build: script

Hello,
I am trying to install the IPXE latest because we run in to issues with the version supplied with YUM install on centos 7.

When i try to follow the installation steps on this github i run in to the first error, that GCC command is not found. I installed GCC using yum install GCC. after this i tried in the folder src the command make.
but that resulted in the following error see below.

Error:
In file included from include/ipxe/fault.h:13:0,
from core/fault.c:28:
./config/fault.h:32:32: fatal error: config/local/fault.h: No such file or directory

Can somebody help me by telling me what i do wrong, the reason we want to update and try is with version 20.18 (installed via YUM on centos 7) we run in to the issue a lot of nodes keep getting completly stuck and is fixed by rebooting the de device (sometimes multiple reboots are necessary) we hope that this is fixed in the new version, we need this for a automatic installation of OpenShift cluster.

Thanks in advance!
Tim

Hi,
Emulex NIC in HPE Gen9 is not working with latest ipxe.efi or snp.efi.

Same issue was reported in this thread:
https://lists.ipxe.org/pipermail/ipxe-devel/2019-October/006786.html

I did git bisect as suggested in the above thread.
found that it started not to work with emulex driver since commit 6324227.

I built snp.efi with parent commit of 6324227 ( fdcdc52)
and it works for emulex dirver and also works for Mellanox MT27710 driver in HPE Gen9 or DELL PowerEdge R640.

I tried iPXE for my own custom PCI Express card on a Dell PowerEdge R7515 server.
I found an interesting problem - the iPXE driver will only find the card in the first PCIe slot.
I examined this issue in more detail and discovered the following:

1. The server uses 4 PCI Roots and these roots share same PCI segment (0)

2. First slot belongs PCI Root with index 0

3. Other slots had a different PCI Root

4. The device binding fails in the efipci_read function (see the efi_pci.c file) because root-> Pci.Read returns an INVALID PARAMETER error.

5. The efipci_root_open function pairs the PCI Root with the PCI segment number and thus always finds the first PCI Root

I think this pairing method is bad. The UEFI specification in chapter PCI Root Bridge I/O Overview says:

A PCI Host Bridge and PCI Root Bridge are different than a PCI Segment. A PCI Segment is a
collection of up to 256 PCI busses that share the same PCI Configuration Space. Depending on
the chipset, a single EFI_PCI_ROOT_BRIDGE_IO_PROTOCOL may abstract a portion of a PCI
Segment, or an entire PCI Segment. A PCI Host Bridge may produce one or more PCI Root
Bridges. When a PCI Host Bridge produces multiple PCI Root Bridges, it is possible to have
more than one PCI Segment.

I have no idea how reliably fix this issue.

Description

As a user, I would like the option of using a .iso image when booting an EFI system, for equivalence with BIOS boots.

Acceptance criteria

• Ability to build bin-x86_64-efi/ipxe.iso (or other .iso images)
• Ability to boot using qemu -cdrom bin-x86_64-efi/ipxe.iso with OVMF firmware

The source code comment quoted below suggests that iPXE will only respond to an LACP partner's PDUs as they arrive.

However, this does not seem to be the case. If the switch sends an LACP PDU to iPXE while its NIC is initialised, the iPXE starts spewing out a never-ending flood of LACP PDUs. This in turn may overload the control plane on the switch.

I can easily reproduce this using the following lab setup:

• Switch model: Edge-Core AS5812-54X running Cumulus Linux v4.2.1 NOS
• LACP bypass enabled on the switch ports, which allows switch ports to pass traffic even in the absence of incoming LACP PDUs
• Dnsmasq running directly on the switch to provide PXE boot service: dnsmasq -d -i vlan1409 --enable-tftp --tftp-root /srv/tftp --dhcp-range=10.21.9.10,10.21.9.20 --dhcp-boot=ipxe.efi
• iPXE 1.20.1+ (gc70b) binary downloaded today from http://boot.ipxe.org/ipxe.efi (md5sum: 4f0268b10c1e54e7d2b7b74f02ceb35b)
• Server model: HP ProLiant DL380 Gen9, BIOS Version: P89 v2.30 (09/13/2016), UEFI boot mode
• NIC model: HPE Ethernet 10G 2-port 546FLR-SFP+, which appears to be a rebranded Mellanox Technologies MT27520 Family [ConnectX-3 Pro]

When turning on the server, it starts EFI PXE boot, which works fine, chainloading into iPXE. I then use CTRL+B to enter the iPXE shell, and issue dhcp net4 to configure the NIC (net4 is the same NIC/port the EFI PXE boot uses). This goes fine as well, and the serial console output is shown below:

>> Booting Embedded FlexibleLOM 1 Port 1 : HPE Ethernet 10G 2-port 546FLR-SFP+ Adapter - NIC (PXE IPv4) 

>> Booting PXE over IPv4.
  Station IP address is 10.21.9.20

  Server IP address is 10.21.9.3
  NBP filename is ipxe.efi
  NBP filesize is 970752 Bytes
 Downloading NBP file...

  NBP file downloaded successfully.
iPXE initialising devices...ok



iPXE 1.20.1+ (gc70b) -- Open Source Network Boot Firmware -- http://ipxe.org
Features: DNS HTTP iSCSI TFTP SRP AoE EFI Menu

iPXE> dhcp net4                          
Configuring (net4 e0:07:1b:7f:52:10)...... ok
iPXE>

At this point I can leave it like this and observe the network traffic using tcpdump on the switch port. It is then clear that the moment the switch sends a single LACP PDU to the server, iPXE goes crazy and starts spamming the switch with an endless flood of LACP PDUs in return. There is no indication that anything is amiss on the console, it just sits there waiting for further commands (which it will happily accept, e.g., issuing ifclose net4 will instantly stop the flood).

ipxe-lacp-flood.pcap.gz is a PCAP file which contains an example of such a flood. It was captured with tcpdump -vni swp24 -s0 -c 1000 -w ipxe-lacp-flood.pcap, started seconds before issuing the dhcp net4 command in the iPXE shell. Frame 16 is the initial LACP PDU sent by the switch; iPXE's flood starts at frame 17.

One thing worth noting here is that each successive LACP frame in the flood appears to increase in size by 14 bytes for some weird reason (until the link MTU is reached), cf. column 7 below:

[:~] $ tshark -Y 'slow.subtype == 0x01' -r ipxe-lacp-flood.pcap.gz | head
   16  10.680019 Edgecore_6a:3b:94 → Slow-Protocols LACP 124 v1 ACTOR 44:38:39:ff:30:bf P: 1 K: 15 *F**SGSA PARTNER 00:00:00:00:00:00 P: 1 K: 1 *******A
   17  10.680682 HewlettP_7f:52:10 → Slow-Protocols LACP 138 v1 ACTOR e0:07:1b:7f:52:10 P: 1 K: 1 **DCSGS* PARTNER 44:38:39:ff:30:bf P: 1 K: 15 *F**SGSA
   18  10.683697 HewlettP_7f:52:10 → Slow-Protocols LACP 152 v1 ACTOR e0:07:1b:7f:52:10 P: 1 K: 1 **DCSGS* PARTNER e0:07:1b:7f:52:10 P: 1 K: 1 **DCSGS*
   19  10.686696 HewlettP_7f:52:10 → Slow-Protocols LACP 166 v1 ACTOR e0:07:1b:7f:52:10 P: 1 K: 1 **DCSGS* PARTNER e0:07:1b:7f:52:10 P: 1 K: 1 **DCSGS*
   20  10.689726 HewlettP_7f:52:10 → Slow-Protocols LACP 180 v1 ACTOR e0:07:1b:7f:52:10 P: 1 K: 1 **DCSGS* PARTNER e0:07:1b:7f:52:10 P: 1 K: 1 **DCSGS*
   21  10.692671 HewlettP_7f:52:10 → Slow-Protocols LACP 194 v1 ACTOR e0:07:1b:7f:52:10 P: 1 K: 1 **DCSGS* PARTNER e0:07:1b:7f:52:10 P: 1 K: 1 **DCSGS*
   22  10.695682 HewlettP_7f:52:10 → Slow-Protocols LACP 208 v1 ACTOR e0:07:1b:7f:52:10 P: 1 K: 1 **DCSGS* PARTNER e0:07:1b:7f:52:10 P: 1 K: 1 **DCSGS*
   23  10.698753 HewlettP_7f:52:10 → Slow-Protocols LACP 222 v1 ACTOR e0:07:1b:7f:52:10 P: 1 K: 1 **DCSGS* PARTNER e0:07:1b:7f:52:10 P: 1 K: 1 **DCSGS*
   24  10.701667 HewlettP_7f:52:10 → Slow-Protocols LACP 236 v1 ACTOR e0:07:1b:7f:52:10 P: 1 K: 1 **DCSGS* PARTNER e0:07:1b:7f:52:10 P: 1 K: 1 **DCSGS*
   25  10.704667 HewlettP_7f:52:10 → Slow-Protocols LACP 250 v1 ACTOR e0:07:1b:7f:52:10 P: 1 K: 1 **DCSGS* PARTNER e0:07:1b:7f:52:10 P: 1 K: 1 **DCSGS*

I can also reproduce this problem with much older iPXE versions, e.g. 1.0.0+ (e5b4).

Hey there,

I am willing to enable imgverify to check signatures for vmlinuz, initrd.img and filesystem.squashfs and I am facing issues with squashfs on Debian.

On the current setup (with no signing verification) the fetch parameter is passed to vmlinuz with the filesystem.squash url and everything works fine. The issue appears when I stop using fetch and start using imgfetch in order to check the signature first.

Old setup:

set install_params boot=live live-netdev=eth0 ethdevice=eth0 ethdevice-timeout=120 dhcp ...

imgfree
echo Boot parameters: ${install_params}
kernel ${mirror_address}${mirrordir}vmlinuz fetch=${mirror_address}${mirrordir}filesystem.squashfs ${install_params}
initrd ${mirror_address}${mirrordir}initrd.img
boot

New setup (which fails):

set install_params boot=live live-netdev=eth0 ethdevice=eth0 ethdevice-timeout=120 dhcp ...

imgfree
echo Boot parameters: ${install_params}
kernel ${mirror_address}${mirrordir}vmlinuz root=/dev/ram0 ${install_params}
imgfetch ${mirror_address}${mirrordir}initrd.img
imgfetch ${mirror_address}${mirrordir}filesystem.squashfs filesystem.squashfs
imgverify vmlinuz ${mirror_address}${mirrordir}vmlinuz.sig
imgverify initrd.img ${mirror_address}${mirrordir}initrd.img.sig
imgverify filesystem.squashfs ${mirror_address}${mirrordir}filesystem.squashfs.sig
imgstat
sleep 5
boot

When the systems boots up it drops to busybox because the squashfs couldn't be found. I tried to add the path but when I do it the file filesystem.squashfs doesnt appear withing the filesystem anymore.

imgfetch ${mirror_address}${mirrordir}filesystem.squashfs /live/filesystem.squashfs

Any suggestion? Has anyone a similar setup?
I suspect that if I was able to add filesystem.squashfs into /live directory it would work.

Some of our customers reported an intermittent iPXE problem where iPXE fails to download a large image from the iPXE server with our 10G adapter using chain load (legacy UNDI driver). After some analysis, I found that iPXE stack sent out an ARP request during TCP data transfer. it then sent out TCP ACK packet after it received an ARP responses. During this period, iPXE stack was dropping the incoming TCP packets. iPXE stack shouldn't send out any ARP requests for the active connection. ARP requests should be sent out after a long time of inactivities of a particular node where ARP entry is removed from the ARP table cache. Based on the network trace, the last good packet that iPXE stack received from the iPXE server is just 200uS earlier.

They are using iPXE binary that was built in 2016. Is this a known problem which has been fixed?

Thanks!
Kevin

Hello Everyone,

I am trying to flash a UEFI rom image to my intel NIC 8086:10D3, but got error invalid image format.

I compile the rom image with command make bin-x86_64-efi/808610d3.efirom without problem.

when I flash it using command "bootutil -nic 1 -restoreimage -file 808610d3.efirom" I got invalid image format error. I try to restore image using the saved image from NIC without problem. and I can flash a new image from intel booting.flb.

THX

When using iPXE builds with ECM--NCM before, iPXE was successfully pairing when connected to a phone via USB cable when the phone was set in USB tether mode. With the latest builds the phones are not detected as network interfaces anymore. With DEBUG=usb enabled the device is found, but does not seem to show itself as a network device.

Tried devices;

iPhone5
iPhone7
Google Pixel 2
Google Pixel 4

Description

As a sysadmin, I would like the cross-signed certificate files (see https://ipxe.org/cfg/crosscert) to be hosted on a highly available service, so that I do not have to worry about outages of the single machine currently hosting ca.ipxe.org.

The cross-signed certificate files are just static files (with filenames constructed from a hash of the certificate subject name) and can be served from any infrastructure capable of serving static files via HTTP. The request from iPXE includes a query string encoding the raw subject name but this is only for debugging purposes and can be safely ignored.

Acceptance criteria

• Cross-signed certificate files are hosted on a highly available service (such as AWS S3 in multiple regions)
• Cross-signing process is updated to upload files automatically to the HA hosting service
• Cross-signed certificate files can be downloaded using the existing http://ca.ipxe.org/auto base URI
• iPXE is able to perform an HTTPS boot using a cross-signed certificate downloaded from the HA hosting service, with no changes to iPXE code or configuration required.

Hi:
just use the latest v1.20.1.tar.gz for testing.
legacy boot with undionly.kpxe and scriptlet works fine.
uefi boot with snponly.efi and scriptlet is not working. but when I type "config" to check configuration, I can see the correct scriptlet parameters is received from dhcp server, it just didn't get executed.
could it be fixed so scriptlet can work both for legacy bios and uefi?

Description

As a user, I want to be able to access SMBIOS information on a platform that provides only 64-bit versions of the SMBIOS tables (e.g. OVFM in a 64-bit ARM virtual machine), so that I can rely on the DHCP system UUID and ${smbios/...} variables functioning as expected.

Acceptance Criteria

• Ability to start an OVMF virtual machine via qemu-system-aarch64 -uuid ..., to drop to the iPXE shell, and to use the command show uuid to display the expected UUID

Howdy,

I've got an iPXE script that attempts to hit a Heroku webapp, which redirects me to a URL that has the actual content I need. Unfortunately, this it seems like we're unable to trust Heroku's star cert. https://ipxe.org/crypto indicates that anything that "In the default configuration, iPXE will therefore automatically trust the same set of certificates as the Firefox web browser." Firefox likes these, but iPXE doesn't.

Any idea what could be at play or where I could start digging?

My build is pretty simple: #define DOWNLOAD_PROTO_HTTPS in src/config/general.h, make bin/ipxe.usb.

Attempting to hit anything.herokuapp.com:

iPXE> kernel https://foo.herokuapp.com
https://foo.herokuapp.com...
X509 chain 0xeec04 added X509 0xf4234 "*.herokuapp.com"
X509 chain 0xeec04 added X509 0xf4ed4 "DigiCert SHA2 High Assurance Server CA"
X509 chain 0xeec04 added X509 0xf5444 "DigiCert High Assurance EV Root CA"
X509 chain 0xeec04 found no usable certificates
Permission denied (http://ipxe.org/0216eb3c)

Issue seems to be trusting DigiCert:

iPXE> kernel https://digicert.com
https://digicert.com...
X509 chain 0xeec04 added X509 0xfdaf4 "digicert.com"
X509 chain 0xeec04 added X509 0xf7614 "DigiCert SHA2 Extended Validation Server CA"
X509 chain 0xeec04 added X509 0xf5444 "DigiCert High Assurance EV Root CA"
X509 chain 0xeec04 found no usable certificates
Permission denied (http://ipxe.org/0216eb3c)

At least one other CA works:

iPXE> kernel https://ipxe.org
https://ipxe.org...X509 chain 0xeeab4 added X509 0xf7ff4 "ipxe.org"
X509 chain 0xeeab4 added X509 0xfd024 "Let's Encrypt Authority X3"
<...>
X509 0xf7ff4 "ipxe.org" requires an OCSP check
X509 0xf7ff4 "ipxe.org" successfully validated using issuer 0xfd024 "Let's Encrypt Authority X3"
ok

Firefox seems to like Heroku

So either my Firefox setup is wonky or ipxe.org/crypto is incorrect.

Hey!

Currently, to load iPXE payload, we can provide an URL as a BOOTP filename. When chainloading, this requires the DHCP server to be able to give a different value depending on the user class. Not all DHCP servers are able to do that. I would propose to implement an additional option that would be preferred to BOOTP filename for the same purpose. If this option is present, then its value is used and BOOTP filename is ignored.

Is there any opposition for this approach?

Thanks.

I have a Synology iSCSI target on the same subnet as a machine with Intel i210 NIC, which I build iPXE uEFI firmware for iSCSI booting a Windows Server 2016. Both iPXE and Windows configures to use DHCP on the NIC.

The problem I have is that, once Windows boots, it's ARP cache entry of the iSCSI target is stuck as "invalid", and all iSCSI traffic from Windows to iSCSI target is sent to the gateway, which dutifully forwards the traffic to the destination. But the performance suffers, cannot reach line-speed because of the extra "routing" hop.

Interestingly, the incoming iSCSI traffic from the iSCSI target to Windows are correctly sent directly from the Synology to the Windows machine, creating a strange traffic "triangle".

Packet sniffer shows that, when iPXE starts, it does send ARP request of the iSCSI target; But once Windows boot takes over, it never send out any ARP request of the iSCSI target. Moreover, once boot completes, I try to:

• Manually remove the "invalid" ARP entry, which doesn't do anything at all;
• Trace route inside Windows always show 2 hops, the first being the router;
• Adding permanent ARP entry of the iSCSI target (via powershell) did make the arp tool render the iSCSI target having corrected MAC address, but it does not change the route.

It almost feels like Windows somehow has, at a very low level, stuck the iSCSI target address as not reachable on the link layer, and force all packets addressed to the iSCSI target to be routed.

Then, I made a (self-proclaimed) "brilliant" hack which seemingly resolved the problem: "if you (Windows) insist on routing the traffic, what happens if there is no gateway to use?"
I commented out this line basically prevent iBFT from passing Windows the gateway. Then magic happened -- during Windows boot, an ARP request of the iSCSI target showed up on the wire, and Windows suddenly realized iSCSI target is link-layer reachable!

Could this be a Windows specific glitch? Or is there a specification for iSCSI boot says if iSCSI target is L2 reachable, then do not pass gateway in iBFT?

First of, I am really happy to see that iPXE is still going on!

Would it be possible to provide full featured builds at http://boot.ipxe.org/ instead of the default builds? Or in addition to the default builds?

I see two benefits for that:

1. easy place for users to download an iPXE version that can do (almost) everything that is there, helping to show case iPXE abilities and reducing the effort for users who don't need further customization
2. demonstrate which features can be combined in a build without troubles

I got to this point when setting up a universal network boot server for myself. I tried to find precompiled iPXE binaries that would be fairly recent and support HTTPS booting and framebuffer console. No luck.

I know that I can build my own but that is an extra step while I would like to provide easy to follow instructions for setting up such a universal boot server.

Since you in any case have an automated setup for building iPXE and uploading it to http://boot.ipxe.org/, I am asking you to add there also a "big" version of iPXE.

I've seen some cases where loading initrd.img over TFTP is extremely slow when using iPXE. I've managed to reproduce one of them in my office:

• BIOS PXE => undionly.kpxe: 8 seconds
• BIOS PXE => ipxe.pxe: 120 seconds
• BIOS => grub => ipxe.lkrn: 120 seconds

The seconds there mean "time to load the 80 MB initrd.img" and do not include anything else like the DHCP request or the kernel loading time.

The related components were:

• iPXE version: all were the latest binaries from boot.ipxe.org (gfe6993)
• Server NIC: Gigabit Realtek 10ec:8168
• Client NIC: Gigabit Realtek 10ec:8168
• Switch: Gigabit D-Link DGS-1008D
• Client info: Sony Vaio netbook, BIOS 11/14/2012, Intel UNDI, PXE-1.2 (build 083)
• Initrd size (/srv/tftp/ltsp/x86_64/initrd.img): 81528088 bytes
• TFTP server: dnsmasq 2.80-1.1ubuntu1

How can I help in troubleshooting this? I can provide TCP dumps or even give remote access, although it should be easily reproducible as rtl8168 isn't rare.

When I boot iPXE.efi, the Mac initially shows that it is configuring the network adapters, then asking me to hit Control B. I strike the keys, but then it boots to MacOS 10.14. Any idea why?

platform:qemu and deskmini H110/COM
cpu i7-7700
ram up to 32 gig

i build a ipxe
but i always failed with a large initramfs to unpack to boot entire linux distro system in ram.

Problem: I am unable to boot all the way into winpe successfully (as of c70b3e0). The same setup using the previous commit works.

Setup:

• PXE client is ESXi v11 VM; 64-bit, UEFI, non-secure boot enabled
• chainloading ipxe.efi (using self-built make bin-x86_64-efi-sb/ipxe.efi)
• using wimboot to provide a winpe WIM image

Problem:
The iPXE firmware chainloads and successfully downloads the winpe wim. But it only briefly shows the Windows logo screen ... and never shows the swirling dots below it). After a few seconds, the machine shuts down.

The exact same setup using the previous commit (fbb5989) works as expected (i.e., I see the swirling dots for a moment ... and then boot all the way into winpe).

Also note that the problem is only exhibiting for me in the above scenario. 32 and 64-bit BIOS boots work, and 32-bit UEFI works as well. The only scenario that seems to break with this commit is 64-bit UEFI.

Please let me know if there is anything else I can do to provide insight into the problem.

Description

As a user, I want UEFI chainloading to work similarly to BIOS chainloading, to minimise my surprise. In particular, I would like options from the original vendor PXE DHCP request to be available within UEFI iPXE as they are in BIOS iPXE.

Acceptance criteria

• Ability to chainload snponly.efi, to break immediately into the iPXE shell via Ctrl-B, and to see via route that iPXE already has an IPv4 address configuration
• Ability to chainload snponly.efi, to break immediately into the iPXE shell via Ctrl-B, and to see show filename show the path to snponly.efi itself.

Sorry if there's a better place to request this. I did a quick look and couldn't find any obvious place, and couldn't find a way to update this myself.

Anyway, ipxe.org/crypto links to Mozilla list of public CA certificates. That page was hanging for me (but this seems intermittent; I didn't have issues yesterday), but surprisingly, the https version loads very quickly. Additionally, that page redirects to hg.mozilla.com, so it may be worth it to just point at that.

IDK if you're able to introduce this behavior, but if so, it may be worth making that change.

Description

As a user, I want to be able to use the file:/ URI syntax to refer to local files on a USB key from which iPXE was loaded even if iPXE includes native USB host controller drivers, since I expect this to work regardless of which drivers are included in the build.

Using the file:/ URI syntax to refer to local files on a USB key from which iPXE was loaded will currently fail if the iPXE binary includes native USB host controller drivers, since iPXE's loaded image device handle will cease to be valid when iPXE disconnects the platform host controller drivers.

There is no way to prevent the loaded image's device handle from becoming invalid, so an alternative matching strategy will be required. Recording the device path at startup and matching on device path may be a viable approach.

It may also be worth identifying other uses of efi_loaded_image->DeviceHandle to see if similar workarounds are required there.

Acceptance criteria

• Ability to boot bin-x86_64-efi/ecm.usb (or other iPXE binary with native USB host controller drivers) from a USB key and to subsequently execute a script held on the USB key using the file:/ URI syntax (with absolute path and no volume label, e.g. chain file:/script.ipxe)
• Other uses of efi_loaded_image->DeviceHandle have been identified and triaged

Description

As a user, I want UEFI chainloading to work similarly to BIOS chainloading, to minimise my surprise. In particular, I would like options from the original vendor PXE DHCP request to be available within UEFI iPXE as they are in BIOS iPXE.

Acceptance criteria

• Ability to chainload snponly.efi, to break immediately into the iPXE shell via Ctrl-B, and to see via route that iPXE already has an IPv4 address configuration
• Ability to chainload snponly.efi, to break immediately into the iPXE shell via Ctrl-B, and to see show filename show the path to snponly.efi itself.

Hi,

Today I tried cloning the repo and building the VMXNET3 driver from source.

The VM building is Ubuntu 18.04 Server.

I run make bin/15ad07bo.rom and this creates the rom file. However, when attempting to use it in a VM, I get this in the VMware log:
BIOS 15ad07b0.rom has unexpected file size 0x10600

Whenever I download and use a rom file that someone else made years ago, then it does work, so this is really weird.
Am I doing something wrong?

Also, a question: is there a way to build this for UEFI?

This issue occurred with an iPXE build using commit 2091288 because I thought it was the newest version that was working properly for me (refer to issue #162).

But, we've just run into a new issues using that build when loading Linux Mint 20. The iPXE menu loads properly and everything, this failure is after the boot command is run.

Roughly, initrd is called first with the proper initrd.lz file and then boot is called with the proper vmlinuz file and kernel arguments which are all known working. Both command seem to run properly, but then we hit a black screen with the just the following messages:

exit_boot() failed!
efi_main() failed!

After running into this issue, I just rolled all the way back to commit fe69934 from 2020-09-22 (which was just the last known good version that we used in production) and then booting into Linux Mint 20 from this exact OptiPlex 9020 works fine again.

Hi,
We want to move from lpxelinux to ipxe.

Our hosts have dualboot and PXE is default boot option on our hosts.
Currently, with lpxelinux, we use chain.c32 which let us "lock" boot on windows during the deploy process of Windows, which requires some reboot.

To boot local windows from lpxelinux in Legacy mode, we use that boot file.

DEFAULT Windows
PROMPT 0

LABEL Windows
    MENU LABEL Windosw
    COM32 chain.c32
    APPEND hd0 1

To boot local linux from lpxelinux in Legacy mode, we use that boot file.

DEFAULT Linux 
PROMPT 0

LABEL Linux 
    MENU LABEL Linux
    COM32 chain.c32
    APPEND hd0

With ipxe, in UEFI mode, we can directly specify EFI boot file with file:
But to do this in Legacy mode, it would be great to be able to specify on which partition to boot in legacy mode with sanboot with for exemple a --partition option.
Thanks

Dear sir
We met the issue of supporting ipxe on CML platform with ipxe rom embedded in BIOS. The LAN chip used was Intel i219v with Vendor ID Device ID 80860d4d. The platform is H470.
When first power on, system could boot to ipxe server. But if we restart the system from Ubuntu 20.04, or shutdown the system from Ubuntu 20.04 and then power on the system, system could no longer be able to boot into ipxe server unless we remove the power supply and connect the power again.

Restart failure information:
iPXE 1.20.1+ (gb6e2e)[0m -- Open Source Network Boot Firmware -- http://ipxe.org
Features: DNS HTTP iSCSI TFTP AoE ELF MBOOT NBI PXE bzImage Menu PXEXT
net0: f8:75:a4:21:94:be using i219v-10 on 0000:00:1f.6 (open)
[Link:down, TX:0 TXE:0 RX:0 RXE:0]
[Link Status: Down (http://ipxe.org/38086101)]
Waiting for link-up on net0................. Down (http://ipxe.org/38086101)
net0: f8:75:a4:21:94:be using i219v-10 on 0000:00:1f.6 (open)
[Link:down, TX:0 TXE:0 RX:0 RXE:0]
[Link Status: Down (http://ipxe.org/38086101)]
[TXE: 1 x "Operation not supported (http://ipxe.org/3c654003)"]
...

Shutdown from ubuntun and then power on the system failure information:
iPXE 1.20.1+ (gb6e2e)[0m -- Open Source Network Boot Firmware -- http://ipxe.org
Features: DNS HTTP iSCSI TFTP AoE ELF MBOOT NBI PXE bzImage Menu PXEXT
net0: f8:75:a4:21:94:be using i219v-10 on 0000:00:1f.6 (open)
[Link:up, TX:0 TXE:0 RX:0 RXE:0]
Configuring (net0 f8:75:a4:21:94:be)....... No configuration methods succeeded (http://ipxe.org/040ee119)
net0: f8:75:a4:21:94:be using i219v-10 on 0000:00:1f.6 (open)
[Link:up, TX:0 TXE:0 RX:0 RXE:0]
[TXE: 1 x Operation not supported (http://ipxe.org/3c654003)]
...

How to recover it when the problem happens
Platform reset or global reset or power off and then power on cannot recover it. It can only be recovered by removing the power adaptor and plug it again.

PS: There is no problem on Corporation SKU Q470.(The LAN chip used was Intel i219v with Vendor ID Device ID 80860d4d. )

Can you kindly give some comments on this issue? Thanks.

We have a quite big infrastructure and now we started to use AMD based servers instead of the intel ones with 1 nvme only for os.

We are using ipxe to kickstart the servers but for some reason with this new amd nvme setup the ipxe fails during the kickstart

Here are the issue that I'm seeing:

https://i.ibb.co/VQksZTF/1.png

https://i.ibb.co/7Gh80BT/2020-09-15-16-34-23-Greenshot.png

Here is the pxelinux and the tftpboot config as well: https://jpst.it/2hIpU

If I type manually the # for grub 2.02

It will kickstart the system, but it should be automated :) somehow it doesn't go to that step.

When I try to compile an iPXE rom to burn onto my i219-V ethernet adapter, I run the following:

cd src
make bin/80860d4f

and I get the following error:

[VERSION] bin/version.80860d4f.rom.o
  [LD] bin/80860d4f.rom.tmp
--defsym:2: undefined symbol `obj_80860d4f' referenced in expression
Makefile.housekeeping:1188: recipe for target 'bin/80860d4f.rom.tmp' failed
make: *** [bin/80860d4f.rom.tmp] Error 1
rm bin/version.80860d4f.rom.o

is there something different I should be doing when compiling this? Thanks!

Suppose that I boot from the PXE stack, which loads a custom build of undionly.kpxe with the following embedded ipxe script:

ifopen net0
chain ${proxydhcp/dhcp-server}/ltsp/ltsp.ipxe

The problem is that at that point, the proxydhcp variables aren't there; they're only available if a dhcp net0 gets executed.

When using proxydhcp, there's little benefit in doing an additional DHCP request, as we have no control over the main DHCP server anyway, and our only variables that we'll need are ${proxydhcp/dhcp-server} and ${proxydhcp/filename}.

Would it be possible to get the ProxyDHCP packet and make it available at that point, to avoid the extra DHCP request?
Thank you again for the wonderful iPXE!

Hello there!
I have an issue executing my boot.ipxe file. Script file permissions are 755. File content is simple 'hello world':

#!ipxe
:loop
echo hello world
goto loop

Script file is stored on USB stick drive within /boot/grub/ipxe directory.
I don't know why this doesn't execute. Please help!

I build the latest iPXE periodically to keep up with changes.

The last build from last month (2020-09-23) works perfectly fine in UEFI and BIOS mode. But when I built the latest iPXE on 2020-10-20, I'm having issues with my exact same menu files in UEFI while BIOS continues to work fine.

I just built the latest iPXE again today to see if anything has changed and I'm getting the same behavior.

I have script which downloads the latest iPXE source and then does a few minor modifications to include the build date as the version and enable the settings we use, which are:

UNCOMMENT IN config/general.h: #define POWEROFF_CMD, #define PARAM_CMD, #define PING_CMD, #define CONSOLE_CMD
UNCOMMENT IN config/console.h: #define CONSOLE_FRAMEBUFFER
ADD IN config/defaults/pcbios.h: #define MEMMAP_SETTINGS

My embedded menu file successfully runs dhcp, ping, and then tries to boot my actual menu file from the server which was successfully detected with the previous commands.

I can see the the menu file get loaded with the "ok" message but then the computer just hangs on a black screen or reboots.

This main menu file has a lot of options, but everything is done as safe as I could, all the initial custom color and image loading lines end with "||" so they should just continue to show the menu if anything fails.

Up until the point that the first menu is displayed, all that is done is setting variables for later use, a few of which are conditional for the platform but nothing too fancy. As far as I know I have things set up in such a way that a menu error should never cause a shutdown or reboot, worst case would be an unstyled menu or an error getting displayed.

Is there anything in the commits since 2020-09-23 that might explain this behavior? Or is there more specific information you need about my setup/menus?

Thanks so much for any help and/or advice with this issue.

Description

As a sysadmin, I would like the iPXE OCSP service to be hosted on some kind of highly available infrastructure, so that I do not have to worry about outages of the single machine currently hosting ocsp.ipxe.org.

Unlike the cross-signed certificate files (see #126), OCSP does not just serve static files. Some investigation is required to determine a sensible way to host this service.

Acceptance criteria

• OCSP service is hosted on a highly available service (such as AWS in multiple regions)
• Cross-signing process is updated to provide OCSP signing certificates to the HA hosting service
• HA OCSP service can be accessed using the existing http://ocsp.ipxe.org base URI
• iPXE is able to perform an HTTPS boot using a cross-signed certificate verified using the HA OCSP service, with no changes to iPXE code or configuration required.

Is there any trick to getting initrd to load for AArch64?

Kernel loads fine. But I have a 100% failure rate for loading various Linux flavors of initrd and initramfs build for AArch64. iPXE was built as such:

# Fix the problem when PXE is single-threaded, but iPXE uses interrupts,
#  and prevent redefining cpu_nap() by avoiding efiarm_nap.h from loading.
    echo "#undef  NAP_PCBIOS"   >> config/local/nap.h &&\
    echo "#define NAP_NULL"     >> config/local/nap.h &&\
    echo ""                      > arch/arm/include/bits/nap.h
 
# Add more menu items
    echo "#define DOWNLOAD_PROTO_NFS"   >> config/local/general.h &&\
    echo "#define DOWNLOAD_PROTO_HTTPS" >> config/local/general.h &&\
    echo "#define PING_CMD"             >> config/local/general.h &&\
    echo "#define IPSTAT_CMD"           >> config/local/general.h &&\
    echo "#define NSLOOKUP_CMD"         >> config/local/general.h &&\
    echo "#define TIME_CMD"             >> config/local/general.h &&\
    echo "#define REBOOT_CMD"           >> config/local/general.h &&\
    echo "#define POWEROFF_CMD"         >> config/local/general.h &&\
    echo "#define IMAGE_SCRIPT"         >> config/local/general.h &&\
    echo "#define IMAGE_EFI"            >> config/local/general.h

make ARCH=arm64 bin-arm64-efi/ipxe.efi -j8 DEBUG=image:3

Attempts to load various AArm64 initrds:

iPXE> initrd http://10.10.0.200/images/debian-installer/arm64/initrd   
http://10.10.0.200/images/debian-installer/arm64/initrd... ok 
IMAGE initrd at [571a2000,5c1eb200) registered
Invalid DOS Signature
IMAGE initrd is not EFI: Error 0x7f048181 (http://ipxe.org/7f048181)
IMAGE initrd is not script: Exec format error (http://ipxe.org/2e028081)
IMAGE initrd is not DER: Exec format error (http://ipxe.org/2e088081)
IMAGE initrd is not PEM: No such file or directory (http://ipxe.org/2d09808e)
IMAGE initrd format not recognised

iPXE> initrd http://10.10.0.200/images/alpine-aarch64/initramfs-lts
http://10.10.0.200/images/alpine-aarch64/initramfs-lts... ok
IMAGE initramfs-lts at [54cb2000,5614e74e) registered
Invalid DOS Signature
IMAGE initramfs-lts is not EFI: Error 0x7f048181 (http://ipxe.org/7f048181)
IMAGE initramfs-lts is not script: Exec format error (http://ipxe.org/2e028081)
IMAGE initramfs-lts is not DER: Error 0x3e00e08e (http://ipxe.org/3e00e08e)
IMAGE initramfs-lts is not PEM: No such file or directory (http://ipxe.org/2d09808e)
IMAGE initramfs-lts format not recognised

iPXE> initrd http://10.10.0.200/images/debian/initrd.gz              
http://10.10.0.200/images/debian/initrd.gz... ok
IMAGE initrd.gz at [56152000,5719e3be) registered
Invalid DOS Signature
IMAGE initrd.gz is not EFI: Error 0x7f048181 (http://ipxe.org/7f048181)
IMAGE initrd.gz is not script: Exec format error (http://ipxe.org/2e028081)
IMAGE initrd.gz is not DER: Error 0x3e00e08e (http://ipxe.org/3e00e08e)
IMAGE initrd.gz is not PEM: No such file or directory (http://ipxe.org/2d09808e)
IMAGE initrd.gz format not recognised

This is the same error for the x86-64 initrd files:

iPXE> imgfetch http://boot.ipxe.org/1mb
http://boot.ipxe.org/1mb........... ok            
IMAGE 1mb at [52e39000,52f39000) registered
Invalid DOS Signature
IMAGE 1mb is not EFI: Error 0x7f048181 (http://ipxe.org/7f048181)
IMAGE 1mb is not script: Exec format error (http://ipxe.org/2e028081)
IMAGE 1mb is not DER: Error 0x3e00e08e (http://ipxe.org/3e00e08e)
IMAGE 1mb is not PEM: No such file or directory (http://ipxe.org/2d09808e)
IMAGE 1mb format not recognised

For AArch64, I'm tried renaming initrd to initrd.gz, uncompressing initrd.gz to initrd, and I've tried various netboot ISOs initrds for AArch64, but nothing succeeds.

I've noticed that all the initrd code (https://github.com/ipxe/ipxe/search?q=initrd) is under the x86 arch folder. Does that matter?

iPXE 1.20.1 (g8f15) -- Open Source Network Boot Firmware -- http://ipxe.org
Features: DNS HTTP HTTPS iSCSI NFS TFTP SRP AoE EFI Menu

util/zbin.c:7:18: fatal error: lzma.h: No such file or directory

how to solve this problem?

i want to use undionly.kpxe
but i don't know the default config filename
i create a file named demo.ipxe it doesn't work

Since commit c70b3e0 iPXE is no longer able to boot my HP ProLiant DL380 Gen9 server with HPE Ethernet 10G 2-port 546FLR-SFP+ (rebranded Mellanox Technologies MT27520 Family [ConnectX-3 Pro]).

It fails like this, where it hangs until manually rebooted:

ASSERT u:\MdeModulePkg\Core\Dxe\Hand\Locate.c(492): Size >= 0
ASSERT u:\MdePkg\Library\BaseMemoryLibRepStr\CompareMemWrapper.c(62): (Length - 1) <= (0xFFFFFFFFFFFFFFFFULL - (UINTN)DestinationBuffer)
ASSERT u:\MdePkg\Library\BaseMemoryLibRepStr\CompareMemWrapper.c(63): (Length - 1) <= (0xFFFFFFFFFFFFFFFFULL - (UINTN)SourceBuffer)
ASSERT u:\MdeModulePkg\Core\Dxe\Hand\Locate.c(492): Size >= 0
ASSERT u:\MdePkg\Library\BaseMemoryLibRepStr\CompareMemWrapper.c(62): (Length - 1) <= (0xFFFFFFFFFFFFFFFFULL - (UINTN)DestinationBuffer)
ASSERT u:\MdePkg\Library\BaseMemoryLibRepStr\CompareMemWrapper.c(63): (Length - 1) <= (0xFFFFFFFFFFFFFFFFULL - (UINTN)SourceBuffer)

These messages appear after iPXE has completed the download the kernel and the initramfs image, and is about to hand over control to the Linux kernel.

Today's Git master with c70b3e0 reverted works fine. When this build boots successfully, normal output from the Linux kernel appears instead of the ASSERT lines quoted above.

When using iPXE.EFI and booting from a USB device path the following can be used to access local storage:

file:config.ipxe
file:/EFI/iPXE/config.ipxe
file://DEPLOY/EFI/iPXE/config.ipxe

This all fails in any USB related build when iPXE has initialised the USB devices. Interestingly it works in QEMU, but fails on physical hardware so it seems related to UEFI & USB interaction somehow.

There is a new certificate valid unitl 2031 that not present http://ca.ipxe.org/cross/

https://cacerts.digicert.com/DigiCertHighAssuranceEVRootCA.crt.pem

Hello, I am converting some PXELINUX over to IPXE (for UEFI). I am booting with ipxe.uefi:

this is the pxelinux config that works flawlessly (in BIOS mode)

label c8m
IPAPPEND 2
KERNEL CentOS8.2x64/vmlinuz
append initrd=CentOS8.2x64/initrd.img ksdevice=bootif ks=http://10.1.13.195/Centos8/kickstart-manual

Here is the IPXE config that I am trying to use

:centos8m
kernel CentOS8.2x64/vmlinuz initrd=initrd.img
initrd CentOS8.2x64/initrd.img ksdevice=bootif ks=http://10.1.13.195/Centos8/kickstart-manual
boot

When I try to boot it with IPXE it gives a bunch of dracut-initqueue timeout errors and then drops to an emergency shell.

Thanks in advance if anyone can assist me.

iPXE support for HTTP/HTTPs URLs is very extensible, but places additional dependencies on the networking infrastructure, requiring a host site.

In environments where the iPXE URLs can be provided through automation, and a URL is the preferred or only method of entry, users may benefit from data-uri support.

In order to keep data-uri support simple, the supported encoding types could be restricted to plain text, utf-8, and base64.

Hello,

I have a Supermicro X11SPG-TF motherboard with two Intel x550 nics. When booting iPXE in UEFI neither of the nics are seen by iPXE. I booted the system in Legacy BIOS mode and the nics are seen by iPXE. I would like to use this server in UEFI mode if possible.

The device ID is located in intelx.c source file.

Here is the command I am running to build iPXE:

make bin-x86_64-efi/ipxe.usb DEBUG=intelx,intelxvf,main,dhcpopts,dhcppkt,intelxl

I have attached a screen shot of iPXE running and a screenshot of the NIC information from the BIOS.

Any suggestions on how to debug this issue?

Ironic iPXE arm64 qemu booting always fails with “. Connection reset (http://ipxe.org/0f0a6095)” and http download is very slow

Build ipxe and cp to tftproot

$ git clone git://git.ipxe.org/ipxe.git (commit: 70b1a641)
$ cd ipxe/src; make bin-arm64-efi/ipxe.efi
$ cp ~/ipxe/src/bin-arm64-efi/ipxe.efi /opt/stack/data/ironic/tftpboot

Booting log

boot.ipxe : 758 bytes [script]
Attempting to boot from MAC 52-54-00-09-06-3e
pxelinux.cfg/52-54-00-09-06-3e................................. Connection reset (http://ipxe.org/0f0a6095)
Attempting to boot from MAC 52-54-00-df-72-db
pxelinux.cfg/52-54-00-df-72-db................................. Connection reset (http://ipxe.org/0f0a6095)
PXE boot failed! No configuration found for any of the present NICs.
Press any key to reboot...
Could not boot image: Connection timed out (http://ipxe.org/4c22e092)
No more network devices

Press any key to continue…

Running kvm qemu with virtio-net-pci NIC

libvirt+  406329  3.1  0.2 3810752 274228 ?      Sl   07:32   3:25 qemu-system-aarch64 -enable-kvm -name guest=node-0,debug-threads=on -S -object secret,id=masterKey0,format=raw,file=/var/lib/libvirt/qemu/domain-17-node-0/master-key.aes -blockdev {"driver":"file","filename":"/var/lib/libvirt/images/OVMF_CODE.fd","node-name":"libvirt-pflash0-storage","auto-read-only":true,"discard":"unmap"} -blockdev {"node-name":"libvirt-pflash0-format","read-only":true,"driver":"raw","file":"libvirt-pflash0-storage"} -blockdev {"driver":"file","filename":"/var/lib/libvirt/images/OVMF_VARS.fd-node-0","node-name":"libvirt-pflash1-storage","auto-read-only":true,"discard":"unmap"} -blockdev {"node-name":"libvirt-pflash1-format","read-only":false,"driver":"raw","file":"libvirt-pflash1-storage"} -machine virt-4.2,accel=kvm,usb=off,dump-guest-core=off,gic-version=3,pflash0=libvirt-pflash0-format,pflash1=libvirt-pflash1-format -cpu host -m 3072 -overcommit mem-lock=off -smp 1,sockets=1,cores=1,threads=1 -uuid cafb41a4-9612-4255-a14c-202612c69239 -display none -no-user-config -nodefaults -chardev socket,id=charmonitor,fd=30,server,nowait -mon chardev=charmonitor,id=monitor,mode=control -rtc base=utc -no-shutdown -boot menu=off,strict=on -device pcie-root-port,port=0x8,chassis=1,id=pci.1,bus=pcie.0,multifunction=on,addr=0x1 -device pcie-root-port,port=0x9,chassis=2,id=pci.2,bus=pcie.0,addr=0x1.0x1 -device pcie-root-port,port=0xa,chassis=3,id=pci.3,bus=pcie.0,addr=0x1.0x2 -device pcie-root-port,port=0xb,chassis=4,id=pci.4,bus=pcie.0,addr=0x1.0x3 -device pcie-root-port,port=0xc,chassis=5,id=pci.5,bus=pcie.0,addr=0x1.0x4 -device pcie-root-port,port=0xd,chassis=6,id=pci.6,bus=pcie.0,addr=0x1.0x5 -device pcie-root-port,port=0xe,chassis=7,id=pci.7,bus=pcie.0,addr=0x1.0x6 -device pcie-root-port,port=0xf,chassis=8,id=pci.8,bus=pcie.0,addr=0x1.0x7 -device pcie-root-port,port=0x10,chassis=9,id=pci.9,bus=pcie.0,multifunction=on,addr=0x2 -device pcie-root-port,port=0x11,chassis=10,id=pci.10,bus=pcie.0,addr=0x2.0x1 -blockdev {"driver":"file","filename":"/var/lib/libvirt/images/node-0.qcow2","node-name":"libvirt-1-storage","cache":{"direct":false,"no-flush":true},"auto-read-only":true,"discard":"unmap"} -blockdev {"node-name":"libvirt-1-format","read-only":false,"cache":{"direct":false,"no-flush":true},"driver":"qcow2","file":"libvirt-1-storage","backing":null} -device virtio-blk-pci,scsi=off,bus=pci.10,addr=0x0,drive=libvirt-1-format,id=virtio-disk0,write-cache=on -netdev tap,fd=32,id=hostnet0,vhost=on,vhostfd=33 -device virtio-net-pci,netdev=hostnet0,id=net0,mac=52:54:00:09:06:3e,bus=pci.1,addr=0x0,bootindex=1 -netdev tap,fd=34,id=hostnet1,vhost=on,vhostfd=35 -device virtio-net-pci,netdev=hostnet1,id=net1,mac=52:54:00:df:72:db,bus=pci.2,addr=0x0 -add-fd set=5,fd=37 -chardev pty,id=charserial0,logfile=/dev/fdset/5,logappend=on -serial chardev:charserial0 -device virtio-balloon-pci,id=balloon0,bus=pcie.0,addr=0x7 -sandbox on,obsolete=deny,elevateprivileges=deny,spawn=deny,resourcecontrol=deny -msg timestamp=on
stack     426200  0.0  0.0   5904  2020 pts/7    S+   09:22   0:00 grep --color=auto qemu

I ran into a problem with an Intel i219-lm(4) based nic.
I have a setup where I use iPXE to boot a Genode based OS. Genode uses a port of iPXE as its generic network interface driver. Sometimes the nic then fails to transmit packets. The error occurs more often if the cable is removed while booting the OS and reconnected after the nic driver turned iPXE is running.
I found an older issue with similar behaviour but there already exists a fix.

I came to the following conclusions while investigating the error:
When the OS is started and the link is up the network stack starts to send DHCP discover packets. The first transmit attempt is acknowledged with the TXDW bit set in the interrupt cause register. But I could not see any packet on the net (wireshark). So the packet was never sent or seriously corrupted. All following transmit attempts won't even be acknowledged and the TXDW bit is never set again.
The RX queue on the other hand seems to be working.

I could recover from this situation by executing the following sequence.

netdev_link_down(...);
netdev_close(...);
netdev_open(...);
netdev_irq(..., 1);

The error sometimes can also be reproduced by unplugging and then re-plugging the network cable. Therefore I think the error might be connected to the MAC being resetted without a power cycle. As far as I understood the PHY is not resetted because of other hardware related issues.

I suspect the issue to be caused by a hardware issue. The comments and workarounds in the iPXE and the linux source code regarding said hardware family may support my suspicion.

Is there anybody else who already observed and may confirm the issue? Is it feasible to add some kind of device reset (as shown above) to the intel driver?