From stappers at stappers.nl Sat Jul 5 16:04:08 2025 From: stappers at stappers.nl (Geert Stappers) Date: Sat, 5 Jul 2025 18:04:08 +0200 Subject: [ipxe-devel] PXE Boot Issues with initrd timeout (BIOS) and grubx64.efi error "E18" (UEFI) In-Reply-To: References: Message-ID: On Tue, Jul 01, 2025 at 09:08:58PM +0200, Jean-Fran?ois JUBLIN wrote: > Hi, > > I'm a French teacher and I run a dnsmasq server as PXE (Debian preseeded > installer) / DHCP / DNS server. > I'm running into PXE boot issues this year, using dnsmasq's built-in TFTP > server. > > Setup: > - Debian 12 server > - PXE configuration in dnsmasq > - TFTP root is /srv/tftp serving debian installer > - BIOS clients use pxelinux.0 > - UEFI clients use grubx64.efi or bootnetx64.efi > > Issue 1: BIOS PXE clients > - The pxelinux.0 is loaded successfully, and I get the menu from grub.cfg. > > *- However, during the initrd transfer, I get a timeout everytime, same > with clonezilla's squashfs.*- This issue was resolved by disabling the > built-in TFTP in dnsmasq and using an external TFTP server (tftpd-hpa). > With tftpd-hpa, initrd loads fully and the installation proceeds. > Last year built in TFTP server was working fine for legacy BIOS, but I must > say it was way slower than tftp-hpa. I have swapped pxelinux for iPXE ( https://ipxe.org ) The progress I made with that swap, is that iPXE can do HTTP. ( pxelinux could only do TFTP when I left it ) Thing I'm trying to tell: Prefer HTTP above TFTP for large file transfers. TFTP is "go stop go stop go stop", HTTP is a stream. > Issue 2: UEFI PXE clients > - The UEFI firmware requests grubx64.efi (I see the TFTP request in the > logs). > - The file exists and is accessible (confirmed with manual TFTP download > from another host). > *-* I can see the choice of PXE server > *, still, when I press enter the UEFI clients fail with a "PXE-E18: Server > response timeout" error before anything is shown on screen.*- I?ve tried > several UEFI `.efi` loaders (grubx64.efi, bootnetx64.efi), all give the > same result. PXE-E18: Server response timeout > - I've tried symlink and raw file for the .efi file. > - I've tried different host (old and pretty new motherboard), all give the > same result. PXE-E18: Server response timeout As I understand it, tries the UEFI client of original poster to do PXE, which matches 'Issue 2: UEFI PXE clients' :-) The FAQ of iPXE has this: What does the "i" in "iPXE" stand for? It doesn't. And that, NOT doing Pre eXecution Environment, is also my advice. That probably needs explanation. PXE is PXE. And there several PXE. So use only as least as possible of PXE, like downloading and starting of iPXE. Avoid PXE client code that insists on some special reply from a PXE server (that original poster doesn't seem to have (and should not be pushed to get such PXE server.)) > Here how I build my TFTP content : > > cd /srv/tftp > > wget > > http://ftp.debian.org/debian/dists/bookworm/main/installer-amd64/current/images/netboot/netboot.tar.gz > > tar -xzvf netboot.tar.gz > > rm netboot.tar.gz > > ln -s debian-installer/amd64/grubx64.efi . > > ln -s debian-installer/amd64/grub . > |$ apt search netboot | |WARNING: apt does not have a stable CLI interface. Use with caution in scripts. | |Bezig met sorteren... |Volledige tekst doorzoeken... |busybox-syslogd/oldstable 1:1.30.1-6 all | Provides syslogd and klogd using busybox | |debian-installer-11-netboot-amd64/oldstable 20210731+deb11u12 all | Debian-installer network boot images for amd64 | |debian-installer-11-netboot-arm64/oldstable 20210731+deb11u12 all | Debian-installer network boot images for arm64 | |debian-installer-11-netboot-armel/oldstable 20210731+deb11u12 all | Debian-installer network boot images for armel | |debian-installer-11-netboot-armhf/oldstable 20210731+deb11u12 all | Debian-installer network boot images for armhf | |debian-installer-11-netboot-i386/oldstable 20210731+deb11u12 all | Debian-installer network boot images for i386 | |debian-installer-11-netboot-mips64el/oldstable 20210731+deb11u12 all | Debian-installer network boot images for mips64el | |debian-installer-11-netboot-mipsel/oldstable 20210731+deb11u12 all | Debian-installer network boot images for mipsel | |debian-installer-11-netboot-ppc64el/oldstable 20210731+deb11u12 all | Debian-installer network boot images for ppc64el | |di-netboot-assistant/oldstable 0.70 all | Debian-Installer netboot assistant | |golang-github-insomniacslk-dhcp-dev/oldstable 0.0~git20200621.d74cd86-1 all | DHCPv6 and DHCPv4 packet library, client and server written in Go (library) | |ltsp/oldstable 21.01-1+deb11u1 all | Linux Terminal Server Project | |pxe-kexec/oldstable 0.2.4-3+b5 i386 | Fetch PXE configuration file and netboot using kexec | |rarpd/oldstable,now 0.981107-9+b1 i386 [ge?nstalleerd] | Reverse Address Resolution Protocol daemon |$ In other words: Debian has packages for what you want. 8^) > I also compressed initrd files and included firmware, but it makes no > difference ? it?s not relevant to the problem. > > cd /srv/tftp/debian-installer/amd64 > > [ -f initrd.gz.orig ] || cp -p initrd.gz initrd.gz.orig > > [ -f firmware.cpio.gz ] || wget > > https://cdimage.debian.org/cdimage/firmware/bookworm/current/firmware.cpio.gz > > cat initrd.gz.orig firmware.cpio.gz > initrd.gz > > gzip -cd initrd.gz | xz -9 --check=crc32 > initrd.xz I agree on not relevant to the problem. Problem is server and client understanding each other not well enough. > My specific dnsmasq conf : > ...... serveral lines of dnsmasq configuration deleted ...... Assume dnsmasq being OK. Switch from pxelinux to ipxe, switch from grub.efi to ipxe.efi. > I'm pretty sure last year I did not had thoses issues for EFI either. Tempora mutantur et nos mutamur in illis. > Thanks in advance for any help or insight ? I?m hoping to get the computer > ready soon for the kids. > > Have a nice day, > Best regards, Groeten Geert Stappers P.S. iPXE.org website has "open source boot firmware" in the title. Do know that it can be used without any firmware update. (No need to fear updating of firmware, use it as bootloader like pxelinux or grub.) -- Silence is hard to parse