If you want to know more information about the files: Click Here
- iPXE may have issues with buggy bios or not supporting all hardware.
- This is because ipxe has about the same number of developers as FOG does, maybe even less.
- For what they have from personal and physical resources, it's not likely to always work on your machines.
- Because of this, I've maintained the original pxelinux.0 file in the /tftpboot folder. So if you're having troubles give it a shot.
undionly.* or ipxe.* (Which should I use?)
The primary filenames do different things at different points. First, they both enable the same initialization of protocols such as FTP, HTTP, NFS, HTTPS, CONSOLE, PARAMS, and many more. The major difference between undionly and ipxe that I've been able to discern is ipxe has it's native drivers builtin where undionly rely's on the underlying motherboard stack and/or pxe stack information. This is loaded from the "undi" driver.
Extensions (.pxe, .kpxe, .kkpxe, .kkkpxe, .efi)
The extensions do different things from what I've been able to find. The principles behind the different extensions are:
.pxe : The undi and ipxe code is NOT kept loaded. This will enable the start up of NIC's only for the drivers with in the native ipxe system. In the case of undionly, it will not work at all as there's literally no driver information, it's just easier to build all in one neat command.
.kpxe : keep underlying UNDI driver loaded. At least one "k" is required when trying to use the underlying UNDI driver (e.g. via undionly.kpxe) instead of a native driver (e.g. via intel.pxe).
.kkpxe : keep underlying UNDI driver and PXE base code loaded. At least two "k"s are required if you have BIOS bugs that prevent you from booting the next device via INT 18, and must instead exit back via the original PXE stack.
.kkkpxe : keep underlying UNDI driver and PXE base code loaded, and provide the PXENV_FILE_EXIT_HOOK API required when building ipxelinux.0. Unless you are building ipxelinux.0, you can completely ignore this.
.efi files are used for (u)EFI based network booting. Generally, only newer systems support UEFI type firmware. The .efi files that are normally located inside of /tftpboot are 64bit and .efi files located inside of /tftpboot/i386-efi are 32bit. (u)EFI enabled systems will either support 64bit booting or 32bit booting, but not both.
Many new systems (in 2015) are only (u)EFI. Future systems will likely all be (u)EFI only. Examples of these systems would include the Surface Pro series tablets, and several others.
NOTE: If you're attempting to image a Surface Pro, make sure the firmware is updated to the latest on the device.
(Source found: http://permalink.gmane.org/gmane.network.ipxe.devel/1988)