You do not have permission to edit this page, for the following reasons:

This IP address has been blocked from editing Wikipedia.
This does not affect your ability to read Wikipedia pages.
Most people who see this message have done nothing wrong. Some kinds of blocks restrict editing from specific service providers or telecom companies in response to recent abuse or vandalism, and can sometimes affect other users who are unrelated to that abuse. Review the information below for assistance if you do not believe that you have done anything wrong.

The IP address or range 44.202.0.0/16 has been blocked (disabled) by ‪Blablubbs‬ for the following reason(s):

The IP address that you are currently using has been blocked because it is believed to be a web host provider or colocation provider. To prevent abuse, web hosts and colocation providers may be blocked from editing Wikipedia.
You will not be able to edit Wikipedia using a web host or colocation provider because it hides your IP address, much like a proxy or VPN.
We recommend that you attempt to use another connection to edit. For example, if you use a proxy or VPN to connect to the internet, turn it off when editing Wikipedia. If you edit using a mobile connection, try using a Wi-Fi connection, and vice versa. If you are using a corporate internet connection, switch to a different Wi-Fi network. If you have a Wikipedia account, please log in.
If you do not have any other way to edit Wikipedia, you will need to request an IP block exemption.

How to appeal if you are confident that your connection does not use a colocation provider's IP address:
If you are confident that you are not using a web host, you may appeal this block by adding the following text on your talk page: ((unblock|reason=Caught by a colocation web host block but this host or IP is not a web host. My IP address is _______. Place any further information here. ~~~~)). You must fill in the blank with your IP address for this block to be investigated. Your IP address can be determined here. Alternatively, if you wish to keep your IP address private you can use the unblock ticket request system. There are several reasons you might be editing using the IP address of a web host or colocation provider (such as if you are using VPN software or a business network); please use this method of appeal only if you think your IP address is in fact not a web host or colocation provider.

Administrators: The IP block exemption user right should only be applied to allow users to edit using web host in exceptional circumstances, and requests should usually be directed to the functionaries team via email. If you intend to give the IPBE user right, a CheckUser needs to take a look at the account. This can be requested most easily at SPI Quick Checkuser Requests. Unblocking an IP or IP range with this template is highly discouraged without at least contacting the blocking administrator.

This block will expire on 21:04, 17 October 2024.

Even when blocked, you will usually still be able to edit your user talk page, as well as email administrators and other editors.

For information on how to proceed, please read the FAQ for blocked users and the guideline on block appeals. The guide to appealing blocks may also be helpful.

Other useful links: Blocking policy · Help:I have been blocked
Your IP address is in a range that has been blocked on all Wikimedia Foundation wikis. The block was made by ‪AntiCompositeNumber‬. The reason given is Open proxy/Webhost: Visit the FAQ if you are affected .
- Start of block: 13:55, 18 August 2022
- Expiry of block: 13:55, 18 September 2024
Your current IP address is 44.202.77.27. The blocked range is 44.202.0.0/16. Please include all above details in any queries you make. If you believe you were blocked by mistake, you can find additional information and instructions in the No open proxies global policy. Otherwise, to discuss the block please post a request for review on Meta-Wiki. You could also send an email to the stewards VRT queue at stewards@wikimedia.org including all above details.

You can view and copy the source of this page:

((short description|Standard for booting from a server))
((For|an episode of the animated series ''Adventure Time''|Preboot))
((More citations needed|date=May 2021))
[[File:PXE diagram.png|thumb|right|upright=1.3|A high-level PXE overview]]

In computing, the '''Preboot eXecution Environment''', '''PXE''' (most often pronounced as ((IPAc-en|'|p|I|k|s|i:)) ''pixie'', often called PXE Boot/''pixie boot''.) specification describes a standardized [[client–server model|client–server]] environment that [[booting|boots]] a software assembly, retrieved from a network, on PXE-enabled clients.  On the client side it requires only a PXE-capable [[network interface controller]] (NIC), and uses a small set of industry-standard network protocols such as [[Dynamic Host Configuration Protocol|DHCP]] and [[Trivial File Transfer Protocol|TFTP]].

The concept behind the PXE originated in the early days of protocols like [[BOOTP]]/DHCP/TFTP, and ((as of|2015|lc=on)) it forms part of the [[UEFI|Unified Extensible Firmware Interface]] (UEFI) standard. In modern data centers, PXE is the most frequent choice<ref name="pxespread">((cite book 
|last= Avramov
|first= Lucien
|date=December 31, 2014 
|title=The Policy Driven Data Center with ACI: Architecture, Concepts, and Methodology 
|quote= In modern data centers, administrators rarely install new software via removable media such as DVDs. Instead, administrators rely on PXE (Preboot eXecution Environment) booting to image servers.
|publisher=Cisco Press 
|page= 43
|isbn=978-1587144905 
))</ref> for operating system booting, installation and deployment.

== Overview ==
Since the beginning of computer networks, there has been a persistent need for [[Client (Computing)|client]] systems which can [[Bootstrapping#Computing|boot]] appropriate software images, with appropriate configuration parameters, both retrieved at boot time from one or more network [[Server (computing)|servers]]. This goal requires a client to use a set of pre-boot services, based on industry standard [[network protocol]]s. Additionally, the Network Bootstrap Program (NBP) which is initially downloaded and run must be built using a client [[firmware]] layer (at the device to be bootstrapped via PXE) providing a hardware independent standardized way to interact with the surrounding network booting environment. In this case the availability and subjection to standards are a key factor required to guarantee the network boot process system interoperability.((Citation needed|date=August 2023))

One of the first attempts in this regard was bootstrap loading using TFTP standard RFC 906, published in 1984, which established the 1981 published [[Trivial File Transfer Protocol]] (TFTP) standard RFC 783 to be used as the standard file transfer protocol for bootstrap loading. It was  followed shortly after by the [[Bootstrap Protocol]] standard RFC 951 (BOOTP), published in 1985, which allowed a [[diskless node|diskless client machine]] to discover its own IP address, the address of a TFTP server, and the name of an NBP to be loaded into memory and executed. BOOTP implementation difficulties, among other reasons, eventually led to the development of the [[Dynamic Host Configuration Protocol]] standard RFC 2131 (DHCP) published in 1997. The pioneering TFTP/BOOTP/DHCP approach fell short, as at the time, it did not define the required standardized client side of the provisioning environment.

The Preboot Execution Environment (PXE) was introduced as part of the [[Wired for Management]]<ref name="wfmspec">((cite web
 | url = http://download.intel.com/design/archives/wfm/downloads/base20.pdf
 | title = Wired for Management Baseline - Version 2.0 Release
 | publisher = Intel Corporation
 | date = 1998-12-18
 | access-date = 2014-02-08
 | archive-url = https://web.archive.org/web/20170222225329/http://download.intel.com/design/archives/wfm/downloads/base20.pdf
 | archive-date = 2017-02-22
))</ref> framework by [[Intel]] and is described in the specification published by Intel and SystemSoft. PXE version 2.0 was released in December 1998, and the update 2.1 was made public in September 1999.<ref name="pxespec">((cite web
 |url         = http://download.intel.com/design/archives/wfm/downloads/pxespec.pdf
 |title       = Preboot Execution Environment (PXE) Specification - Version 2.1
 |publisher   = Intel Corporation
 |date        = 1999-09-20
 |access-date  = 2014-02-08
 |url-status     = dead
 |archive-url  = https://web.archive.org/web/20131102003141/http://download.intel.com/design/archives/wfm/downloads/pxespec.pdf
 |archive-date = 2013-11-02
))</ref> The PXE environment makes use of several standard client‑server protocols including DHCP and TFTP (now defined by the 1992 published RFC 1350). Within the PXE schema the client  side of the provisioning equation is an integral part of the PXE standard and it is implemented either as a [[Network Interface Card]] (NIC) [[BIOS]] extension or current devices in [[UEFI]] code. This distinctive firmware layer makes available at the client the functions of a basic Universal Network Device Interface (UNDI), a minimalistic [[UDP/IP|UDP]]/[[Internet protocol suite|IP]] stack, a Preboot (DHCP) client module and a TFTP client module, together forming the PXE [[API|application programming interface]]s (APIs) used by the NBP when needing to interact with the services offered by the server counterpart of the PXE environment. TFTP's low [[throughput]], especially when used over high-[[Latency (engineering)|latency]] links, has been initially mitigated by the TFTP Blocksize Option RFC 2348 published in May 1998, and later by the TFTP Windowsize Option RFC 7440 published in January 2015, allowing potentially larger payload deliveries and thus improving throughput.((Citation needed|date=August 2023))

== Details ==
The PXE environment relies on a combination of industry-standard Internet protocols, namely UDP/IP, DHCP and TFTP. These protocols have been selected because they are easily implemented in the client's NIC firmware, resulting in standardized small-[[Memory footprint|footprint]] PXE ROMs. Standardization, small size of PXE firmware images and their low use of resources are some of the primary design goals, allowing the client side of the PXE standard to be identically implemented on a wide variety of systems, ranging from powerful client computers to resource-limited [[single-board computer]]s (SBC) and [[system-on-a-chip]] (SoC) computers.

DHCP is used to provide the appropriate client network parameters and specifically the location (IP address) of the TFTP server hosting, ready for download, the initial bootstrap program (NBP) and complementary files. To initiate a PXE bootstrap session the DHCP component of the client's PXE firmware [[Broadcast address|broadcasts]] a DHCPDISCOVER packet containing PXE-specific options to port 67/UDP (DHCP server port); it asks for the required network configuration and network booting parameters. The PXE-specific options identify the initiated DHCP transaction as a PXE transaction. Standard DHCP servers (non PXE enabled) will be able to answer with a regular DHCPOFFER carrying networking information (i.e. IP address) but not the PXE specific parameters. A PXE client will not be able to boot if it only receives an answer from a non PXE enabled DHCP server.

After parsing a PXE enabled DHCP server DHCPOFFER, the client will be able to set its own network IP address, IP Mask, etc., and to point to the network located booting resources, based on the received TFTP Server IP address and the name of the NBP. The client next transfers the NBP into its own [[random-access memory]] (RAM) using TFTP, possibly verifies it (i.e. UEFI [[Unified Extensible Firmware Interface#Secure Boot|Secure Boot]]), and finally boots from it. NBPs are just the first link in the boot chain process and they generally request via TFTP a small set of complementary files in order to get running a minimalistic OS executive (i.e. [[Windows Preinstallation Environment|WindowsPE]], or a basic [[Linux kernel]]+[[initrd]]). The small OS executive loads its own network drivers and TCP/IP stack. At this point, the remaining instructions required to boot or install a full OS are provided not over TFTP, but using a robust transfer protocol (such as [[Hypertext Transfer Protocol|HTTP]], [[Cifs|CIFS]], or [[Network File System|NFS]]).

== Integration ==
[[File:DHCP vs proxyDHCP Server.png|thumb|DHCP vs proxyDHCP Server]]
The PXE Client/Server environment was designed so it can be seamlessly integrated with an already in place DHCP and TFTP server infrastructure.
This design goal presented a challenge when dealing with the classic DHCP protocol. Corporate DHCP servers are usually subject to strict policies that are designed to prevent easily adding the additional parameters and rules required to support a PXE environment. For this reason the PXE standard developed the concept of DHCP redirection or "proxyDHCP". The idea behind a proxyDHCP is to split the PXE DHCP requirements in two independently run and administered server units:

# The classic DHCP server providing IP address, IP mask, etc. ''to all booting DHCP clients''.
# The proxyDHCP server providing TFTP server IP address and name of the NBP ''only to PXE identified booting clients''.

In a DHCP plus proxyDHCP server environment<ref name="pxespec" />((rp|18)) the PXE client initially broadcasts a single PXE DHCPDISCOVER packet and receives two complementary DHCPOFFERs; one from the regular non PXE enabled DHCP server and a second one from the proxyDHCP server. Both answers together provide the required information to allow the PXE client to continue with its booting process. This non-intrusive approach allows setting a PXE environment without touching the configuration of an already working DHCP server. The proxyDHCP service may also run on the same host as the standard DHCP service but even in this case they are both two independently run and administered applications. Since two services cannot use the same port 67/UDP on the same host, the proxyDHCP runs on port 4011/UDP. The proxyDHCP approach has proved to be extremely useful in a wide range of PXE scenarios going from corporate to home environments.

== Availability  ==
PXE was conceived considering several system architectures. The version 2.1 of the specification defined architecture identifiers for six system types, including [[IA-64]] and [[DEC Alpha]]. However, PXE v2.1 only completely covered [[IA-32]]. Despite this apparent lack of completeness Intel has recently decided to widely support PXE within the new [[UEFI]] specification extending the PXE functionality to all EFI/UEFI environments. 
Current Unified Extensible Firmware Interface Specification 2.4A, Section 21 Network Protocols — SNP, PXE, and BIS defines the protocols that provide access to network devices
while executing in the UEFI boot services environment. These protocols include the Simple Network Protocol (SNP), the PXE Base Code Protocol (PXE), and the Boot Integrity Services Protocol (BIS).<ref name="2_4_Errata_A">((cite web
 | url = http://www.uefi.org/sites/default/files/resources/2_4_Errata_A.pdf
 | title = Unified Extensible Firmware Interface Specification
 | publisher = UEFI
 | date = 2013-12-02
 | access-date = 2014-04-04
))</ref><ref name="Intel_UEFI_PXE_Boot_Performance_Analysis">((cite web
 | url = https://uefidk.com/sites/default/files/Intel_UEFI_PXE_Boot_Performance_Analysis.pdf
 | title = UEFI PXE Boot Performance Analysis
 | publisher = Intel Corporation
 | date = 2014-02-02
 | access-date = 2014-04-04
 | archive-url = https://web.archive.org/web/20140808044632/https://uefidk.com/sites/default/files/Intel_UEFI_PXE_Boot_Performance_Analysis.pdf
 | archive-date = 2014-08-08
 | url-status = dead
 ))</ref>
Today in a PXE environment the client architecture detection is rarely based on the identifiers originally included with the PXE v2.1 specification. Instead, each computer that will be booting from the network should have set DHCP option 93 to indicate the client's architecture. This enables a PXE server to know (at boot time) the exact architecture of the client from the first network boot packet.((Ref RFC|4578))

With the advent of [[IPv6]], DHCP has evolved into [[DHCPv6]]; the need for options supporting PXE within the new DHCP protocol has been addressed in 2010.((Ref RFC|5970))

The original PXE client firmware extension was designed as an [[Option ROM]] for the IA-32 [[BIOS]], so a [[personal computer]] (PC) was originally made PXE-capable by installing a [[network interface controller]] (NIC) that provided a PXE Option ROM. Today the client PXE code is directly included within the NIC's own firmware or as part of the UEFI firmware on the motherboard.

Even when the original client PXE firmware has been written by Intel and always provided at no cost as a linkable IA32 [[Object code file format|object code format]] module included in their Product Development Kit (PDK), the open source world has produced over the years non-standard derivative projects like [[gPXE]]/[[iPXE]] offering their own ROMs. While Intel based ROMs have been implementing the client side of the PXE standard for more than 20 year some users were willing to trade extra features for stability and PXE standard conformance.<ref name="gPXE">((cite web
 | url = http://etherboot.org/wiki/
 | title = Etherboot/gPXE Wiki
 | publisher = Etherboo.org
))</ref>

== Acceptance ==
PXE acceptance since v2.1 has been ubiquitous; today it is virtually impossible to find a network card without PXE firmware on it. The availability of inexpensive [[Gigabit Ethernet]] hardware (NICs, [[Network switch|switches]], [[Network router|routers]], etc.) has made PXE the fastest method available for installing an operating system on a client when competing against the classic [[CD]], [[DVD]], and [[USB flash drive]] alternatives.

Over the years several major projects have included PXE support, including: 
* All the major Linux distributions.
* [[OpenVMS]] on [[HPE Integrity]] and [[x86-64]] hardware.
* Microsoft [[Remote Installation Services]] (RIS)
* Microsoft [[Windows Deployment Services]] (WDS) 
* [[Microsoft Deployment Toolkit]] (MDT)
* Microsoft [[System Center Configuration Manager]] (SCCM)

In regard to NBP development there are several projects implementing Boot Managers able to offer boot menu extended features, scripting capabilities, etc.:
* Syslinux [[PXELINUX]]
* [[gPXE]]/[[iPXE]]

All the above-mentioned projects, when they are able to boot/install more than one OS, work under a "Boot Manager - Boot Loader" paradigm. The initial NBP is a Boot Manager able to retrieve its own configuration and deploy a menu of booting options. The user selects a booting option and an OS dependent Boot Loader is downloaded and run in order to continue with the selected specific booting procedure.

== Sibling environments ==
[[Apple Inc.|Apple]] has come up with a very similar network boot approach under the umbrella of the [[Boot Service Discovery Protocol|Boot Server Discovery Protocol]] (BSDP) specification. BSDP v0.1 was initially published by Apple in August 1999<ref name="BSDP_1">((cite web
 | url = http://opensource.apple.com/source/bootp/bootp-170/Documentation/BSDP.doc
 | title = NetBoot 2.0: Boot Server Discovery Protocol (BSDP) v0.1
 | publisher = Apple Corporation
 | format= Doc
 | date = 2003-12-02
 | access-date = 2014-04-04
))</ref> and its last v1.0.8 was published in September 2010.<ref name="BSDP_2">((cite web
 | url = https://opensource.apple.com/source/bootp/bootp-254.1/Documentation/BSDP.doc
 | title = NetBoot 2.0: Boot Server Discovery Protocol (BSDP) v1.08
 | publisher = Apple Corporation
 | format= Doc
 | date = 2010-09-17
 | access-date = 2014-04-04
))</ref> [[Mac OS X Server]] included a system tool called [[NetBoot]]. A NetBoot client uses BSDP to dynamically acquire resources that enable it to boot a suitable operating system. BSDP is crafted on top of DHCP using vendor-specific information to provide the additional NetBoot functionality not present in standard DHCP. The protocol is implemented in client firmware. At boot time, the client obtains an IP address via DHCP then discovers boot servers using BSDP. Each BSDP server responds with boot information consisting of:
* A list of bootable operating system images
* The default operating system image
* The client's currently selected operating system image (if defined)

The client chooses an operating system from the list and sends a message to the server indicating its selection. The selected boot server responds supplying the boot file and
boot image, and any other information needed to download and execute the selected operating system.

== Descendant environments ==
[[Microsoft]] created a non-overlapping extension of the PXE environment with their Boot Information Negotiation Layer (BINL). BINL is implemented as a server service and it is a key component of their Remote Installation Services (RIS) and Windows Deployment Services (WDS) strategies. It includes certain preparation processes and a network protocol that could be somehow considered a Microsoft-crafted DHCP extension. BINL is a Microsoft proprietary technology that uses PXE standard client firmware. Currently there is not a publicly available BINL specification.

==IETF standards documentation==
*((Ref RFC|783|ref=no))
*((Ref RFC|906|ref=no))
*((Ref RFC|951|ref=no))
*((Ref RFC|1350|ref=no))
*((Ref RFC|2131|ref=no))
*((Ref RFC|2348|ref=no))
*((Ref RFC|4578|ref=no))
*((Ref RFC|5970|ref=no))
*((Ref RFC|7440|ref=no))

== See also ==

((Div col|colwidth=22em))
* [[Diskless node]]s((snd)) diskless computers
* [[Boot Service Discovery Protocol]]((snd)) Apple network boot protocol
* [[Remote Initial Program Load]] (RIPL or RPL)
* [[System Deployment Image]] (SDI)((snd)) primarily with Microsoft products 
* [[Unified Extensible Firmware Interface#Network booting|Unified Extensible Firmware Interface]]((snd)) UEFI network booting
* [[Wake-on-LAN]] (WOL)
* [[Windows Deployment Services]]((snd)) PXE-based deployment for Microsoft Windows
((div col end))

== References ==
((Reflist|30em))

==External links==
* [https://web.archive.org/web/20110524083740/http://download.intel.com/design/archives/wfm/downloads/pxespec.pdf PXE specification]((snd)) The Preboot Execution Environment specification v2.1 published by Intel & SystemSoft
* [https://web.archive.org/web/20091117070518/http://download.intel.com/design/archives/wfm/downloads/bisspec.pdf BIS specification]((snd)) The Boot Integrity Services specification v1.0 published by Intel
* [http://tools.ietf.org/html/draft-henry-remote-boot-protocol-00 Intel Preboot Execution Environment]((snd)) Internet-Draft 00 of the PXE Client/Server Protocol included in the PXE specification
* [https://web.archive.org/web/20140221222847/http://h18013.www1.hp.com/products/servers/management/rdp/knowledgebase/00000138.html PXE error codes]((snd)) A catalogue of PXE error codes

((Firmware and booting))

[[Category:Networking standards]]
[[Category:Network protocols]]
[[Category:Network booting]]
[[Category:Firmware]]
[[Category:BIOS]]
[[Category:Unified Extensible Firmware Interface]]

Pages transcluded onto the current version of this page (help):

Preboot Execution Environment (edit)
Template:Ambox (view source) (template editor protected)
Template:As of (view source) (template editor protected)
Template:Catalog lookup link (view source) (template editor protected)
Template:Category handler (view source) (protected)
Template:Citation (view source) (protected)
Template:Citation needed (view source) (protected)
Template:Cite IETF (view source) (semi-protected)
Template:Cite IETF/doctypes (view source) (semi-protected)
Template:Cite IETF/makelink (view source) (semi-protected)
Template:Cite book (view source) (protected)
Template:Cite web (view source) (protected)
Template:DMCA (view source) (template editor protected)
Template:Dated maintenance category (view source) (template editor protected)
Template:Dated maintenance category (articles) (view source) (template editor protected)
Template:Delink (view source) (protected)
Template:Div col (view source) (template editor protected)
Template:Div col/styles.css (view source) (template editor protected)
Template:Div col end (view source) (template editor protected)
Template:FULLROOTPAGENAME (view source) (template editor protected)
Template:Find sources mainspace (view source) (template editor protected)
Template:Firmware and booting (edit)
Template:Fix (view source) (protected)
Template:Fix/category (view source) (protected)
Template:For (view source) (template editor protected)
Template:Hlist/styles.css (view source) (protected)
Template:IETF RFC (view source) (template editor protected)
Template:IPAc-en (view source) (template editor protected)
Template:Main other (view source) (protected)
Template:More citations needed (view source) (template editor protected)
Template:Navbox (view source) (template editor protected)
Template:Ns has subpages (view source) (protected)
Template:Pagetype (view source) (protected)
Template:R/superscript (view source) (template editor protected)
Template:R/where (view source) (template editor protected)
Template:Ref RFC (edit)
Template:Ref RFC/db/13 (edit)
Template:Ref RFC/db/21 (edit)
Template:Ref RFC/db/23 (edit)
Template:Ref RFC/db/45 (edit)
Template:Ref RFC/db/59 (edit)
Template:Ref RFC/db/7 (edit)
Template:Ref RFC/db/74 (edit)
Template:Ref RFC/db/9 (edit)
Template:Ref RFC/getref (edit)
Template:Ref RFC/secpage (edit)
Template:Reflist (view source) (protected)
Template:Reflist/styles.css (view source) (protected)
Template:Rp (view source) (template editor protected)
Template:SDcat (view source) (protected)
Template:Short description (view source) (protected)
Template:Short description/lowercasecheck (view source) (protected)
Template:Snd (view source) (template editor protected)
Template:Spaced en dash (view source) (template editor protected)
Template:Yesno (view source) (protected)
Template:Yesno-no (view source) (template editor protected)
Template:Yesno-yes (view source) (template editor protected)
Module:Arguments (view source) (protected)
Module:Catalog lookup link (view source) (template editor protected)
Module:Category handler (view source) (protected)
Module:Category handler/blacklist (view source) (protected)
Module:Category handler/config (view source) (protected)
Module:Category handler/data (view source) (protected)
Module:Category handler/shared (view source) (protected)
Module:Check for unknown parameters (view source) (protected)
Module:Citation/CS1 (view source) (protected)
Module:Citation/CS1/COinS (view source) (protected)
Module:Citation/CS1/Configuration (view source) (protected)
Module:Citation/CS1/Date validation (view source) (protected)
Module:Citation/CS1/Identifiers (view source) (protected)
Module:Citation/CS1/Utilities (view source) (protected)
Module:Citation/CS1/Whitelist (view source) (protected)
Module:Citation/CS1/styles.css (view source) (protected)
Module:DecodeEncode (view source) (template editor protected)
Module:Delink (view source) (protected)
Module:Disambiguation/templates (view source) (protected)
Module:Find sources (view source) (template editor protected)
Module:Find sources/config (view source) (template editor protected)
Module:Find sources/links (view source) (template editor protected)
Module:Find sources/templates/Find sources mainspace (view source) (template editor protected)
Module:For (view source) (template editor protected)
Module:Format link (view source) (template editor protected)
Module:GetParameters (view source) (template editor protected)
Module:Hatnote (view source) (template editor protected)
Module:Hatnote/styles.css (view source) (template editor protected)
Module:Hatnote list (view source) (template editor protected)
Module:IPAc-en (view source) (template editor protected)
Module:IPAc-en/data (view source) (template editor protected)
Module:IPAc-en/phonemes (view source) (template editor protected)
Module:IPAc-en/pronunciation (view source) (template editor protected)
Module:Message box (view source) (protected)
Module:Message box/ambox.css (view source) (protected)
Module:Message box/configuration (view source) (protected)
Module:Namespace detect/config (view source) (protected)
Module:Namespace detect/data (view source) (protected)
Module:Navbar (view source) (protected)
Module:Navbar/configuration (view source) (protected)
Module:Navbar/styles.css (view source) (protected)
Module:Navbox (view source) (template editor protected)
Module:Navbox/configuration (view source) (template editor protected)
Module:Navbox/styles.css (view source) (template editor protected)
Module:Ns has subpages (view source) (protected)
Module:Pagetype (view source) (protected)
Module:Pagetype/config (view source) (protected)
Module:Pagetype/disambiguation (view source) (protected)
Module:Pagetype/setindex (view source) (protected)
Module:Pagetype/softredirect (view source) (protected)
Module:Plain text (view source) (template editor protected)
Module:SDcat (view source) (protected)
Module:String (view source) (protected)
Module:String2 (view source) (template editor protected)
Module:Template wrapper (view source) (template editor protected)
Module:Unsubst (view source) (protected)
Module:Wikitext Parsing (view source) (protected)
Module:Yesno (view source) (protected)

Return to Preboot Execution Environment.

Retrieved from "https://en.wikipedia.org/wiki/Preboot_Execution_Environment"