0

I'm trying to make a thinclient boot from network. I followed this tuturial.

On my Windows laptop I have 2 ethernet ports.

  1. USB-C docking ethernet port (for accessing internet)
  2. Original ethernet port (connected straight to the thinclient)

On my laptop is a Kubuntu VirtualBox configured as Network Boot Server running with 2 network interfaces.

  1. NAT (for accessing internet)
  2. Bridged with original ethernet port

In /etc/dnsmasq.conf I added the line dhcp-host=<<mac-addressOfOriginalEthernetPort>>,ignore so that the DHCP server ignores Windows trying to access the internet via the vm instead of the USB-C ethernet port.

Name of network boot option on the thinclient: UEFI: IP4 Intel(R) I210 Gigabit Network Connection

When the thinclient boots it the text on the screen is:

>>Checking Media Presence......
>>Media Present......
>>Start PXE over IPv4. Press ESC key to abort PXE boot.
  Station IP address is 192.168.50.178

  Server IP address 192.168.50.1
  NBP filename is pxelinux.0
  NBP filesize is 0 Bytes
  PXE-E18: Server response timeout.

Then the thinclient boots it's next boot option and doesn't start from the network. Any suggestions how to troubleshoot this problem?

The filesize is more than 0 Bytes:

@pxe-boot-kubuntu-vm:/netboot/tftp$ ls -la 
total 404
drwxrwxrwx 4 root root   4096 Feb 18 10:08 .
drwxrwxrwx 4 root root   4096 Feb 17 17:07 ..
-rwxrwxrwx 1 root root 120628 Feb 17 17:22 ldlinux.c32
-rwxrwxrwx 1 root root 175792 Feb 17 17:22 libcom32.c32
-rwxrwxrwx 1 root root  24356 Feb 17 17:22 libutil.c32
-rwxrwxrwx 1 root root  42694 Feb 17 17:22 pxelinux.0
drwxrwxrwx 2 root root   4096 Feb 18 10:11 pxelinux.cfg
drwxrwxrwx 2 root root   4096 Feb 18 10:10 ubuntu1804
-rwxrwxrwx 1 root root  28212 Feb 17 17:22 vesamenu.c32

What I tried:

  • Disabling Windows firewall
  • Switching between Legacy and UEFI in BIOS >> Advanced >> SCM Configuration >> Network
  • Network booting from a HP laptop instead of thinclient:
    Intel(R) Boot Agent CL v0.1.06
    Copyright (C) 1997-2013. Intel Corporation
    
    CLIENT MAC ADDR: xx xx xx xx xx xx  GUID:  ....
    CLIENT IP: 192.168.50.220 MASK: 255.255.255.0 DHCP IP: 192.168.50.1
    GATEWAY IP: 192.168.50.1
    Auto-select:
        Install OS via PXE
    PXE-E78: Could not locate boot server
    PXE-M0F: Exiting Intel Boot Agent.
0

Some PXE boot clients (especially early versions of UEFI PXE boot clients) may require that the DHCP answer that identifies the boot file and the TFTP server to load it from, must also contain an option that indicates the size of the boot file (DHCP option #13: boot file size as a 16-bit unsigned value, units of 512-byte blocks, partial blocks rounded up to the next higher integer value).

As your pxelinux.0 is sized 42694 bytes (= 83.3 blocks), you might try adding this line to your dnsmasq.conf:

dhcp-option=option:boot-file-size,84

If this option is missing, the PXE boot firmware may assume that the boot file size is 0 and fails to transfer it (maybe because the size option is used to allocate a memory buffer of suitable size before the transfer?).

Also note that when booting the thin client in UEFI mode, the boot file should be an .EFI binary suitable for the thin-client's hardware architecture. pxelinux.0 is the typical name for a BIOS-based boot file; the corresponding UEFI file would most likely be nimed pxelinux.efi or similar.

In general, I've had good results with UEFI network boot using iPXE instead of PXELINUX. It seems to me that iPXE tends to gain workarounds for UEFI PXE firmware bugs faster than PXELINUX does. You might try using ipxe.efi instead of pxelinux.0; if the file size seems to be a problem, you can try the minimized version snponly.efi.

2
  • I tried the dhcp-option=option:boot-file-size and changed the block size for the different files. I also edited the filename on the dhcp-boot option. The result was Downloading NBP file... PXE-E18: Server response timeout. I will now figure out iPXE – Matebo Feb 18 at 15:41
  • You might want to set your TFTP server to log as verbosely as it can. If that fails to shed more light on the subject, you might also want to use tcpdump, Wireshark or similar on the boot server to verify that the TFTP request actually arrives and that the server actually tries to answer it. – telcoM Feb 22 at 17:20

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.