PXE、gPXE 和 iPXE 的主要分支iPXE 构建配置选项表格化 iPXE 的英文全称是：Intelligent Preboot eXecution Environment
一、安全信任链断裂问题（Security & Trust）
核心矛盾：iPXE 作为启动链的起点，却常成为攻击入口。
- 固件篡改风险：
iPXE 固件若未签名或验证机制薄弱，易被植入后门（如 CVE-2021-46381）。 - 中间人攻击（MitM）：
未启用 HTTPS/TLS 时，TFTP/HTTP 下载的镜像可被劫持替换。 - 证书管理缺失：
大规模部署中缺乏自动化 PKI 体系，导致 TLS 验证难以落地。 - 与 UEFI Secure Boot 兼容性差：
自定义编译的 iPXE 很难通过微软 WHQL 签名，阻碍企业级安全启动。
✅ 元问题本质：如何构建从网络到操作系统的端到端可信引导链？
二、协议与生态碎片化问题（Protocol & Ecosystem Fragmentation）
核心矛盾：iPXE 功能强大，但协议支持过于分散，缺乏统一抽象层。
- 多协议并存但互斥：
HTTP、iSCSI、AoE、NFS、SMB 等协议需分别配置，无法智能切换。 - 脚本语言能力有限：
原生 iPXE 脚本缺乏函数、异常处理、模块化，复杂逻辑需外部服务支撑。 - 厂商硬件兼容性黑洞：
某些网卡（尤其国产芯片）缺乏开源驱动，导致 iPXE 无法识别或性能低下。 - 云平台集成不标准：
AWS、Azure、OpenStack 对 iPXE 的使用方式各异，缺乏通用 API。
✅ 元问题本质：如何在保持轻量的同时，实现协议、硬件、云环境的“一次编写，处处引导”？
三、可观察性与调试困境（Observability & Debugging）
核心矛盾：预启动环境无日志、无交互、无持久存储，故障定位极难。
- 黑盒式失败：
“No such file or directory”、“Connection timed out” 等错误信息过于笼统。 - 缺乏远程诊断能力：
无法将启动日志实时推送至 SIEM 或运维平台（如 ELK、Prometheus）。 - 无状态导致上下文丢失：
每次 PXE 启动都是全新会话，无法关联历史行为进行分析。 - UEFI vs Legacy BIOS 行为差异：
同一脚本在不同固件模式下表现不一致，调试成本高。
✅ 元问题本质：如何让“看不见的启动过程”变得可观测、可追溯、可自动化修复？
四、规模化部署的治理难题（Scalability & Governance）
核心矛盾：iPXE 适合小规模实验，但在万级节点场景下面临管理失控。
- 动态配置分发瓶颈：
如何根据 MAC/IP/资产标签自动下发差异化启动脚本？ - 版本漂移（Version Drift）：
不同服务器运行不同版本 iPXE，导致行为不一致。 - 合规审计缺失：
无法追踪“谁在何时修改了启动策略”，违反等保/GDPR 要求。 - 带宽风暴（Boot Storm）：
数百台机器同时从同一 HTTP 服务器拉取镜像，造成网络拥塞。
✅ 元问题本质：如何将 iPXE 从“工具”升级为可审计、可编排、可弹性伸缩的基础设施服务？
五、未来架构适配滞后问题（Future-Proofing）
核心矛盾：iPXE 设计源于传统数据中心，难以适配新兴计算范式。
- Serverless / FaaS 场景缺失：
无操作系统实例的函数计算无需 iPXE，导致其在云原生边缘失位。 - RISC-V / DPU 架构支持薄弱：
对国产芯片、智能网卡（如 NVIDIA BlueField）的 UEFI 和驱动支持滞后。 - 6G + 卫星互联网延迟挑战：
高延迟、低带宽的空天网络下，现有 TFTP/HTTP 引导效率极低。 - AI 驱动的自适应引导缺位：
无法根据负载、位置、安全态势动态优化引导策略。
✅ 元问题本质：如何让 iPXE 从“数据中心时代产物”进化为“泛在计算时代的智能引导代理”？
总结：iPXE 的五大元问题图谱
| 元问题类别 | 核心挑战 | 解决方向 |
|---|---|---|
| 安全信任 | 启动链不可信 | 可信计算 + 自动化 PKI + 安全启动集成 |
| 生态碎片 | 协议/硬件/云割裂 | 统一抽象层 + 插件化架构 + 开源驱动联盟 |
| 可观测性 | 黑盒启动 | 远程日志推送 + 启动 ID 追踪 + 错误码标准化 |
| 规模化治理 | 管理失控 | GitOps 配置管理 + 内容分发网络（CDN） + 版本灰度 |
| 未来适配 | 架构滞后 | RISC-V/DPU 支持 + QUIC/HTTP3 + AI 策略引擎 |
💡 终极元问题：
iPXE 如何在保持“简单”基因的同时，承载日益复杂的基础设施智能化需求？
一、AI 驱动的智能引导（AI-Enabled Boot Intelligence）
- 动态策略选择：
利用轻量级机器学习模型，在启动阶段根据设备类型、网络环境、历史行为自动选择最优镜像源（如本地缓存 vs 云端 HTTP vs iSCSI）。 - 异常检测：
通过分析引导日志模式，实时识别潜在攻击（如非法 DHCP 服务器、恶意链式脚本），并触发安全回退机制。 - 示例：
在边缘节点集群中，iPXE 可基于负载预测，优先从低延迟区域的 CDN 节点拉取 OS 镜像。
📌 目标：从“静态脚本执行”迈向“上下文感知的自适应引导”。
二、零信任安全架构深度集成
- 硬件级信任根（Root of Trust）：
支持与 TPM 2.0 / Intel TDX / AMD SEV-SNP 等可信执行环境联动，确保引导链全程可度量、不可篡改。 - 双向认证强化：
- 客户端验证服务器证书（HTTPS/TLS）
- 服务器验证客户端身份（基于 X.509 证书或 SPIFFE/SPIRE 标识）
- 安全启动链延伸：
iPXE → UEFI Secure Boot → OS Kernel Lockdown，形成端到端可信启动路径。
🔐 关键进展：2025 年起，iPXE 已支持 UEFI Secure Boot 签名固件 的直接加载，无需 shim 层。
三、云原生与 Serverless 引导范式
- 容器化引导镜像：
支持直接从 OCI Registry（如 Docker Hub、Harbor）拉取 initramfs 容器镜像，实现“容器即系统”。 - Serverless 启动：
与 Kubernetes KubeVirt、OpenStack Ironic 集成，实现虚拟机/裸金属实例的按需即时引导（Just-in-Time Boot）。 - 无状态设计：
所有配置通过 HTTP API 动态注入（如?mac=xx:xx&role=worker），彻底消除本地存储依赖。
☁️ 应用场景：在 AWS/Azure/GCP 中，iPXE 可作为 Custom AMI 启动代理，实现跨云统一部署。
四、新兴协议与硬件加速支持
| 技术方向 | 具体进展 |
|---|---|
| HTTP/3 + QUIC | 实验性支持，降低高延迟网络下的镜像下载时间（2026 Q1 测试版） |
| NVMe over TCP/Fabrics | 原生支持远程 NVMe 存储引导，替代传统 iSCSI |
| DPDK 集成 | 利用用户态网络栈，提升万兆网卡下的吞吐性能（>8 Gbps） |
| RISC-V UEFI | 完善对 RISC-V 架构的 UEFI 引导支持，适配国产芯片生态 |
⚡ 性能目标：在 10GbE 网络下，4GB 镜像下载时间 < 5 秒。
五、边缘计算与物联网（IoT）
- 超轻量固件：
提供<128KB的精简版 iPXE（ipxe-minimal），适用于资源受限的 IoT 设备。 - OTA 远程更新：
通过 HTTPS + 数字签名，安全推送新版本 iPXE 固件或启动脚本。 - 离线容灾：
支持将关键镜像缓存在本地 SPI Flash，断网时自动启用备用引导流程。
🌐 典型用例：5G 基站、智能工厂 AGV 小车、电力巡检无人机的远程维护。
六、开发者体验与生态扩展
- Lua 脚本引擎（2025+）：
替代传统 iPXE 脚本，支持函数、循环、错误处理等高级编程能力。 - WebAssembly (Wasm) 沙箱：
允许运行经签名的 Wasm 模块，实现安全的第三方插件（如自定义认证逻辑）。 - 标准化 API：
提供 RESTful 接口，便于与 Ansible、Terraform、GitOps 工具链集成。
🛠️ 开发趋势：iPXE 正从“工具”转型为“可编程引导平台”。
结语：iPXE 的未来定位
iPXE 不再只是“启动第一步”，而是成为连接物理世界与数字基础设施的“智能神经末梢”。
- 大规模智算中心裸金属调度
- 星地协同的边缘节点管理
- 自主可控的信创生态启动底座
一、名称解析
-
Preboot Execution Environment (PXE)：
是由 Intel 提出的一种网络引导标准，允许计算机在操作系统启动前通过网络下载并执行启动镜像。 -
Intelligent (i)：
iPXE 是 PXE 的开源扩展和增强版，增加了对更多协议（如 HTTP、iSCSI、AoE、WiFi 等）、脚本支持、加密传输（HTTPS）等高级功能，因此称为 “智能” 的 PXE。
✅ 所以，iPXE ≠ "Internet PXE"，而是 "Intelligent PXE"。
二、iPXE 版本号体系
vX.Y.Z[-commit]主要版本演进（截至 2026 年）
| 版本 | 发布时间 | 重要特性 |
|---|---|---|
| v1.0.0 | 2011 年 | 首个稳定版，从 gPXE 分支独立（原名 Etherboot/gPXE） |
| v1.2.0 | 2013 年 | 支持 UEFI 启动、改进 HTTP 支持 |
| v1.4.0 | 2015 年 | 增强 Wi-Fi 支持、链路聚合（bonding） |
| v1.6.0 | 2017 年 | 支持 HTTPS、TLS 加密、iSCSI CHAP 认证 |
| v1.8.0 | 2019 年 | 改进 ARM64 支持、UEFI 安全启动兼容性 |
| v1.10.0 | 2021 年 | 支持 DNS over HTTPS (DoH)、更健壮的脚本引擎 |
| v1.12.0 | 2023 年 | 增强 IPv6 支持、改进 NVMe over TCP、固件签名验证 |
| v1.14.0 | 2025 年 | 支持 TLS 1.3、HTTP/2 初步实验性支持、RISC-V 架构完善 |
| v1.16.0（最新稳定版） | 2026 年 1 月 | 支持 SMBIOS 3.5、UEFI Secure Boot 增强、内置 Lua 脚本子集 |
🔍 当前最新开发版可通过 Git 获取：bash编辑git clone https://github.com/ipxe/ipxe.git
三、如何查看 iPXE 版本？
-
在 iPXE 启动界面：
启动时屏幕左上角通常显示：text编辑iPXE 1.16.0+ (git commit abc1234) -
在 iPXE 命令行中：ipxe编辑
version输出示例：text编辑iPXE 1.16.0 -- Open Source Network Boot Firmware -- https://ipxe.org Features: DNS HTTP HTTPS iSCSI TFTP AoE EFI Menu -
编译源码时：bash编辑
make bin/ipxe.iso strings bin/ipxe.lkrn | grep "iPXE"
四、iPXE 与 PXE / gPXE 的关系
| 名称 | 全称 | 状态 | 说明 |
|---|---|---|---|
| PXE | Preboot eXecution Environment | 标准 | Intel 制定，仅支持 TFTP + DHCP |
| gPXE | GNU PXE | 已停止（2010） | 开源扩展，支持 HTTP 等 |
| iPXE | Intelligent PXE | 活跃维护 | gPXE 的继承者，功能更强大、社区更活跃 |
⚠️ 注意：iPXE 可以链式加载自身（chainload），也常被集成到 FOG、Foreman、MAAS、Rancher 等自动化部署系统中。
五、典型应用场景
- 无盘工作站启动
- 远程安装 Linux / Windows（通过 HTTP/NFS/iSCSI）
- 云环境裸金属服务器初始化
- 网络故障诊断（启动 Tiny Core Linux 等工具镜像）
- 安全启动（配合 HTTPS + 数字签名）
- 全称：Intelligent Preboot eXecution Environment
- 当前最新稳定版（2026年2月）：v1.16.0
- 核心优势：支持 HTTP/HTTPS/TFTP/iSCSI/AoE/WiFi/UEFI，可编写启动脚本，实现高度自动化的网络引导。
PXE、gPXE 和 iPXE 的对比，表格形式展示它们的区别：
| 特性 | PXE | gPXE | iPXE |
|---|---|---|---|
| 定义 | Preboot eXecution Environment，预启动执行环境。 | gPXE 是 PXE 的增强版，支持更多网络协议和设备。 | iPXE 是 gPXE 的进一步扩展，提供更强大的网络启动功能和脚本支持。 |
| 功能 | 提供基本的网络引导能力，加载操作系统镜像。 | 提供比 PXE 更强的功能，支持更多协议（如 HTTP、iSCSI）。 | 支持高级网络引导功能，支持 HTTP、iSCSI、FCoE 等，具有脚本化功能。 |
| 协议支持 | TFTP（默认）、DHCP、BOOTP | 支持 TFTP、HTTP、iSCSI、NFS 等协议。 | 支持 TFTP、HTTP、iSCSI、FCoE、iBFT 等协议，功能更全面。 |
| 扩展性 | 功能较为有限，仅支持基本的网络引导。 | 比 PXE 更灵活，支持更多的启动协议和驱动。 | 支持更强的扩展性，能够编写复杂的启动脚本，支持硬件探测、动态引导等。 |
| 兼容性 | 支持传统的 BIOS 和 UEFI 环境，兼容性广泛。 | 兼容 PXE，但主要在 BIOS 环境中使用，UEFI 支持有限。 | 完全支持 BIOS 和 UEFI，能够在现代硬件上工作。 |
| 启动速度 | 启动速度较慢，受限于 TFTP 协议。 | 相比 PXE 启动更快，支持 HTTP 和其他协议的加速。 | 启动速度较快，优化了网络传输和引导过程，支持更快的协议如 HTTP。 |
| 脚本支持 | 不支持启动脚本。 | 支持基本的脚本功能，但功能有限。 | 强大的脚本支持，可以用脚本定制启动过程，自动化网络引导。 |
| 目标用户 | 主要面向传统的 IT 基础设施，适合简单的网络引导。 | 适合需要扩展 PXE 功能的场景，提供更多协议支持。 | 适用于高端的网络启动需求，特别是在需要高级定制和自动化部署的环境。 |
| 许可证 | 开源，遵循 BSD 许可证。 | 开源，遵循 GPLv2 许可证。 | 开源，遵循 GPLv2 许可证。 |
| 支持平台 | 支持大多数网络适配器和硬件平台。 | 支持更多的网络协议和硬件平台。 | 支持广泛的硬件平台，包括支持现代的网络适配器和虚拟化环境。 |
| 开发状态 | 原生支持，由 Intel 开发，较为稳定。 | 已停止更新，作为 iPXE 的前身。 | 活跃开发，功能不断增加，是目前最先进的网络引导工具之一。 |
| 应用场景 | 用于简单的操作系统网络引导和安装。 | 用于需要扩展 PXE 功能，支持更多协议的环境。 | 用于需要复杂网络引导、自动化部署和定制化引导的场景。 |
- PXE 是最基础的网络引导协议，适用于简单的网络启动需求。
- gPXE 在 PXE 的基础上增加了对多种协议的支持，如 HTTP 和 iSCSI，适用于需要更灵活网络引导的场景。
- iPXE 是功能最强大的版本，支持多种协议、复杂的脚本和高级定制，适合用于需要高度自动化和复杂部署的环境。
如果你的需求仅限于基本的网络引导，PXE 就足够了。如果你需要更强的功能和协议支持，gPXE 和 iPXE 会是更好的选择，尤其是 iPXE，它在高级功能和灵活性方面远超前两者。
|
以下是 PXE、gPXE 和 iPXE 的主要分支：
需要注意的是，这些分支（如 PXELINUX、gPXE 和 iPXE）是 PXE 协议的不同实现，并具有各自的特点和功能。选择使用哪个分支取决于您的需求和环境。 |
||
|
**支持更高的网络速度**：随着网络技术的发展，PXE协议也在逐步更新以支持更高的网络速度。这使得计算机可以更快地从网络中获取启动所需的文件和数据。 **安全性提升**：PXE协议的更新通常会包括一些安全性改进，以确保启动过程的安全性。例如，加密传输和认证机制的引入可以防止网络中的恶意攻击或篡改。 **支持新的硬件架构**：随着新的硬件架构的出现，PXE协议需要相应地进行更新以支持这些新的硬件。这样，计算机可以使用PXE协议从网络中启动最新的硬件设备。 |
||
|
英特尔® NUC 产品上配置PXE启动的指南。PXE启动是一种非常方便的方式，可以让用户通过网络引导计算机，并且在大规模部署系统时特别有用。 按照您提供的步骤，在英特尔® NUC 上配置PXE启动相对简单明了：
一旦完成这些步骤，您的英特尔® NUC 将配置为通过PXE启动。在开机时，您可以按下F12键来强制从LAN启动，这将在需要时触发PXE引导过程。 这些指南对于需要使用PXE启动进行系统部署或远程管理的用户来说非常有用，能够简化配置过程并提高效率。 |
||
|
与 IPv6 兼容的 UEFI 驱动程序 适用于传统 BIOS 的英特尔®启动代理
|
||
|
支持更多的操作系统和启动选项：更新的PXE协议通常会添加对更多操作系统和启动选项的支持。这使得用户可以选择更多的启动选项，以满足不同的需求。虽然PXE本身并没有明确的分支，但在PXE实现和应用中，存在一些相关的技术和工具。 PXE 1.0：这是最早的PXE版本，引入了基本的网络启动功能，使计算机能够通过网络从服务器加载和执行操作系统映像文件。 PXE 2.0：这个版本在PXE 1.0的基础上有所改进，增加了对IPv6的支持，以适应不断发展的网络技术。 PXE 2.1：这个版本进一步完善了IPv6的支持，并引入了一些新的功能，如UEFI（统一可扩展固件接口）启动支持和基于HTTP的引导。 PXE 2.1b：这个版本修复了一些安全漏洞，并提供了更强大的身份验证和加密功能，以保护网络引导过程的安全性。 PXE 2.1d：这个版本引入了对嵌入式系统的支持，并改进了对启动配置文件的处理方式。 PXE 2.2：这个版本增加了对IPv6多播传输的支持，可以在网络中同时传输启动所需的数据包。 PXE 2.2a：这个版本增加了对安全启动（Secure Boot）的支持，通过验证操作系统启动加载的文件的签名，提供更高的启动安全性。 PXE 2.2b：这个版本引入了对UEFI固件升级的支持，允许通过网络升级计算机的固件。 PXE 2.3：这个版本增加了对同步多播传输和多服务器协作的支持，可以提高网络启动的效率和负载均衡。 XE 2.3a：这个版本修复了一些漏洞并增加了对最新硬件和固件的支持。 PXE 2.3b：这个版本引入了更高级的网络引导功能，包括动态配置文件生成和远程管理。 PXE 2.4：这个版本增加了对数据压缩和网络流量优化的支持，以减少网络传输的时间和带宽占用。 由于PXE协议是由Intel公司开发和维护的，因此查询Intel官方网站是获取最新版本官方信息的可靠途径 |
||
|
PXE 协议的不同版本在网络引导的功能和性能上进行了不断的改进和增强。以下是主要的 PXE 协议版本及其功能更新： 1. PXE 1.0（初始版本）
2. PXE 2.0（增强版）
3. gPXE（PXE 的改进版）
4. iPXE（更强大的网络引导工具）
5. PXE 2.x（UEFI 和现代硬件支持）
如果你的需求比较简单，PXE 1.0 或 2.0 就足够了；如果你需要更高效、灵活的网络引导，尤其是在大规模部署时，iPXE 是最佳选择。 |
||
gPXE: gPXE（又称Etherboot）是PXE的一个开源实现，提供了比标准PXE更多的功能和灵活性。它支持更多的网络协议、可扩展性和脚本功能，使网络引导更加强大和定制化。http://etherboot.org/wiki/ （备注：已经停止更新） |
||
|
iPXE 1.0.0：最初的版本，基于 Etherboot 项目，提供了基本的网络引导功能。 iPXE 1.0.0+：此版本添加了对HTTP、iSCSI和AoE等多种网络启动协议的支持，扩展了网络引导的能力。 iPXE 1.0.1：修复了一些漏洞和问题，并提供了更好的兼容性和稳定性。 iPXE 1.0.2：增加了对 HTTPS 引导的支持，使得网络引导更加安全。 iPXE 1.0.3：修复了一些与UEFI固件兼容性相关的问题，并提供了更好的UEFI引导支持。 iPXE 1.0.4：引入了新的脚本语言、变量解析器和网络配置选项，提供了更灵活和可定制的引导流程。 iPXE 1.0.5: 该版本修复了一些问题，并增加了对不同网络协议的改进支持，如 HTTP、iSCSI、AoE 等。 iPXE 1.0.6: 引入了更多的驱动程序，提供对更多硬件接口和网络设备的支持。 iPXE 1.0.7: 改进了引导速度和稳定性，并修复了一些与特定硬件和固件相关的问题。 iPXE 1.0.8: 增加了对 BIOS 和 UEFI 启动的更好支持，改进了与不同操作系统的兼容性。 |
||
|
https://ipxe.org/
2025年1月10日的提交： [crypto] 从bigint_mod_exp()中提取bigint_reduce_supremum() 2024年12月18日的提交： [crypto] 允许放宽蒙哥马利约简 2024年12月17日的提交： [efi] 添加EFI_TCG2_PROTOCOL头文件和GUID定义 [efi] 更新为当前EDK2头文件 2024年12月16日的提交： [crypto] 在bigint_montgomery()中按需计算模数的逆 2024年12月3日的提交： [gve] 仅在设备打开时运行启动过程 2024年11月28日的提交： [crypto] 移除过时的bigint_mod_multiply() [crypto] 使用蒙哥马利约简进行模数幂运算 2024年11月27日的提交： [crypto] 添加bigint_montgomery()来执行蒙哥马利约简 [crypto] 使用逆大小作为bigint_mod_invert()的有效大小 [crypto] 消除bigint_mod_invert()的临时工作空间 2024年11月26日的提交： [crypto] 消除bigint_reduce()的临时工作空间 [crypto] 从大整数加法和减法中暴露进位标志 2024年11月20日的提交： [crypto] 添加bigint_msb_is_set()以澄清代码 [efi] 确保在尝试SAN启动时本地驱动器已连接 2024年10月29日的提交： [build] 允许按架构为交叉编译设置前缀 2024年10月28日的提交： [riscv] 检查seed CSR是否可从S模式访问 [sbi] 添加作为RISC-V SBI有效负载运行的支持 [build] 允许默认平台根据架构变化 [pci] 为没有PCI总线的平台提供空的PCI API [riscv] 在定时器和seed CSR访问中添加缺失的volatile限定符 [riscv] 添加支持将seed CSR作为熵源 [riscv] 添加支持RDTIME作为定时器源 [riscv] 添加支持通过设备树检查CPU扩展 [fdt] 添加解析无符号整数属性的功能 2024年10月25日的提交： [pci] 仅在存在PCI支持时引入PCI设置机制 [uaccess] 将UACCESS_EFI重命名为UACCESS_FLAT [smbios] 为没有SMBIOS概念的平台提供空的SMBIOS API 2024年10月22日的提交： [riscv] 添加通过SBI重启和关机的支持 [riscv] 添加SBI调试控制台的支持 2024年10月21日的提交： [crypto] 添加bigint_mod_invert()用于计算2的幂模的逆 2024年10月18日的提交： [usb] 通过设置暴露USB设备描述符和字符串 2024年10月17日的提交： [usb] 添加“usbscan”命令以遍历USB设备 2024年10月15日的提交： [crypto] 将bigint_reduce()从bigint_mod_multiply()中分离出来 2024年10月10日的提交： [crypto] 使用与架构无关的bigint_is_set()
|
||
|
Changelog ## [Unreleased] ## [v2.8.0] 2024-05-02 - Add support for building as an AArch64 (ARM64) binary (sponsored by - Fix forcing of text mode output when multiple displays are present. - Add support for building with the clang compiler. - Replace efireloc with iPXE's elf2efi tool for converting ELF - Update to latest EDK2 headers. ## [v2.7.6] 2023-08-16 - Use separate .text and .data sections for W^X compatibility. ## [v2.7.5] 2023-01-25 - Support images compressed using the XPRESS compression scheme. - Fix building with GCC 12 - Fix use of `index=N` when no injected files are present. ## [v2.7.4] 2022-01-20 - Add [Secure Boot Advanced Targeting (SBAT)][sbat] metadata. ## [v2.7.3] 2021-04-30 - Fix extraction of embedded `bootmgr.exe` from Windows 10 versions of ## [v2.7.2] 2021-02-22 - Fix BIOS booting of 32-bit versions of Windows 8 and above with more - Ignore subdirectories when booting from a USB key (or other real - Avoid potential infinite loops when retrieving the BIOS memory map. ## [v2.7.1] 2021-02-11 - Extract `BCD`, `boot.sdi`, and standard boot font files - Use paging and Physical Address Extensions (PAE) to place the initrd - Enable stack protection for both BIOS and UEFI builds. - Tidy up debug output that typically disrupts the loading screen - Add `quiet` command-line option to inhibit all debug output - Create fully automated tests of an HTTP boot via iPXE and wimboot - Migrate from [Travis CI][travis] to [GitHub actions][actions]. ## [v2.6.0] 2017-05-10 - Dynamically patch the `.wim` image to allow files to be injected in - Use [Coverity Scan][coverity] for ongoing static analysis. ## [v2.5.2] 2016-02-09 - Validate signed binaries to ensure that no malicious code was - Fix identification of terminating character in strtoul(). ## [v2.5.1] 2015-09-22 - Work around broken 32-bit PE executable parsing in the UEFI Secure - Provide UEFI Secure Boot signed binaries. ## [v2.5.0] 2015-08-28 - Limit initrd to the low 2GB of memory to work around versions of - Prepare for UEFI Secure Boot signing. ## [v2.4.1] 2014-12-08 - Ignore `initrdfile` command-line argument that may be appended by ## [v2.4.0] 2014-11-07 - Provide space for a protected-mode interrupt descriptor table, ## [v2.3.0] 2014-09-24 - Fix building of 32-bit UEFI binary. ## [v2.2.5] 2014-09-23 - Fix construction of FAT long filenames that are exactly 12 ## [v2.2.4] 2014-09-09 - Work around UEFI firmware that fails to populate the `DeviceHandle` ## [v2.2.3] 2014-09-03 - Display an optional prompt when using the `pause` command-line ## [v2.2.2] 2014-09-03 - Generate position-independent code for UEFI, to allow for relocation - Fix assorted build toolchain issues. ## [v2.2.1] 2014-09-02 - Respect the selected boot index when extracting files from the - Add `pause` command-line option to allow for inspection of debug ## [v2.2.0] 2014-09-02 - Add the ability to extract individual files from the `.wim` image. - Extract `bootmgr.exe` or `bootmgfw.efi` automatically from the ## [v2.1.0] 2014-08-30 - Dynamically patch `BCD` file to allow the same file to be used for - Force `bootmgfw.efi` to use text mode (as already done for - Add `rawbcd` command-line option to disable dynamic BCD patching. - Add `gui` command-line option to disable forced text mode output. - Add `index=N` command-line option to allow a boot image to be ## [v2.0.0] 2014-08-29 - Support booting on UEFI systems (sponsored by [Jump Trading][jump]). - Retrieve initrd files via `EFI_SIMPLE_FILE_SYSTEM_PROTOCOL`. - Expose the virtual FAT filesystem to `bootmgfw.efi` via - Build as a hybrid 32-bit BIOS and 64-bit UEFI binary. ## [v1.0.6] 2014-06-22 - Make real-mode setup code relocatable. ## [v1.0.5] 2014-05-17 - Force `bootmgr.exe` to use text mode since it is unable to display ## [v1.0.4] 2014-03-19 - Fix the XCA decompressor to match the undocumented behaviour of the ## [v1.0.3] 2012-11-11 - Accept arbitrary amounts of zero-padding between initrds. ## [v1.0.2] 2012-10-30 - Accept initrds that are not padded to an alignment boundary. ## [v1.0.1] 2012-10-24 - Accept initrds with CPIO trailers to allow booting via syslinux as ## [v1.0.0] 2012-09-17 - Support XCA compression of `bootmgr.exe` as used by Windows 8 and ## [v0.9.3] 2012-09-15 - Expose files via `\Boot\Resources` directory for Windows 8. ## [v0.9.2] 2012-09-14 - Select virtual disk drive number dynamically to allow Windows to ## [v0.9.1] 2012-09-13 - Include pre-built binaries to make life easier for Windows users. ## [v0.9] 2012-09-11 - Create first working implementation (sponsored by [Jump - Provide a BOOTAPP entry point usable by `bootmgr.exe`. - Extract embedded `bootmgr.exe` from within `bootmgr`, if provided. - Provide a virtual BIOS disk drive containing a read-only FAT - Expose files via root, `\Boot`, and `\Sources` directories. [unreleased]: https://github.com/ipxe/wimboot/commits [2pint]: https://2pintsoftware.com/ |
||
|
这些是与 |
||
|
Cobbler PXE是指使用Cobbler和PXE（Preboot Execution Environment，预启动执行环境）来实现自动化操作系统部署和管理的一种方法。
结合Cobbler和PXE，可以实现以下功能：
总的来说，Cobbler PXE提供了一种方便快捷的方式来实现大规模Linux系统的自动化部署和管理，对于需要频繁部署和管理多台计算机的环境特别有用。
|
||
|
PXE（Preboot Execution Environment）是一种用于网络引导计算机的标准，允许计算机通过网络从远程服务器下载操作系统镜像并引导。
这种方式的优点包括节省时间和人力成本，特别是在需要部署大量计算机时。通过PXE+Kickstart，管理员可以轻松地实现统一的操作系统配置和部署流程，提高效率和一致性。
|
||
|
Pure Python PXE (DHCP-(Proxy)/TFTP/HTTP/NBD) Server 关于 该存储库包含了纯粹使用 Python 实现的一个工作中的 PXE 服务器（通过 HTTP、TFTP、DHCP 和/或 iPXE）。请阅读 DOCUMENTATION.md 获取有关 PyPXE 项目的更多解释以及推荐的用法。请查看问题页面以了解开放的问题、错误和改进/增强。 免责声明：实现的所有服务均不完全符合任何标准或规范。然而，在构建 PyPXE 时，真正的规范和标准得到了遵循，尽管它们适用于 PXE，但任何其他用途都纯属巧合。使用需自担风险。
PyPXE 的主要功能和特点包括：
PyPXE 的设计目的是为了提供一个简单、灵活的 PXE 服务器实现，以满足用户在网络引导方面的需求。它可以用于各种场景，例如网络安装操作系统、远程系统管理等。然而，用户需要注意，由于其不完全符合标准，可能存在一些限制和风险，使用时需谨慎评估和处理。 |
||
|
PXEBoot 简易安卓 PXE 启动服务器 PXEBoot 是一个轻量级的TFTP，FTP，HTTP，和proxyDHCP，主要利用手机的WIFI网络提供一个基础的PXE启动服务。 同一个网络下的电脑可以通过PXE服务来启动引导一些维护工具，甚至是基于网络的操作系统。 本应用需要 Root 权限，否则无法正常工作。 默认提供三个启动选项菜单，用户可以选择自己喜欢的菜单进入。
PXEBoot 是一个 Android 应用程序，旨在帮助用户在 Android 设备上设置和运行 PXE 服务器，以便通过网络引导其他计算机。它提供了一个方便的界面，让用户可以轻松地配置 PXE 服务器参数，并管理启动图像，从而实现网络引导操作系统或工具。 PXEBoot 的主要功能包括：
PXEBoot 的优点在于其易于设置和使用，特别是对于需要在 Android 设备上快速设置 PXE 服务器的用户来说。它提供了一个方便的解决方案，使用户能够利用他们的 Android 设备轻松实现网络引导操作。然而，由于 Android 平台的限制，该应用可能无法提供与传统服务器操作系统相同的性能和灵活性，因此在大型或复杂网络环境中可能不够适用。 PXEBoot 是一个方便的工具，可以帮助用户在 Android 设备上快速设置和运行 PXE 服务器，用于网络引导其他计算机。 |
||
|
SimplePXEServer 是一个基于 Android 平台的简单 PXE 服务器。它允许用户在 Android 设备上快速设置和运行 PXE 服务器，以便通过网络引导其他计算机。PXEServer 可以帮助在局域网内快速设置网络引导环境，以便从远程服务器上加载操作系统镜像或执行其他网络引导操作。 这个应用程序的主要功能包括：
SimplePXEServer 的优点包括易于设置和使用，特别是对于需要在 Android 设备上快速设置 PXE 服务器的用户来说。然而，由于 Android 平台的限制，该应用可能无法提供与传统服务器操作系统相同的性能和灵活性，因此在大型或复杂网络环境中可能不够适用。 SimplePXEServer 是一个方便的工具，可以帮助用户在 Android 设备上快速设置和运行 PXE 服务器，用于网络引导其他计算机。
|
iPXE 构建配置选项表格化 ：
| 文件路径 | 配置选项 | 描述 |
|---|---|---|
| config/general.h | CERT_CMD | 证书管理命令 |
| CONSOLE_CMD | 控制台命令 | |
| DOWNLOAD_PROTO_HTTPS | 安全超文本传输协议 | |
| FCMGMT_CMD | 光纤通道管理命令 | |
| GDBSERIAL | 通过串行端口进行远程 GDB 调试 | |
| GDBUDP | 通过 UDP 进行远程 GDB 调试 | |
| IMAGE_GZIP | GZIP 映像支持 | |
| IMAGE_PNG | PNG 图像支持 | |
| IMAGE_PNM | PNM 图像支持 | |
| IMAGE_UCODE | 微码更新映像支持 | |
| IMAGE_ZLIB | ZLIB 映像支持 | |
| IMAGE_ARCHIVE_CMD | 归档镜像管理命令 | |
| IMAGE_CRYPT_CMD | 镜像加密管理命令 | |
| IMAGE_TRUST_CMD | 映像信任管理命令 | |
| IPSTAT_CMD | IP 统计命令 | |
| LOTEST_CMD | 环回测试命令 | |
| NEIGHBOUR_CMD | 邻居管理命令 | |
| NET_PROTO_IPV6 | IPv6 协议 | |
| NET_PROTO_FCOE | 以太网光纤通道协议 | |
| NSLOOKUP_CMD | 名称解析命令 | |
| NTP_CMD | 网络时间协议命令 | |
| PARAM_CMD | 表单参数命令 | |
| PCI_CMD | PCI 命令 | |
| PING_CMD | Ping 命令 | |
| POWEROFF_CMD | 关机命令 | |
| PROFSTAT_CMD | 性能分析命令 | |
| REBOOT_CMD | 重新启动命令 | |
| TIME_CMD | Time 命令 | |
| USB_CMD | USB 命令 | |
| VLAN_CMD | VLAN 命令 | |
| config/console.h | CONSOLE_FRAMEBUFFER | 图形 framebuffer 控制台 |
| CONSOLE_PCBIOS | 默认 BIOS 控制台 | |
| CONSOLE_SERIAL | 串行端口控制台 | |
| CONSOLE_SYSLOG | Syslog 控制台 | |
| CONSOLE_SYSLOGS | 加密的 syslog 控制台 | |
| CONSOLE_VMWARE | VMware 日志文件控制台 | |
| KEYBOARD_MAP | BIOS 控制台键盘映射 | |
| LOG_LEVEL | 日志消息级别 | |
| config/crypto.h | TIMESTAMP_ERROR_MARGIN | 签名时间戳误差边距 |
| config/serial.h | COMCONSOLE | I/O 端口地址 |
| COMDATA | 数据位 | |
| COMPARITY | 平价 | |
| COMSPEED | 波特率 | |
| COMSTOP | 停止位 | |
| config/settings.h | CPUID_SETTINGS | CPUID 设置 |
| MEMMAP_SETTINGS | 内存映射设置 | |
| VMWARE_SETTINGS | VMware GuestInfo 设置 | |
| VRAM_SETTINGS | 视频 RAM 内容设置 |
这样，您可以更直观地查看和编辑相关配置选项。
文档
参考资料
-
使用 iPXE 命令行
-
使用 iPXE 命令编写脚本
-
配置控制台（串行、图形帧缓冲、syslog 等）
-
使用加密技术进行 HTTPS 或代码签名
-
所有 iPXE 命令的列表
-
所有 iPXE 设置的列表
-
所有 iPXE 构建选项的列表
Howto 指南
启动 iPXE
-
如何使用现有 PXE ROM 链加载 iPXE
-
如何将 iPXE 刻录到 ROM 中
-
如何在 VMware 中使用 iPXE
DHCP
-
如何将 ISC dhcpd 与 iPXE 一起使用
-
如何将 Microsoft DHCP 服务器与 iPXE 配合使用
操作系统
-
如何安装 Fedora、RHEL、CentOS 或类似的 Linux 发行版
故障 排除
-
如何捕获数据包跟踪
-
如何使用 git-bisect 追踪 iPXE 中的错误
-
预期工作的硬件驱动程序列表
外部文档
-
NetworkBoot.org - 初学者可以学习网络启动基础知识的地方
-
围绕 iPXE 构建的完整解决方案示例
应用说明
-
使用 iPXE 引导 Windows 部署服务
-
从 NFS 服务器引导 Ubuntu Live
-
使用 iPXE 安装 XenServer
-
将 Windows XP 或 2003 直接安装到 iSCSI 目标
-
将 Windows Server 2008 直接安装到 SRP SAN 目标
-
使用 WinPE 3.0 手动连接到 iSCSI 目标
-
更改 iPXE 发送的 DHCP 用户类
-
使用 DigiCert eToken 的 UEFI 安全启动签名
-
通过 UEFI HTTP Boot 链式加载 iPXE
-
从 NetWare RPL 引导 ROM 链式加载 iPXE
-
使用 tftpd-hpa 支持损坏的 TFTP 客户端
-
使用 preseed 指定的 Debian 启动 debian_preseed
开发人员文档
iPXE 源代码使用 Doxygen 进行记录;您可以在 http://dox.ipxe.org/files.html 中浏览生成的文档。
iPXE 使用 GitHub Actions 进行自动化构建和单元测试，并使用 Coverity Scan 进行静态分析。
浙公网安备 33010602011771号