What is pxe boot in linux

Preboot Execution Environment

The Preboot eXecution Environment (PXE, most often pronounced as pixie) specification describes a standardized client-server environment that 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 DHCP and TFTP.

In this guide, PXE is used to boot the installation media with an appropriate option-rom that supports PXE on the target. This works well when you already have a server set up.

Contents

Preparation

Overview

It is useful to give an overview of the PXE boot process in order to understand the #Server setup, the #Installation on the client side and the Arch Linux files needed.

The client starts by broadcasting packets asking for a DHCP server and containing specific PXE options. The DHCP server responds with networking information (the IP address assigned to the client) and also provides, by using specific bootstrap protocol (BOOTP) parameters of the DHCP, additional information like the TFTP server address, the path of the initial network bootstrap program (NBP) to download or the boot configuration file name.

The NBP is transferred from the PXE server to the client using TFTP, to be loaded into memory and executed. The kernel and the initramfs are also transferred this way.

Then the root filesystem is transferred using one of the following protocols: HTTP, NFS or NBD.

Boot from install media

In order to gather the files that will be transferred from the server to the client for booting, get the latest official install media from the download page.

Next mount the image:

where release_date is the release date in the ISO filename like, e.g., 2020.10.01 .

Boot from netboot

Arch Linux netboot images can be used to download the latest Arch Linux release on the fly upon system boot. Download the image compatible with your configuration.

Pixiecore

A all-in-one solution is provided by pixiecore

1. Install pixiecore-gitAUR
2. Run pixiecore quick arch —dhcp-no-bind as root
3. Boot via PXE

Server setup

You will need to setup a DHCP server, a TFTP server for transferring the NBP and one of the following services for transferring the root filesystem: HTTP server, NFS or NBD.

Network

Bring up your wired network adapter, and assign it an address appropriately.

DHCP + TFTP

You will need both a DHCP server and a TFTP server to configure networking on the install target and to facilitate the transfer of files between the server and the client. dnsmasq does both, and is extremely easy to set up.

dnsmasq needs to be configured. See instructions on how to setup a dnsmasq#TFTP server and a dnsmasq#PXE server.

Are provided below some common configuration instructions. tftp_root is the directory where the Arch ISO is mounted (e.g. /mnt/archiso ) or where the network boot program is located.

To enable the DHCP server and give IPv4 addresses within a range, add to the configuration file a line similar to:

Or in case there is already a DHCP-server running on the network and you want to interoperate with it, see dnsmasq#Proxy DHCP.

Two examples covering different boot style and installation media are provided below.

Once configured according to your needs, start dnsmasq.service .

BIOS boot from install media

The path of the initial bootstrap program to be transferred is defined with the dhcp-boot option in the configuration file.

In order to send specific bootstrap protocol (BOOTP) parameters, like the configuration file path, the dhcp-option-force=flag,value line is used.

UEFI boot from netboot

To send a file depending on the architecture, here the netboot image for UEFI-style boot, use:

If using netboot, the rest of the server setup section which focuses on the Arch ISO does not apply.

Transferring archiso root filesystem

Thanks to archiso_pxe_http , archiso_pxe_nfs and archiso_pxe_nbd initcpio hooks in archiso, it is possible to boot using HTTP, NFS or NBD. Boot time is approximately the same in all three methods, but HTTP method allows you to watch a state of downloading airootfs.sfs in percents.

Among all alternatives, darkhttpd is by far the most trivial to setup (and the lightest-weight).

Then start darkhttpd using our /mnt/archiso as the document root:

You will need to set up an NFS server with an export at the root of your mounted installation media, which would be /mnt/archiso if you followed #Preparation. After setting up the server, add the following line to your /etc/exports file:

If the server was already running, re-export the filesystems with exportfs -r -a -v .

The default settings in the installer expect to find the NFS at /run/archiso/bootmnt , so you will need to edit the boot options. To do this, press Tab on the appropriate boot menu choice and edit the archiso_nfs_srv option accordingly:

Alternatively, you can use /run/archiso/bootmnt for the entire process.

After the kernel loads, the Arch bootstrap image will copy the root filesystem via NFS to the booting host. This can take a little while. Once this completes, you should have a running system.

Install the nbd package and configure it:

where release_date is the release date in the ISO filename like, e.g., 2020.03.01 .

Existing PXE server

If you have an existing PXE server with a PXELINUX system setup (e.g. a combination of DHCP and TFTP), you can add the following menu items to your /tftpboot/pxelinux.cfg/default file in order to boot Arch via your preferred method:

You can replace archiso_http_srv with archiso_nfs_srv for NFS or archiso_nbd_srv for NBD (see usage examples in arch/boot/syslinux/archiso_pxe.cfg file resided on ArchLinux iso). Whichever method you choose, you must pass ip= parameter to instruct the kernel to bring up the network interface before it attempts to mount the installation medium over the network. Passing BOOTIF= is required when there are several wired interfaces on the client side and/or you want resolv.conf to be already configured inside booted archiso. You can use sysappend mask 3 (which is 1+2) to pass these parameters automatically. For available boot parameters see README.bootparams.

Installation

For this portion you will need to figure out how to tell the client to attempt a PXE boot; in the corner of the screen along with the normal post messages, usually there will be some hint on which key to press to try PXE booting first. On an IBM x3650 F12 brings up a boot menu, the first option of which is Network; on a Dell PE 1950/2950 pressing F12 initiates PXE booting directly.

Looking at journald on the PXE server will provide some additional insight to what exactly is going on during the early stages of the PXE boot process:

After you load pxelinux.0 and archiso.cfg via TFTP, you will (hopefully) be presented with a syslinux boot menu with several options, where you can select Boot Arch Linux (x86_64) (HTTP).

Next the kernel and initramfs (appropriate for the architecture you selected) will be transferred, again via TFTP:

If all goes well, you should then see activity on darkhttpd coming from the PXE-target; at this point the kernel would be loaded on the PXE-target, and in init:

After the root filesystem is downloaded via HTTP, you will eventually end up at the normal live system root zsh prompt.

Post-boot

Unless you want all traffic to be routed through your PXE server (which will not work anyway unless you set it up properly), you will want to stop dnsmasq.service and get a new lease on the install target, as appropriate for your network layout.

You can also kill darkhttpd; the target has already downloaded the root filesystem, so it is no longer needed. While you are at it, you can also unmount the installation image:

At this point you can follow the Installation guide.

Low memory systems

The copytoram initramfs option can be used to control whether the root filesystem should be copied to ram in its entirety in early-boot.

It highly recommended to leave this option alone, and should only be disabled if entirely necessary (systems with less than

256MB physical memory). Append copytoram=n to your kernel line if you wish to do so.

Sharing internet with PXE clients

If your network for PXE clients is private (for example, 192.168.1.0/24), and you want them to be able to access internet (for example, for packages installation), you should configure masquerade/source nat properly. Your PXE server must have a separate NIC connected to the internet. You can use such command to pass through the internet to clients:

To make this rule persistent after reboot, run the following command:

Troubleshooting

DHCP interface rename bug

FS#36749 causes default predictable network interface renaming to fail and then DHCP client to fail because of it. A workaround is to add the kernel boot parameter net.ifnames=0 to disable predictable interface names.

VirtualBox cannot boot while real machines can

When using VirtualBox to test your configuration, the virtual machine may get stuck at:

While PXE booting with a real machine works fine. The problem may be because you have set several CPU cores to your client machine, and you set its type as Other and version as Other/Unknown (64 bit). So VirtualBox does not know which paravirtualization interface to use by default.

Adding loglevel=7 to the kernel parameters lets you see where it actually got stuck:

To resolve this, either use one CPU core, or go to Machine > Settings > System > Acceleration and set one of the following paravirtualization interface: Minimal, Hyper-V or KVM.

Источник

Linuxhit

Linux, networking, hardware and more

PXE Boot, What is PXE? How does it work?

PXE Boot – Introduction

What can you expect to learn about PXE from this post?

• High level overview of PXE boot process.
• Use cases for PXE boot.
• Detailed end to end overview of the PXE boot process.
• Technical details of each stage.

What is PXE?

In this post we are deep diving into PXE boot. PXE stands for preboot execution environment. It is standards base and can be implemented using open source software or vendor supported products. PXE is a key part of data center infrastructure because it enables automated provisioning of servers or work stations over a network. An in depth understanding of the PXE stack benefits anyone working on infrastructure deployment of bare metal servers, embedded devices and IOT devices.

Authors background

I first implemented a PXE boot environment in a production data center 15 years ago. Installing operating systems from CDROM was painfully slow and we desired an automated solution. The knowledge I gained from that project increased in value through out my career. Since then I have worked with PXE in large scale deployments provisioning thousands and thousands of hosts in data centers across the globe. I am excited to share what I have learned through years of hands on experience.

Why did I write this guide?

PXE is often seems like a dark art. Typically only a handful of people in the team truly know how the environment’s PXE infrastructure boot works. Additionally debugging it is hard, debugging remotely even harder. Therefore, I wrote this guide to help demystify PXE boot by explaining it a simple, thorough and interesting fashion.

High level overview of PXE boot

PXE Use Case, What problem does it solve?

PXE solves a problem large enterprises face. How do you automate provisioning or installation of operating systems on large quantities of machines?

Operating system such as Windows or Linux have mechanisms to automate installation. Typically you create a seed file or configuration. The seed file provides answers to the questions asked by the OS installer. In the linux world examples of this are debian preseed files or Redhat kickstart files. But still you need access to the installation media on CD/DVD-ROM or a USB drive. A human running around with the usb drive touching every server does not scale. Its time consuming and error prone. Lets imagine a world where a human puts a server in the rack, powers it on and is done. This has many benefits:

• Installers can be less technical.
• Reduced time spent per server.
• Less error prone due to automation.
• OS installation tools are centralized and easier to update.

This is where PXE comes in. PXE is a standards based approached to solving the problem of getting the OS onto the system without a human being putting media (USB, CD/DVD-ROM) in the system. It does this by bootstrapping the machine over the network.

In a fully automated environment the human installing the server does the following:

• Installs server in the rack.
• Connects power and network.
• Walks away.

The powered on server automatically fetches a network boot file (NBF) to boot itself up and provisions an operating system. It is a beautiful thing when its working properly 🙂

How does it work?

It all starts with the NIC

The start of a PXE workflow is booting network interface card (NIC). In a typical PC or laptop the NIC will not do anything until the operating system boots and loads the proper driver. However network booting requires a PXE enabled NIC. The NIC contains firmware with a tiny network stack. This firmware is capable of connecting to the network and fetching a file to boot, commonly referred to as the network boot file (NBF). The file could be a kernel or it could be network enabled boot loader.

The server boots the file downloaded off the network. Typically the boot image kicks off an automated installation of an operating system. Now lets dive into the components that make this process possible.

PXE boot components

A typical PXE environment has the following components.

PXE enabled NICs

Not all NICs are equal. Many consumer grade network cards do not have a PXE capabilities. Although that is rapidly changing as advances make it easier to include more features in cheaper devices. PXE enabled NICs are the defacto standard in data center grade servers. We suggest you double check before you buy. However I would be surprised if any major server manufacturer ships a NIC without PXE capability these days.

Some of the PXE enabled NICs even use open source PXE firmware. IPXE is an open source firmware often installed on data center NICs.

DHCP Server

DHCP stands for Dynamic Host Configuration Protocol. There are two types of actors in DHCP. The DHCP server and the DHCP client.

A DHCP server provides a network configuration to clients. Specifically, DHCP provides an IP network configuration to a client. A DHCP client runs on computers that join the network and need a configuration.

An example of real world DHCP use you are probably familiar with is connecting to your office LAN. Your laptop has no idea what IP addresses are in use on the network it has joined. The DHCP client on your laptop sends a broadcast to the network indicating it is looking for a DHCP server. A response is sent from the the server to announce its availability. Your client acknowledges this by sending a request for a DHCP lease. The DHCP server sees this request and finds an unused IP address. Your laptop gets a DHCP lease offer from the server. The lease offer among other things includes the IP address you will use. Your laptop’s DHCP client accepts the offer and begins using the IP address to talk to on the network. As lease expiration time approaches your laptop will ask to renew.

In a PXE boot environment there is always a DHCP server. The machines that are being provisioned are DHCP clients. The PXE enabled NIC has a DHCP client built into its firmware.

DHCP supports a wide range of options that can be provided to network clients. But typically it consists of an IP address for use by the client, a default gateway address and DNS servers to use for name resolution. In the case of PXE, an option that contains the IP address of the server to download its boot files from.

TFTP Server

TFTP stands for trivial file transfer protocol. It is a simple UDP based protocol for getting or sending a file. It’s simplicity lends well to being implemented in firmware environments where resources are limited. Due to its simple nature TFTP has no bells or whistles. Getting and putting files are supported, that’s it. There is no directory listing, you must know the exact path of the file you want to download. Additionally there is no authentication or authorization.

While TFTP is still commonly used in PXE environments, advances is in technology has resulted in some PXE implementations supporting more complex protocols like HTTP or ISCSI. For example the IPXE firmware supports:

• HTTP
• ISCSI Storage Area Networks (SAN)
• Fiber channel over ethernet (FCOE) Storage Area Networks (SAN)
• ATA over etherent (AOE)

Putting it all together

The above diagram illustrates a basic PXE workflow. Lets review each of the steps.

PXE DHCP Steps

• Client PXE enabled NIC powers on and boots firmware.
• Firmware’s DHCP client sends a broadcast packet to the local area network indicating it needs a network configuration from the DHCP server.
• The DHCP server responds with what is called an “offer”. The offer contains the network configuration as specified by the DHCP protocol specification.
• The DHCP client, happy with the result now sends a DHCP request. This request basically means “I got the offer, I want to confirm before moving forward”.
• The DHCP server then responds with a unicast packet directed at the assigned IP address. Note that up until this point all packets have been broadcast.
• The DHCP client gets the response and starts using the network configuration.

PXE TFTP Steps

At this point the NIC firmware in the PXE client has an IP configuration. Part of that configuration should have been what is referred to “next-server” option. The next-server option is a DHCP option that tells the client where it should go to download the network boot file.

• NIC firmware makes a TFTP request to the server using the IP or name specified in the next-server option of the DHCP lease.
• TFTP server sends the requested file in a udp data stream.
• NIC firmware receives the file storing it in memory.
• Server then executes the downloaded file.

Next steps after TFTP

What happens at this point will vary depending on the environment and goal of the PXE boot configuration. Some examples are OS installation or full network boot.

OS Installation Use Case

The system boots up an automated OS installer image that installs an OS to the local drive. After the installation a reboot is performed to reboot into the local OS.

Full Network Boot Use Case

In this use case the server boots entirely over the network on every boot. Typically the root file system is mounted via NFS. Pros of this configuration are the servers can run with no local storage. Cons are that the network needs to be functional to boot the server and performance may not be as good as local storage.

Variations

The PXE environment we just described is a simple and common configuration. It is a good starting point for newcomers trying to understand PXE for the first time.

Here are some variations you will see in the real world. Especially in enterprises.

• DHCP relay or “helper”. The relay forwards DHCP request to a DHCP server not on the local LAN. This functionality is common on enterprise routers.
• PXE proxy or relay. This is often used when one does not have the access required to modify the DHCP server configuration. In this case the relay responds to the DHCP request with just the server and filename of the network boot file. Letting the existing DHCP server provide the standard IP configuration.
• HTTP or HTTPS instead of TFTP for retrieval for the network boot file.

Conclusion

In conclusion PXE is a very powerful tool for automating and managing the provisioning and updates of data center infrastructure, embedded devices, IOT devices and even workstations. We have covered the basics and hope you walk away from this article with a better understanding.

Related articles on Linuxhit.com

Appendix & further reading

• PXE Specification
• TFTP protocol specification RFC 1350
• DHCP protocol specification RFC 2131
• IPXE

Feedback

We appreciate feedback. If you have ideas on how we can make this article or site better please leave a comment.

Источник