Talk:IPXE

Merger proposal
I propose to merge gPXE article with iPXE, since both are closely related. --Ismael Luceno (talk) 03:41, 13 May 2012 (UTC)

As the maintainer of iPXE, I have no objection to this. Mcb30 (talk) 17:09, 13 May 2012 (UTC)

What if we merge iPXE into gPXE instead, since the gPXE came first, and the gPXE name is more familiar then iPXE. Gigglesworth (talk) 03:57, 28 August 2012 (UTC)

Merging iPXE into gPXE would not be appropriate, since gPXE is no longer maintained. (It would be similar to merging "LibreOffice" into "StarOffice".) 86.27.186.171 (talk) 13:10, 15 September 2012 (UTC)

I think the merge of the gPXE article with the iPXE article and a redirect of gPXE to iPXE is appropriate. The iPXE page already has a link to the etherboot.org - The Etherboot/gPXE Wiki and Both GPXE.ORG and ETHERBOOT.ORG redirect to this page. Merging iPXE into gPXE would not be appropriate becasue the fork happened when the person that owns the domain names gpxe.org and etherboot.org alienated the actual developers. Let this person keep the domain names but not the Wikipedia article. LAMurakami (talk) 21:35, 25 November 2012 (UTC)

gPXE is a forked version of iPXE, and according to the gPXE web site the 2 projects are not collaborating. gPXE is not a rebranding of iPXE and should not be merged. — Preceding unsigned comment added by JamieGoebel (talk • contribs) 00:14, 22 March 2013 (UTC)
 * gPXE is not a forked version of iPXE; it is exactly the other way around. I personally consider the article should be merged and called gPXE/iPXE.
 * 213.37.84.214 (talk) 10:31, 20 December 2013 (UTC)

There is also a couple things wrong for this article. 1. It says iPxe used to be gPxe. As you know, it was forked, gpxe didn't change their name to iPxe. 2. You can't load ftp or nfs. That's the kernel's job. — Preceding unsigned comment added by 8.26.74.148 (talk) 07:40, 28 July 2014 (UTC)
 * Agreed; I already fixed that mistake. Pxe 213 37 84 214 (talk) 13:42, 8 August 2014 (UTC)

Option ROM usage inconsistency in summary
The text "iPXE firmware cannot be considered as a "drop-in" replacement for PXE firmware." is actually wrong. Using the ROM-building feature of iPXE it is possible to make a PXE spec-compliant BIOS option ROM that can be used to replace e.g. Intel's PXE firmware as long as the hardware in question is supported by a native iPXE driver. You can see an example on how it is used to replace the PXE firmware for VirtualBox here: https://git.ipxe.org/ipxe.git/blob/HEAD:/src/config/vbox/README Robin Smidsrød (talk) 15:53, 13 March 2015 (UTC)


 * Hello! That description perhaps considers a "drop-in" replacement as something that provides 100%-equivalent interfaces to the outside world, while iPXE offers a much broader functionality than PXE's support for TFTP. &mdash; Dsimic (talk | contribs) 01:24, 25 March 2015 (UTC)


 * Hi there; I also consider the summary sentence is correct as it is; even if there is a mode to create an iPXE ROM able to mimic PXE features it is perfectly valid to say that "iPXE firmware cannot be considered as a "drop-in" replacement for PXE firmware."Pxe 213 37 84 214 (talk) 08:15, 18 February 2016 (UTC)


 * I came here, trying to understand what was meant by the "cannot" sentence. After reading the above comments, this is still unclear. If iPXE is a strict superset of pre-existing PXE firmware, then most certainly it is an entirely compatible replacement. If there are examples of PXE firmware that offer features not offered by iPXE, then we have a disjoint set ... are there any such examples? (What *is* the heritage of PXE firmware in commercial use?) If there are such examples, they should be mentioned (or referenced) in the article. If there is some other argument, then it too should be made clear. pbannister (talk) 16:16, 2 November 2021 (UTC)