I'm working on setting up netboot, and got it working with one motherboard, but it doesn't quite seem to work with another; and I don't see enough output to figure out why.

So, the setup on the 'PXE server' is that DHCP and TFTP reside on the same server, and DHCP is configured with:

root@vogon:/etc/dhcp# cat dhcpd.conf
option domain-name "somewhere.com";
option domain-name-servers,;
allow booting;
allow bootp;

default-lease-time 600;
max-lease-time 7200;
ddns-update-style none;

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

subnet netmask {
  option routers;
  option broadcast-address;
  #filename "debian-installer/amd64/bootnetx64.efi";
  filename "grubx64.efi";

TFTP uses /srv/tftp as root dir, and grubx64.efi will read /debian-installer/amd64/grub/grub.cfg because I'm using the bootloader from the debian 11 distro:

root@vogon:/srv/tftp# cat debian-installer/amd64/grub/grub.cfg
set menu_color_normal=cyan/blue
set menu_color_highlight=white/blue
set gfxpayload=text
set timeout=-1

menuentry 'Debian 11'{
    set background_color=black
    linux    /debian/11/amd64/linux priority=low vga=788 ---
    initrd   /debian/11/amd64/initrd.gz

menuentry "Ubuntu 20.04" {
        linux /ubuntu/20.04/amd64/linux only-ubiquity ip=dhcp ---
        initrd /ubuntu/20.04/amd64/initrd.gz

I have used this setup to successfully install both Debian 11 and Ubuntu 20.04 on a ROG Strix X570-F Gaming motherboard with an AMD Ryzen 9 5950X CPU. In /var/log/syslog I see the following from the tftp server:

Jul  8 13:33:33 vogon in.tftpd[45602]: RRQ from filename grubx64.efi
Jul  8 13:33:33 vogon in.tftpd[45602]: tftp: client does not accept options
Jul  8 13:33:33 vogon in.tftpd[45603]: RRQ from filename grubx64.efi
Jul  8 13:33:34 vogon in.tftpd[45604]: RRQ from filename /debian-installer/amd64/grub/x86_64-efi/command.lst
Jul  8 13:33:34 vogon in.tftpd[45605]: RRQ from filename /debian-installer/amd64/grub/x86_64-efi/fs.lst
Jul  8 13:33:34 vogon in.tftpd[45606]: RRQ from filename /debian-installer/amd64/grub/x86_64-efi/crypto.lst
Jul  8 13:33:34 vogon in.tftpd[45607]: RRQ from filename /debian-installer/amd64/grub/x86_64-efi/terminal.lst
Jul  8 13:33:34 vogon in.tftpd[45608]: RRQ from filename /debian-installer/amd64/grub/grub.cfg
Jul  8 13:33:37 vogon in.tftpd[45609]: RRQ from filename /ubuntu/20.04/amd64/linux
Jul  8 13:33:40 vogon in.tftpd[45610]: RRQ from filename /ubuntu/20.04/amd64/initrd.gz

However, with another motherboard, ASUS ProArt Z690-CREATOR WIFI Intel Z690 PCIe 5.0 ATX, and Intel Core i9 12900KS Special Edition 16 Core Alder Lake Unlocked CPU, I only see the following in the log:

Jul 12 10:49:00 vogon in.tftpd[58652]: RRQ from filename grubx64.efi
Jul 12 10:49:00 vogon in.tftpd[58652]: tftp: client does not accept options
Jul 12 10:49:00 vogon in.tftpd[58653]: RRQ from filename grubx64.efi

and the text 'Welcome to GRUB!' on the client screen. This text is only found in the bootloader, grubx64.efi, so it seems it actually starts running, but never goes on to looking for the other files.

Any suggestions for what I can do to troubleshoot this further?

1 Answer 1


You don't seem to have the option boot-size line anywhere in your dhcpd configuration. Some UEFI implementations require that this option is used to indicate the size of the UEFI PXE bootloader file, so the UEFI firmware will be able to allocate the right amount of memory for it in advance.

Adding the option (with the correct size specified) should never hurt and might help some UEFI implementations. So please run du -B 512 /srv/tftp/grubx64.efi to determine the size of the grub64.efi file in 512-byte blocks, and then add

option boot-size <size in blocks>;

within the subnet declaration in your dhcpd.conf file.

Having the boot-size option defined was apparently a requirement for PXE boot with earlier versions of the UEFI specification, but I would not be surprised if later versions have made that optional, or if some firmware authors have just chosen to write a PXE boot file download routine that uses the TFTP tsize option to request the TFTP server to tell the total size of the incoming file transfer before it begins, if that option is available.

If adding the option boot-size line doesn't help, and the firmware doesn't provide you any useful diagnostics, then you might want to dump the TFTP traffic and analyze it (e.g. with wireshark) to verify that the entire file gets transferred. On the PXE boot server, you might do something like this:

tcpdump -i eno1 -Knpvv -s0 -w pxe-tftp.cap udp

then make a PXE boot attempt while the tcpdump is running, then press Ctrl+C to stop the tcpdump. You might not be able to filter just the TFTP packets at tcpdump, because the TFTP server may allocate a different port for sending data to the client, and you won't be able to know in advance which port that will be.

Once you get the dump opened in Wireshark, just type in tftp into the filter expression bar and you'll see only the TFTP packets you're interested in. Then right-click on any TFTP packet displayed in the packet list window, and make sure Protocol Preferences -> Trivial File Transfer Protocol -> Reassemble fragmented TFTP files is checked. Now you can find the last packet of each TFTP file transfer (should be helpfully marked with (last)), open the Trivial File Transfer Protocol branch in the packet analysis window, and see a line like:

[nn TFTP Fragments (nnnnn bytes): ...]

The (nnnnn bytes) part will tell you the total transferred size for the file. If it does not match the actual size of the transferred file, you've probably found the cause. Fixing it might require a firmware update, though.

  • This is a really good answer - I'm going to try your advice as soon as I get the chance. Thx!
    – j4nd3r53n
    Commented Jul 13, 2022 at 7:56
  • Here's an odd observation, but maybe it is just because I don't know enough - the last packet captured claims to have a length of 1434 bytes, but the size of data inside is: Data (1426816 bytes), which matches the size of the file on disk.
    – j4nd3r53n
    Commented Jul 13, 2022 at 10:11
  • Wireshark is reassembling all the packets in the datastream for you, and indicating the total size of the file transferred over multiple packets. If all the TFTP packets are getting acknowledged by the client, it looks like the grubx64.efi file is getting transferred correctly and the problem would not seem to be the bootloader file getting truncated in transit. But it might still be a case of insufficient buffer being allocated for the transfer in the client; did you add the option boot-size 2786; line to the DHCP configuration?
    – telcoM
    Commented Jul 13, 2022 at 11:37
  • I did; that was the first thing I did. Should I make it bigger?
    – j4nd3r53n
    Commented Jul 13, 2022 at 12:26
  • No, it should accurately describe the size of your bootloader file in 512-byte blocks.
    – telcoM
    Commented Jul 13, 2022 at 12:32

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .