http://en.wikipedia.org/wiki/Network_booting
Network booting
Network booting is the process of booting a computer from a network rather than a local drive. This method of booting can be used by routers , diskless workstations and centrally managed computers ( thin clients ) such as public computers at libraries and schools. Network booting can be used to centralise management of disk storage, which supporters claim can result in reduced capital and maintenance costs. It can also be used in cluster computing , in which nodes may not have local disks.
Hardware support[edit]
Contemporary desktop personal computers generally provide an option to boot from the network in their firmware, frequently via the Preboot Execution Environment(PXE). Post-1998 PowerPC (G3 - G5) Mac systems can also boot from their firmware to a network disk via NetBoot. Other personal computers can utilize a floppy disk or flash drive containing software to boot from the network instead, using technology such as iPXE.
Process[edit]
The initial software to be loaded is loaded from a server on the network; for TCP/IP networks this is usually done using the Trivial File Transfer Protocol. The server from which to load the initial software is usually found by broadcasting or multicasting a Bootstrap Protocol or Dynamic Host Configuration Protocol request. Typically, this initial software is not a full image of the operating system to be loaded, but just part of it - enough for the operating system to start and then take control of the booting process, and continue booting over the network.
Legacy[edit]
Before IP became the primary Layer 3 protocol, NetWare Core Protocol and IBM RIPL was widely used for network booting. Their client implementations also fit into smaller ROM than PXE. Technically network booting can be implemented over any of file transfer or resource sharing protocols, for example, NFS is preferred by BSD variants.
Installations[edit]
Network booting is also used for unattended operating system installations. In this case, a network-booted helper operating system is used as a platform to execute the script-driven, unattended installation of the intended operating system on the target machine. Implementations of this for Mac OS X and Windowsexist as NetInstall and Windows Deployment Services, respectively.
See also[edit]
External links[edit]
- iPXE project - a scriptable network boot loader and network card firmware.
- NetworkBoot.org - a place for beginners to learn the fundamentals of network booting.
《Preboot Execution Environment(PXE) Specification Version 2.1》
This document specifies the Preboot Execution Environment (PXE). PXE embodies three
technologies that will establish a common and consistent set of pre-boot services within the boot
firmware of Intel Architecture systems:
! A uniform protocol for the client to request the allocation of a network address and
subsequently request the download of an NBP(Network Bootstrap Program) from a network boot server.
! A set of APIs available in the machine’s pre-boot firmware environment that constitutes a
consistent set of services that can be employed by the NBP or the BIOS.
! A standard method of initiating the pre-boot firmware to execute the PXE protocol on the
client machine.
In summary, using the capabilities described above, a newly installed networked client machine
should be able to enter a heterogeneous network, acquire for itself a network address from a DHCP
server, and then download an NBP to set itself up. This sets the stage to enable IT managers to
customize the manner in which their network client machines go through a network-based booting
process.
1.5 Overview
1.5.1 PXE Protocol
PXE is defined on a foundation of industry-standard Internet protocols and services that are widely
deployed in the industry, namely TCP/IP, DHCP, and TFTP. These standardize the form of the
interactions between clients and servers. To ensure that the meaning of the client-server interaction is
standardized as well, certain vendor option fields in DHCP protocol are used, which are allowed by
the DHCP standard. The operations of standard DHCP and/or BOOTP servers (that serve up IP
addresses and/or NBPs) will not be disrupted by the use of the extended protocol. Clients and servers
that are aware of these extensions will recognize and use this information, and those that do not
recognize the extensions will ignore them.
In brief, the PXE protocol operates as follows. The client initiates the protocol by broadcasting a
DHCPDISCOVER containing an extension that identifies the request as coming from a client that
implements the PXE protocol. Assuming that a DHCP server or a Proxy DHCP server implementing
this extended protocol is available, after several intermediate steps, the server sends the client a list
of appropriate Boot Servers. The client then discovers a Boot Server of the type selected and receives
the name of an executable file on the chosen Boot Server. The client uses TFTP to download the
executable from the Boot Server. Finally, the client initiates execution of the downloaded image. At
this point, the client’s state must meet certain requirements that provide a predictable execution
environment for the image. Important aspects of this environment include the availability of certain
areas of the client’s main memory, and the availability of basic network I/O services.
1.5.1.1 Deployment of servers
On the server end of the client-server interaction there must be available services that are responsible
for providing redirection of the client to an appropriate Boot Server. These redirection services may
be deployed in two ways:
1. Combined standard DHCP and redirection services. The DHCP servers that are supplying IP
addresses to clients are modified to become, or are replaced by servers that serve up IP addresses
for all clients and redirect PXE-enabled clients to Boot Servers as requested.
2. Separate standard DHCP and redirection services. PXE redirection servers (Proxy DHCP
servers) are added to the existing network environment. They respond only to PXE-enabled
clients, and provide only redirection to Boot Servers.
Each PXE Boot Server must have one or more executables appropriate to the clients that it serves.
1.5.1.2 Deployment of Clients
PXE does not specify the operational details and functionality of the NBP that the client receives
from the server. However, the intent is that running this executable will result in the system’s being
ready for use by its user. At a minimum, this means installing an operating system, drivers, and
software appropriate to the client’s hardware configuration. It might also include user-specific system
configuration and application installation.
PXE specifies the protocols by which a client requests and downloads an executable image from a
Boot Server and the minimum requirements on the client execution environment when the
downloaded image is executed.
1.5.2 PXE APIs
To enable the interoperability of clients and downloaded bootstrap programs, the client PXE code
provides a set of services for use by the BIOS or a downloaded NBP.
The API services provided by PXE for use by the BIOS or NBP are:
! Preboot Services API. Contains several global control and information functions.
! Trivial File Transport Protocol (TFTP) API. Enables opening and closing of TFTP
connections, and reading packets from and writing packets to a TFTP connection.
! User Datagram Protocol (UDP) API. Enables opening and closing UDP connections, and
reading packets from and writing packets to a UDP connection.
! Universal Network Driver Interface (UNDI) API. Enables basic control of and I/O through
the client’s network interface device. This allows the use of universal protocol drivers such
that the same universal driver can be used on any network interface that implements this API.
The following diagram illustrates the relationship between the NBP (the remote boot program) and
the PXE APIs.
http://en.wikipedia.org/wiki/Preboot_Execution_Environment
Preboot Execution Environment
The Preboot eXecution Environment ( PXE , also known as Pre-Execution Environment ; sometimes pronounced "pixie") is an environment to boot computers using a network interface independently of data storage devices (like hard disks ) or installed operating systems .
PXE was introduced as part of the Wired for Management framework by Intel and is described in the specification (version 2.1) published by Intel and SystemSoft on September 20, 1999.[1] It makes use of several network protocols like Internet Protocol (IPv4), User Datagram Protocol (UDP), Dynamic Host Configuration Protocol (DHCP) and Trivial File Transfer Protocol (TFTP) and of concepts like Globally Unique Identifier (GUID), Universally Unique Identifier (UUID) and Universal Network Device Interface and extends the firmware of the PXE client (the computer to be bootstrapped via PXE) with a set of predefined Application Programming Interfaces (APIs).
Contents
[hide]
Chain
The firmware on the client tries to locate a PXE redirection service on the network (Proxy DHCP) in order to receive information about available PXE boot servers. After parsing the answer, the firmware will ask an appropriate boot server for the file path of a network bootstrap program (NBP), download it into the computer's random-access memory (RAM) using TFTP, possibly verify it, and finally execute it.
Availability
PXE was designed to be applicable to many system architectures. The 2.1 version of the specification assigns architecture identifiers to six system types, including IA-64 and DEC Alpha. However, the specification only completely covers IA-32. Intel included PXE in the EFI for IA-64, creating a de facto standard with the implementation.
Besides proprietary PXE boot images, alternative "non-standard" open source implementations are also available, providing even broader possibilities like booting over HTTP or iSCSI.[2] They can be either chainloaded from proprietary PXE implementations, or burned into EPROMs of network adapters as a complete replacement.[3][4]
Protocol
The PXE protocol is approximately a combination of DHCP and TFTP, albeit with subtle modifications to both. DHCP is used to locate the appropriate boot server or servers, with TFTP used to download the initial bootstrap program and additional files.
To initiate a PXE bootstrap session the PXE firmware broadcasts a DHCPDISCOVER packet extended with PXE-specific options (extended DHCPDISCOVER) to port 67/UDP (DHCP server port). The PXE options identify the firmware as capable of PXE, but they will be ignored by standard DHCP servers. If the firmware receives DHCPOFFERs from such servers, it may configure itself by requesting one of the offered configurations.
Proxy DHCP
If a PXE redirection service (Proxy DHCP) receives an extended DHCPDISCOVER, it replies with an extended DHCPOFFER to the client's port 68/UDP (DHCP client port).
An extended DHCPOFFER contains mainly:
- a PXE Discovery Control field to recommend multicasting, broadcasting, or unicasting to contact PXE boot servers
- a list of IP addresses of each available PXE Boot Server Type
- a PXE Boot Menu with each entry representing a PXE Boot Server Type
- a PXE Boot Prompt telling the user to press a certain key to see the boot menu
- a timeout to launch the first boot menu entry if it expires
The Proxy DHCP service may also run on the same host as the standard DHCP service. Since two services cannot share port 67/UDP, the Proxy DHCP runs on port 4011/UDP and expects the extended DHCPDISCOVER packets from PXE Clients to be DHCPREQUESTs.[5] The standard DHCP service has to send a special combination of PXE options in its DHCPOFFER, so the PXE client knows to look for a Proxy DHCP on the same host, port 4011/UDP.
Boot server contact
To contact a PXE Boot Server the booting system must have an IP address (perhaps from a DHCP server).
It multicasts or unicasts a DHCPREQUEST packet extended with PXE-specific options (extended DHCPREQUEST) to port 4011/UDP or broadcasts it to port 67/UDP. This packet contains the PXE Boot Server type and the PXE Boot Layer, allowing multiple boot server types to run from one daemon. The extended DHCPREQUEST may be a DHCPINFORM.
A PXE Boot Server receiving an extended DHCPREQUEST configured for the requested type and client architecture responds with an extended DHCPACK including:
- the complete file path to download the NBP via TFTP.
- PXE Boot Server type and PXE Boot Layer it answered
- the multicast TFTP configuration, if MTFTP as described in the PXE specification should be used.
The booting system accepts information from only one extended DHCPOFFER.
A 2.1 version PXE Boot Server supports "Boot Integrity Services"[6] allowing the Client to verify downloaded NBPs using a checksum file which is downloaded from the same boot server as the NBP.
To get the file path of this credentials file another exchange of extended DHCPREQUEST and extended DHCPACK is required.
Network bootstrap program
After receiving the requested extended DHCPACK, the Network Bootstrap Program is uploaded into RAM and after it is verified or if verification is not required, the NBP will be executed. It has access to the APIs of the PXE firmware extension (Pre-boot, UDP, TFTP, Universal Network Device Interface (UNDI)). Its functions or tasks are not described in the PXE specification.
Integration
The PXE Client/Server Protocol was designed so:
- it can be used in the same network as an existing DHCP environment without interference
- it can be integrated completely into standard DHCP services
- it can be easily extended at the most important points without a call for papers
- every service (DHCP, Proxy DHCP, Boot Server) can be implemented standalone or in any combination of them.
Additionally the PXE firmware extension was designed as an Option ROM for the IA-32 BIOS so a personal computer (PC) can be made PXE-capable by installing a NIC that provides a PXE Option ROM. This procedure also applies to the newer AMD64 processor standard for PC.
The design goal of utilizing existing DHCP and TFTP servers cannot be achieved in a strictly conforming implementation. Some aspects of the PXE protocol require that the DHCP and TFTP servers be modified and communicate. One specific example is using multicast, where DHCP packets provide the multicast group information rather than an opening RFC-2090 multicast TFTP exchange. The impact of this is minimal as the most common PXE client implementation (written by Intel and provided at no cost as a linkable IA32 binary module) interoperates with a combination of isolated DHCP and unicast TFTP servers.
http://en.wikipedia.org/wiki/IPXE
iPXE
| It has been suggested that gPXE be merged into this article. (Discuss) Proposed since May 2012. |
| Developer(s) | iPXE project |
|---|---|
| Stable release | 1.0.0+ |
| Written in | C |
| Type | Boot loader |
| License | GPLv2+ |
| Website | ipxe.org |
iPXE (formerly gPXE in 2010,[1] formerly Etherboot) is an open-source Preboot Execution Environment (PXE) implementation and bootloader. It can be used to enable computers without built-in PXE support to boot from the network, or to extend an existing PXE implementation with support for additional protocols. While traditional PXE clients use TFTP to transfer data, iPXE adds the ability to retrieve data through other protocols like HTTP, iSCSI, ATA over Ethernet (AoE), and Fibre Channel over Ethernet (FCoE), and can work with Wi-Fi rather than requiring a wired connection.
PXE implementation[edit]
iPXE can be loaded by a computer in several ways:
- from media like floppy disk, USB flash drive, or hard disk
- as a pseudo Linux kernel
- as an ELF image
- from an option ROM on a network card or embedded in a system BIOS
- over a network as a PXE boot image
iPXE implements its own PXE stack, using a driver corresponding to the network card, or a UNDI driver if it was loaded by PXE itself. This allows you to use a PXE stack even if the network card has no boot ROM, by loading iPXE from a fixed medium.
Bootloader[edit]
Although its basic role was to implement a PXE stack, iPXE can be used as a full-featured network bootloader. It can fetch files from multiple network protocols,[2] such as TFTP, NFS, HTTP[3][4] or FTP, and can boot PXE, ELF, Linux, FreeBSD, multiboot, EFI, and Windows CE images.
In addition, it is scriptable and can load COMBOOT and COM32 SYSLINUX extensions. This allows you, for instance, to build a graphical menu for network boot.
See also[edit]
http://en.wikipedia.org/wiki/SYSLINUX
SYSLINUX
Screenshot of SYSLINUX
| |
| Developer(s) | H. Peter Anvin |
|---|---|
| Stable release | 6.01 / July 4, 2013 |
| Operating system | Linux |
| Type | Boot loader |
| License | GNU General Public Licenseversion 2 or later |
| Website | http://www.syslinux.org/ |
The SYSLINUX Project is a suite of lightweight IBM PC MBR bootloaders for starting up computers with the Linux kernel. It is the work of H. Peter Anvin, and consists of several separate systems, the best-known of which is ISOLINUX.
Contents
[hide]
List[edit]
- The original SYSLINUX, used for booting from FAT and NTFS filesystems (such as floppy disks and USB drives).
- ISOLINUX, used for booting from CD-ROM ISO 9660 filesystems.
- PXELINUX, used for booting from a network server using the Preboot Execution Environment (PXE) system.
- EXTLINUX, used to boot from Linux ext2/ext3/ext4 or btrfs filesystems.
- MEMDISK, used to boot older operating systems like MS-DOS from these media.
- Two separate menu systems.
- A development environment for additional modules.
Use[edit]
SYSLINUX and ISOLINUX[edit]
SYSLINUX is not normally used for booting full Linux installations since Linux is not normally installed on FAT filesystems. Instead, it is often used for boot or rescue floppy discs, Live USBs, or other lightweight boot systems. ISOLINUX is generally used by Linux Live CDs and bootable install CDs.
A minor complication is involved when booting from CD-ROM. The El Torito standard allows for booting in two different modes:
-
Floppy emulation mode
- the boot information is stored in an image file of a FAT-formatted floppy disk, which is loaded from the CD and then behaves as a virtual floppy disk. This mode uses SYSLINUX. No emulation mode
- the boot information is stored directly on the CD (not in a floppy image). This mode uses ISOLINUX.
To have this choice is sometimes useful, since ISOLINUX is vulnerable to BIOS bugs; for that reason, it is handy to be able to boot using SYSLINUX. This mostly affects computers built before about 1999, and, in fact, for modern computers no emulation mode is generally the more reliable method.
The use of SYSLINUX for the creation of Live USBs is growing, though, and allowing the creation of distributions like Slax that allow users to try Linux with complete interactivity and persistent changes without needing to install it on their hard disk.
Newer ISOLINUX versions allow for creation of so-called "hybrid ISO" images, that put both CD el-torito and HDD MBR boot records into an ISO image, which lets users use a single-image as either a CD/DVD boot or USB boot.[1]
PXELINUX[edit]
PXELINUX is used in conjunction with a PXE compliant ROM on a network card. The PXE environment uses DHCP or BOOTP to enable basic TCP/IP networking, then downloads a bootstrap program via TFTP. This bootstrap program loads and configures a kernel according to directives that are also downloaded from the TFTP server.
Typically, PXELINUX is used for Linux installations from a central network server or for booting diskless workstations.
EXTLINUX[edit]
EXTLINUX is typically used as a general-purpose bootloader, similar to LILO or GRUB. Since Syslinux 4, EXTLINUX has been merged with SYSLINUX.
COMBOOT[edit]
SYSLINUX can be extended by COMBOOT modules written in C or assembly language. 32-bit modules typically use file extension .c32. Since version 5 16-bit .commodules are no longer supported.[2]
Hardware Detection Tool (HDT)[edit]
Since the 3.74 release, the Syslinux project hosts the Hardware Detection Tool (HDT) project. This tool is a Syslinux com32 module that displays low-level information for any x86 compatible system. It provides both a command-line interface and a semi-graphical menu mode for browsing. HDT is available as a com32 file, a bootable ISO and a 2.88 MB floppy disk. HDT is registered as a SourceForge project.
The Syslinux Project covers lightweight bootloaders for MS-DOS FAT filesystems (SYSLINUX), network booting (PXELINUX), bootable "El Torito" CD-ROMs (ISOLINUX), and Linux ext2/ext3/ext4 or btrfs filesystems (EXTLINUX). The project also includes MEMDISK, a tool to boot legacy operating systems (such as DOS) from nontraditional media; it is usually used in conjunction with PXELINUX and ISOLINUX.
More info about SYSLINUX, PXELINUX, ISOLINUX, and EXTLINUX can be found on their respective pages; however, since the three have a lot in common, the common documentation is on the SYSLINUX page for now.
How do I Configure SYSLINUX?
All the configurable defaults in SYSLINUX can be changed by creating a file called syslinux.cfg.
syslinux.cfg is a text file in either UNIX or DOS format, containing one or more of the keywords listed below. Keywords are case insensitive. Upper case is used here to indicate a word should be typed verbatim.
Here is a simple example syslinux.cfg file, with one entry to boot a Linux kernel:
DEFAULT linux LABEL linux SAY Now booting the kernel from SYSLINUX... KERNEL vmlinuz.img APPEND ro root=/dev/sda1 initrd=initrd.img
KERNEL file
Selects the file SYSLINUX will boot. The "kernel" doesn't have to be a Linux kernel, it can be a boot sector or a COMBOOT file.
Chain loading requires the boot sector of the foreign operating system to be stored in a file in the root directory of the filesystem. Because neither Linux kernel boot sector images, nor COMBOOT files have reliable magic numbers, Syslinux will look at the file extension. The following extensions are recognized (case insensitive):
none or other Linux kernel image .0 PXE bootstrap program (NBP) [PXELINUX only] .bin "CD boot sector" [ISOLINUX only] .bs Boot sector [SYSLINUX only] .bss Boot sector, DOS superblock will be patched in [SYSLINUX only] .c32 COM32 image (32-bit COMBOOT) .cbt COMBOOT image (not runnable from DOS) .com COMBOOT image (runnable from DOS) .img Disk image [ISOLINUX only]
APPEND options...
Adds one or more options to the kernel command line. These are added to both, automatic and manual boots. The options are added at the very beginning of the kernel command line, usually permitting explicitly entered kernel options to override them.
What is PXELINUX?
PXELINUX is a SYSLINUX derivative, for booting Linux from a network server using a network ROM conforming to the Intel PXE (Pre-Execution Environment) specification. PXELINUX is not a program intended to be flashed or burned into a PROM on the network card. If you want that, check out iPXE ( http://ipxe.org/).
If you want to create PXE-compliant boot PROM for your network card (to use with PXELINUX, for example), check out NetBoot (http://netboot.sourceforge.net/).
How do I Configure PXELINUX?
PXELINUX operates in many ways like SYSLINUX. If you are not familiar with SYSLINUX, read the SYSLINUX FAQ first, since this documentation only explains the differences.
On the TFTP server, create the directory "/tftpboot", and copy pxelinux.0 (from the SYSLINUX distribution) and any kernel or initrd images that you want to boot.
Finally, create the directory "/tftpboot/pxelinux.cfg". The configuration file (equivalent of syslinux.cfg -- see the SYSLINUX FAQ for the options here) will live in this directory. Because more than one system may be booted from the same server, the configuration file name depends on the IP address of the booting machine. PXELINUX will search for its config file on the boot server in the following way:
- First, it will search for the config file using the hardware type (using its ARP type code) and address, all in lower case hexadecimal with dash separators; for example, for an Ethernet (ARP type 1) with address 88:99:AA:BB:CC:DD it would search for the filename 01-88-99-aa-bb-cc-dd.
- Next, it will search for the config file using its own IP address in upper case hexadecimal, e.g. 192.0.2.91 -> C000025B (you can use the included progam gethostip to compute the hexadecimal IP address for any host). If that file is not found, it will remove one hex digit and try again. Ultimately, it will try looking for a file named default (in lower case). As an example, if the boot file name is /mybootdir/pxelinux.0, the Ethernet MAC address is `88:99:AA:BB:CC:DD` and the IP address 192.0.2.91, it will try following files (in that order):
/mybootdir/pxelinux.cfg/01-88-99-aa-bb-cc-dd
/mybootdir/pxelinux.cfg/C000025B
/mybootdir/pxelinux.cfg/C000025
/mybootdir/pxelinux.cfg/C00002
/mybootdir/pxelinux.cfg/C0000
/mybootdir/pxelinux.cfg/C000
/mybootdir/pxelinux.cfg/C00
/mybootdir/pxelinux.cfg/C0
/mybootdir/pxelinux.cfg/C
/mybootdir/pxelinux.cfg/default
Note that all filename references are relative to the directory pxelinux.0 lives in. PXELINUX generally requires that filenames (including any relative path) are 127 characters or shorter in length.
How Should I Setup my TFTP server?
PXELINUX currently requires that the boot server has a TFTP server which supports the "tsize" TFTP option (RFC 1784/RFC 2349).
Also, please do check out the problematic hardware reference page to see if your PXE stacks need any special workarounds.
Some TFTP servers which have been successfully used with PXELINUX include:
- The "tftp-hpa" TFTP server, a highly portable update and port of the BSD TFTP server code is available at:
http://www.kernel.org/pub/software/network/tftp/ or ftp://ftp.kernel.org/pub/software/network/tftp/ .
- Another TFTP server which supports this is atftp by Jean-Pierre Lefebvre:
ftp://ftp.mamalinux.com/pub/atftp/ atftp is likely going to perform better than tftp-hpa on a large boot server, but may not be quite as widely portable. If your boot server runs Windows (and you can't fix that), try tftpd32 by Philippe Jounin: http://tftpd32.jounin.net/
How Should I Setup My DHCP server?
The PXE protocol uses a very complex set of extensions to DHCP or BOOTP. However, most PXE implementations -- this includes all Intel ones version 0.99n and later -- seem to be able to boot in a "conventional" DHCP/TFTP configuration. Assuming you don't have to support any very old or otherwise severely broken clients, this is probably the best configuration unless you already have a PXE boot server on your network.
A sample DHCP setup, using the "conventional TFTP" configuration, would look something like the following, using ISC dhcp (2.0 or later) dhcpd.conf syntax:
allow booting;
allow bootp;
# Standard configuration directives...
option domain-name "domain_name";
option subnet-mask subnet_mask;
option broadcast-address broadcast_address;
option domain-name-servers dns_servers;
option routers default_router;
# Group the PXE bootable hosts together
group {
# PXE-specific configuration directives...
next-server TFTP_server_address;
filename "/tftpboot/pxelinux.0";
# You need an entry like this for every host
# unless you're using dynamic addresses
host hostname {
hardware ethernet ethernet_address;
fixed-address hostname;
}
}
Note that if your particular TFTP daemon runs under chroot (tftp-hpa will do this if you specify the -s (secure) option; this is highly recommended), you almost certainly should not include the /tftpboot prefix in the filename statement.
If this does not work for your configuration, you probably should set up a "PXE boot server" on port 4011 of your TFTP server; a free PXE boot server is available at:http://www.kano.org.uk/projects/pxe/
With such a boot server defined, your DHCP configuration should look the same except for an "option dhcp-class-identifier" (ISC dhcp 2) or "option vendor-class-identifier" (ISC dhcp 3):
allow booting;
allow bootp;
# Standard configuration directives...
option domain-name "domain_name";
option subnet-mask subnet_mask;
option broadcast-address broadcast_address;
option domain-name-servers dns_servers;
option routers default_router;
# Group the PXE bootable hosts together
group {
# PXE-specific configuration directives...
option dhcp-class-identifier "PXEClient";
next-server pxe_boot_server_address;
# You need an entry like this for every host
# unless you're using dynamic addresses
host hostname {
hardware ethernet ethernet_address;
fixed-address hostname;
}
}
Here, the boot file name is obtained from the PXE server.
If the "conventional TFTP" configuration doesn't work on your clients, and setting up a PXE boot server is not an option, you can attempt the following configuration. It has been known to boot some configurations correctly; however, there are no guarantees:
allow booting;
allow bootp;
# Standard configuration directives...
option domain-name "domain_name";
option subnet-mask subnet_mask;
option broadcast-address broadcast_address;
option domain-name-servers dns_servers;
option routers default_router;
# Group the PXE bootable hosts together
group {
# PXE-specific configuration directives...
option dhcp-class-identifier "PXEClient";
option vendor-encapsulated-options 09:0f:80:00:0c:4e:65:74:77:6f:72:6b:20:62:6f:6f:74:0a:07:00:50:72:6f:6d:70:74:06:01:02:08:03:80:00:00:47:04:80:00:00:00:ff;
next-server TFTP_server;
filename "/tftpboot/pxelinux.0";
# You need an entry like this for every host
# unless you're using dynamic addresses
host hostname {
hardware ethernet ethernet_address;
fixed-address hostname;
}
}
Note that this will not boot some clients that will boot with the "conventional TFTP" configuration; Intel Boot Client 3.0 and later are known to fall into this category.
Fetching images via HTTP/FTP
TFTP can be extremely slow, so PXELINUX allows you to fetch data (such as a kernel and initial ramdrive) over http - a technique first pioneered by gPXE its more recent iPXE fork. Older versions of PXELINUX supported this by using a hybrid bootloader that also contained gPXE/iPXE, with such images named either gpxelinux.0 or ipxelinux.0. Since 5.10, PXELINUX has native support for the feature.
To enable http/ftp, you must use lpxelinux.0 in place of pxelinux.0 If you try to use pxelinux.0 (without the l prefix) then you'll get a "file not found" warning without any explanation as to the cause!
There's also a bug in the feature that can cause an "netconn_write failed: -5" error. This was fixed in the 6.02 release.
Many advanced options here. Read full documentation on Syslinux to understand it all.
Its password protected from modification during PXE boot, very useful to prevent tampering.
Note: this example uses the legacy way to generate submenus, which is compatible with older SYSLINUX versions. SYSLINUX 3.62 supports a slightly different syntax, which is faster and somewhat more flexible.
Directory Structure:
/tftpboot/
/tftpboot/memdisk
/tftpboot/pxelinux.0
/tftpboot/menu.c32
/tftpboot/pxelinux.cfg/
/tftpboot/pxelinux.cfg/default
/tftpboot/pxelinux.cfg/graphics.conf
/tftpboot/pxelinux.cfg/fixes.menu
/tftpboot/pxelinux.cfg/setup.menu
/tftpboot/TRK/
/tftpboot/TRK/chkdsk.trk
/tftpboot/TRK/initrd.trk
/tftpboot/TRK/kernel.trk
/tftpboot/Memtest/memtest.x86
/tftpboot/Suse/
/tftpboot/Suse/initrd92
/tftpboot/Suse/linux92
/tftpboot/Floppy/
/tftpboot/Floppy/kbfloppy.img
/tftpboot/pxelinux.cfg/default
default menu.c32
prompt 0
menu title PXE Special Boot Menu
menu INCLUDE pxelinux.cfg/graphics.conf
MENU AUTOBOOT Starting Local System in # seconds
label bootlocal
menu label ^Boot Point of Sale
menu default
localboot 0
timeout 80
TOTALTIMEOUT 9000
LABEL Fixes Menu
MENU LABEL ^Fixes Menu
KERNEL menu.c32
APPEND pxelinux.cfg/graphics.conf pxelinux.cfg/fixes.menu
LABEL Setup Menu
MENU LABEL ^Setup Menu
KERNEL menu.c32
APPEND pxelinux.cfg/graphics.conf pxelinux.cfg/setup.menu
/tftpboot/pxelinux.cfg/graphics.conf
menu color tabmsg 37;40 #80ffffff #00000000
menu color hotsel 30;47 #40000000 #20ffffff
menu color sel 30;47 #40000000 #20ffffff
menu color scrollbar 30;47 #40000000 #20ffffff
MENU MASTER PASSWD yourpassword
MENU WIDTH 80
MENU MARGIN 22
MENU PASSWORDMARGIN 26
MENU ROWS 6
MENU TABMSGROW 15
MENU CMDLINEROW 15
MENU ENDROW 24
MENU PASSWORDROW 12
MENU TIMEOUTROW 13
MENU VSHIFT 6
MENU PASSPROMPT Enter Password:
NOESCAPE 1
ALLOWOPTIONS 0
Set ALLOWOPTIONS to 1 if you want to be able to edit any of the entries while booted with PXE on the menu system. If you might want that for testing but once its final I like it set to 0. Also set NOESCAPE to 0 for the same reasons.
/tftpboot/pxelinux.cfg/fixes.menu
MENU TITLE Fixes Menu
LABEL Main Menu
MENU LABEL ^Return to Main Menu
KERNEL menu.c32
APPEND pxelinux.cfg/default
label fsck
menu label ^File system check
kernel TRK/kernel.trk
append initrd=TRK/chkdsk.trk ramdisk_size=32768 root=/dev/ram0 vga=0
label memtest
menu label ^Memory Test: Memtest86+ v1.65
kernel Memtest/memtest.x86
label trk3
menu label ^Trinity Rescue Kit
kernel TRK/kernel.trk
append initrd=TRK/initrd.trk ramdisk_size=32768 root=/dev/ram0 vga=0 trknfs=IPADDR:/trk ip=::::::dhcp splash=verbose
/tftpboot/pxelinux.cfg/setup.menu
MENU TITLE Setup Menu
LABEL Main Menu
MENU LABEL ^Return to Main Menu
KERNEL menu.c32
APPEND pxelinux.cfg/default
label setupkb
menu label ^Any floppy disk image
kernel memdisk
append initrd=Floppy/kbfloppy.img
label linux
MENU PASSWD yourpassword
menu label Install - ^Classic
kernel Suse/linux92
append initrd=Suse/initrd92 ramdisk_size=65536 vga=0 textmode=1 install=http://IPADDR serverdir=/9.2/install
autoyast=http://IPADDR/9.2/scripts/ay92.xml
label trkclone
MENU PASSWD yourpassword
menu label Install - ^Faster
kernel TRK/kernel.trk
append initrd=TRK/initrd.trk ramdisk_size=65536 root=/dev/ram0 vga=0 install=Y trknfs=IPADDR:/trk
ip=::::::dhcp splash=verbose
label linuxfull
MENU PASSWD yourpassword
menu label Install - ^Developer
kernel Suse/linux92
append initrd=Suse/initrd92 ramdisk_size=65536 vga=0 textmode=1 install=http://IPADDR serverdir=/9.2/install
autoyast=http://IPADDR/9.2/scripts/develdesktop.xml
2710
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
