PXE boot has OS image size 1GB limitation?

Question

In my experience, if the OS image size is too big, the PXE boot will fail.

I am not sure which size is the limitation.

ref: https://www.syslinux.org/archives/2002-March/000249.html

Does iPXE fix the image size limitation issue?

Answer 1

The message you linked was written more than 20 years ago, and the comment about the "kernel" part of the memory space in Linux refers to 32-bit x86 kernels. If you are working with 64-bit hardware, that should not be relevant, especially if you are PXE booting in UEFI mode, rather than legacy BIOS mode.

It's been years since I experimented with PXE and large images at work, but I think it can depend on the protocol used to load the image. I seem to recall finding out that some TFTP implementations (don't recall if server or client was at fault, sorry) can have problems with transferring very large files. If that is the problem, iPXE can use HTTP instead, and modern HTTP servers certainly have no trouble sending large files.

And even if you don't use HTTP, iPXE's TFTP implementation might well be better than what's in your default PXE boot firmware.

I remember I found transferring large images with some firmware TFTP implementations to be quite slow: switching to iPXE and HTTP made the network boot with a large image much faster.

I found a source that lists the limitations of TFTP: https://www.compuphase.com/tftp.htm

The basic TFTP protocol defined by RFC 1350 has a default packet size of 512 bytes and a 16-bit packet counter, which would cause problems at about 32 MB size, unless the counter rollover is implemented correctly.

The extensions defined in RFCs 2348 and 2349 allow the negotiation of a bigger packet size, up to the maximum UDP packet size limit, which usually works out to 1468 bytes per packet, resulting in packet counter rollover at around 91 MB.

Those two would be the "expected" possible size limits the TFTP protocol might cause.