简介：《深度远程启动管理器 1.3》面向网络管理员、机房运维人员及希望搭建 PXE 网络启动环境的用户，聚焦局域网内工作站批量引导与远程启动管理。软件遵循 BOOTP 规范，内置 DHCP 与 TFTP 服务，可提供 netboot 网络启动支持，让工作站从 PXE 引导；网络引导程序 NBP 允许自行指定，常见的 grub4dos、gpxe、pxelinux、winaoe 等开源方案均可按需编译配置，并支持多台工作站按不同引导文件分组启动，适合机房多系统部署、批量维护和网络启动实验等场景。压缩包共 4 个文件，以 2 个 exe 可执行程序为主，辅以 txt 与 htm 说明文档，整体约 2.68MB，体积轻便，便于快速获取核心工具与配置说明。已有 660 人学习，可为理解 PXE 启动流程、DHCP/TFTP 协同及 NBP 选择提供可直接参考的软件实例。

1. 深度远程启动管理器 1.3：四十台机器重装系统，为什么我把 U 盘收进了抽屉

实验室四十台机器要统一换系统，插 U 盘、点下一步、等二十五分钟，一台一台来，两天就没了，中间还得防着有人拔错盘。深度远程启动管理器 1.3 是我这两年处理这类活时固定使用的工具：镜像放在一台服务器上，客户端网卡一开、PXE 一响应，装机、还原、批量分发全在局域网里跑完，人只需要在管理端点几下。它不涉及虚拟化，也不做远程桌面，本质上是一个统一管理 DHCP、TFTP 与 iPXE 这条启动链路的调度器，附带客户端记录和镜像仓库。

它适合手上有二十台以上同构机器的场景——机房、实验室、产线测试机、门店终端；家里两三台电脑用它属于杀鸡用牛刀，配一遍 DHCP 的时间够你装十次系统了。下面按我实际部署的顺序拆：先把网络启动这套底层链路搭稳，再谈镜像怎么塞进去、批量分发怎么开组播，最后是那些会让人半夜爬起来看交换机的坑。

2. 网络启动的底层链路：DHCP 与 TFTP 的握手细节，决定一半的失败率

很多人第一次用这类管理器，卡住的地方通常发生在插上网线后的第一屏；真正进入管理器界面之后卡住的情况其实不多。客户端屏幕上滚的那几行字，其实已经把故障位置告诉你了，只是没人教过你怎么读。这一章把从网卡通电到菜单出现之间的几十秒拆开看。

2.1 PXE 四步时序：客户端到底在等谁回话

客户端开机按网卡启动，第一件事是广播DHCPDISCOVER。这一步是二层广播，出不了网关，所以部署服务器必须和客户端在同一个广播域，或者中间有设备做 DHCP 中继。服务器回DHCPOFFER时，除了给 IP、掩码、网关，还会塞两个关键字段：next-server（option 66，告诉客户端文件服务器在哪）和bootfile-name（option 67，告诉客户端第一个文件叫什么）。客户端拿到这两个值，才去用 TFTP 拉那个文件。

这里有个容易忽略的点：option 67指定的文件叫 NBP（Network Bootstrap Program），它本身不是操作系统，只是一个几十 KB 到 1 MB 的跳板程序。老式 BIOS 机器用的是undionly.kpxe这类约 70 KB 的文件，UEFI 机器用的是ipxe.efi这类约 1 MB 的文件。为什么体积这么重要？因为 TFTP 走 UDP 69 端口，默认块大小 512 字节，一个 1 MB 的ipxe.efi要来回确认两千次，在质量一般的交换机上很容易超时重传。

所以客户端屏幕上出现DHCP...一直转圈，是没收到 offer，问题在 DHCP 层；出现TFTP...或ProxyDHCP...之后卡住，是 offer 拿到了但文件下不来，问题在 TFTP 层或防火墙。这两个症状的处理方向完全相反，别一上来就重装管理器。

2.2 接管还是旁路：ProxyDHCP 与完整 DHCP 的选型

网段里已经有一台路由器在发 IP 的时候，最忌讳的就是把管理器的 DHCP 也全开——两台服务器同时应答，客户端先收到谁的就认谁，结果是“有的机器能启动、有的机器不能”，而且每次重启结果都不一样。这是最典型的配置错误。

常见做法是走 ProxyDHCP：管理器的 DHCP 只回答 PXE 相关的部分，IP 地址仍然由原来那台路由器发。dnsmasq 里用一个proxy关键字就能开这个模式，PXE 的应答会走到 4011 端口。配置文件大致是这样：

# /etc/dnsmasq.d/pxe.conf port=0 # 关掉 DNS 功能，只做 DHCP 与代理应答 interface=eth1 # 只监听内网这块网卡，避免应答串到办公网 bind-interfaces log-dhcp # 把每次交互写进日志，排错全靠它 dhcp-range=192.168.60.0,proxy,255.255.255.0 # proxy 模式，不发 IP pxe-service=x86PC,"LAN Boot (Legacy)",ipxe pxe-service=X86-64_EFI,"LAN Boot (UEFI)",ipxe.efi enable-tftp tftp-root=/srv/tftp

proxy这个参数是整个配置的核心：它让 dnsmasq 只回应带PXEClient标识的请求，普通办公电脑要 IP 的时候它装作没听见。pxe-service按固件类型分两条，是因为客户端在请求里会带架构标识，Legacy BIOS 发的是x86PC，64 位 UEFI 发的是X86-64_EFI，两者要的 NBP 完全不同。log-dhcp建议一直开着，日志里会明确写出“给某个 MAC 回了哪个 bootfile”，出问题时这一行比任何猜都准。

如果你的网络是跨网段的三层结构，那就不能靠广播了，得在网关设备上配 DHCP 中继指向部署服务器，并且确认中继会透传 option 66/67。很多三层交换机默认只中继基础字段，PXE 相关的字段被丢掉，表现就是“IP 拿到了，但就是不启动”。

注意：改完 DHCP 配置先用一台测试机验证，不要一次性推给整个网段。两台 DHCP 抢答造成的故障，排查成本远高于多花十分钟做单机验证。

2.3 把 NBP 换成 iPXE：菜单化与 chainloading

NBP 只负责一件事：把控制权交给真正的启动脚本。这套流程叫 chainloading。第一跳是固件从 TFTP 拿到的ipxe.efi或undionly.kpxe，第二跳是它自己去 HTTP 拉一个文本脚本，脚本里写着菜单和各项启动参数。

这么设计的好处很实在：改菜单不用重新生成 NBP，不用管固件差异，也不用再碰 TFTP。HTTP 传大文件比 TFTP 快一个数量级，一个 400 MB 的 WinPE 镜像用 TFTP 传要十几分钟，走 HTTP 通常两三分钟就完事。

#!ipxe dhcp || goto retry # 拿不到地址就重试，别直接死在这里 set srv http://192.168.60.2 # 镜像服务器地址，后面所有路径都基于它 :menu menu 启动菜单 --timeout 10000 item --gap -- -------- 维护环境 -------- item winpe WinPE 维护环境 item live Linux Live 桌面 item --gap -- -------- 其他 -------- item local 从本地硬盘启动 item shell 进入 iPXE 命令行 choose --default local t && goto ${t} :winpe kernel ${srv}/wimboot initrd ${srv}/winpe/bootmgr bootmgr initrd ${srv}/winpe/BCD BCD initrd ${srv}/winpe/boot.sdi boot.sdi initrd ${srv}/winpe/boot.wim boot.wim boot :local exit # 退出 iPXE，交还给固件按原顺序启动

choose --default local这个默认项很重要：超时十秒没人操作就回本地硬盘，避免服务器一挂整个机房全部卡在菜单界面。exit是 iPXE 交还控制权的标准写法，等价于“从下一启动项继续”，比自己写硬盘引导扇区跳转稳得多。item --gap只用来画分隔线，不参与选择。

这套脚本放哪儿？管理器一般会把它挂在 HTTP 根目录下的固定路径，NBP 里内置了指向它的地址。如果你要改，改的是这份文本，不是重新生成ipxe.efi。

3. 把 ISO 变成启动项：WinPE 与 Linux Live 的两条注入路径

网络层通了之后，下一步是往里放东西。很多人以为把 ISO 扔进目录就能启动，结果菜单点了没反应——ISO 是个容器，PXE 要的是容器里的具体文件。这一章讲清楚两条路径分别需要哪些文件。

3.1 目录约定与镜像落位

先把目录结构定下来，后面所有配置都基于它。我一般这么分：

原则就一条：TFTP 只承担“把控制权交出去”这一件事，凡是超过 2 MB 的东西一律走 HTTP。这条规则定下来，后面九成的传输超时问题不会出现。

每个镜像目录里再放一个manifest文本，写清楚版本号、生成时间、适用的机型。听着像形式主义，但三个月后你面对五个名字都叫winpe的目录时，会感谢当时的自己。

3.2 Windows 侧：wimboot 四件套的拼装

WinPE 不能直接启动，需要一个小程序wimboot把 WIM 挂到内存盘上再引导。它要求的输入是四个文件加它自己：

kernel ${srv}/wimboot # 引导器本体，约 20 KB initrd ${srv}/winpe/bootmgr bootmgr # 引导管理器 initrd ${srv}/winpe/BCD BCD # 引导配置数据库 initrd ${srv}/winpe/boot.sdi boot.sdi # 内存盘驱动 initrd ${srv}/winpe/boot.wim boot.wim # 真正的 PE 镜像 boot

这五个文件里，wimboot从 iPXE 官方项目取，后四个从 Windows 安装 ISO 的boot目录里拷。注意initrd后面跟的两个参数：前面是服务器上的实际路径，后面是 wimboot 在内存里给它起的名字——bootmgr就必须叫bootmgr，名字对上才能被识别，路径随便。

BCD有一个隐藏坑：从 ISO 直接拷出来的 BCD 里，device和osdevice指向的是ramdisk，这个是对的；但如果你用工具编辑过 BCD，很容易把这两项改成了具体分区路径，结果 wimboot 加载到一半报0xc000000f。判断方法很简单：BCD 文件大小只有 20 KB 左右，用十六进制编辑器能看到里面有没有ramdisk字样。改坏了就从 ISO 重新拷一份，别试图修。

WinPE 起来之后如果认不到网卡，说明boot.wim里缺驱动。2.5G 网卡和部分新型号的有线网卡在旧版 PE 里都没有内置驱动。处理办法是把厂商的驱动用dism挂载进boot.wim：

# 把驱动注入到 PE 镜像的离线目录 mkdir -p /mnt/pe dism /Mount-Wim /WimFile:/srv/http/winpe/boot.wim /Index:1 /MountDir:/mnt/pe dism /Image:/mnt/pe /Add-Driver /Driver:/srv/drivers/net /Recurse dism /Unmount-Wim /MountDir:/mnt/pe /Commit

/Index:1指定映像里的第一个卷，PE 通常只有一个；/Recurse让它把驱动目录下所有子目录都扫一遍；/Commit不写就会丢弃所有改动，很多人第一次做这一步会忘了加，白忙半小时。注入之后boot.wim体积会涨几十 MB，这是正常的。

3.3 Linux 侧：kernel + initrd 与 live 参数

Linux Live 的路径更直接，两个文件就够，关键是内核命令行参数要写对：

kernel ${srv}/live/vmlinuz boot=live components quiet fetch=${srv}/live/filesystem.squashfs initrd ${srv}/live/initrd.img boot

boot=live告诉 initrd 走 live 启动流程，components让它加载额外的硬件检测模块，fetch=是最关键的一项：默认情况下 live 系统会去本地光盘里找filesystem.squashfs，走 PXE 时必须显式告诉它根文件系统在网络上的地址，否则会停在Unable to find a medium containing a live file system。

如果这个 Live 环境需要持久化保存数据，就得再挂一个网络存储，通常用 NFS 或 iSCSI。常见做法是在内核参数里加persistence并配置一个存储后端，但这条路依赖存储服务的可用性——存储服务挂掉，客户端会卡在启动阶段。机房环境下我一般直接关掉持久化，数据统一回写到服务器，客户端保持无状态，反而省心。

3.4 抓包与日志：三分钟定位卡在哪一步

排错不要靠猜。服务端一条命令就能看清整个交互过程：

# 只抓 DHCP 与 TFTP 相关端口，避免被其他流量淹掉 tcpdump -i eth1 -n -vv 'port 67 or port 68 or port 69 or port 4011'

看到客户端发DHCPDISCOVER但没有任何回应，检查interface=绑的是不是内网网卡、防火墙有没有放行 UDP 67/68。看到有DHCPOFFER但客户端没继续，多半是客户端收到了另一台设备的 offer，用-e参数把源 MAC 打出来对比一下就很清楚。看到 TFTP 请求发出后反复重传同一个块，检查tftp-root路径权限和blksize协商。

客户端这边也有信息。iPXE 自带命令行，菜单里留一个shell项，进去之后可以dhcp、ifstat、imgfetch逐条手动执行，比反复重启快得多。这个入口我建议一直留着，交付给使用方之前也不删。

4. 批量分发与还原：组播、写盘与客户端记录

单台能启动，和多台能同时装完，中间还差着一次网络架构上的选择。四十台机器同时从一台服务器拉 20 GB 镜像，千兆网卡会被打满，最后几台耗时是前面的好几倍。这一章讲怎么把这段时间压下来。

4.1 单播与组播的临界点

单播是一对一，N 台客户端就要发 N 份数据；组播是一对多，服务器只发一份，由交换机复制给所有加入组的端口。听起来组播完胜，但它对网络设备有要求，配置不对会比单播更慢。

我自己的临界点大概在 8 台：低于这个数直接走 HTTP 单播，不用管交换机配置，省心；高于这个数开组播，但前提是先确认交换机开了 IGMP snooping 并且有 querier。没有 querier 的组播会被当成广播泛洪到所有端口，把办公网一起拖慢，这是真事。

4.2 镜像采集与回写：partclone 与 udpcast 组合

采集一台“样板机”的镜像，用partclone比dd好，因为它只复制有数据的块，一个用了 40 GB 的 500 GB 分区，镜像可能只有 20 GB。

# 采集 NTFS 分区，压缩后落到镜像库 partclone.ntfs -c -s /dev/sda2 -o - | gzip -1 > /srv/http/images/office-win11.img.gz # 校验压缩包完整性，采集完立刻做，别等分发时才发现坏包 gzip -t /srv/http/images/office-win11.img.gz && echo OK

-c是采集模式，-s是源分区，-o -输出到标准输出直接接管道，gzip -1用最低压缩级别——这里是个取舍：-9能把体积压得更小，但解压时 CPU 成为瓶颈，四十台机器同时解压反而不如用-1快。gzip -t那行别省，一个坏包分发到四十台机器上，你会得到四十次失败。

分发用udp-sender，回写用udp-receiver：

# 服务端：等够 5 台客户端再开始，最多等 90 秒 udp-sender --file /srv/http/images/office-win11.img.gz \ --interface eth1 --min-clients 5 --max-wait 90 --full-duplex # 客户端：接收并直接写入目标分区，中间不落盘 udp-receiver --file - | gzip -dc | partclone.ntfs -r -s - -o /dev/sda2

--min-clients 5是防止第一台机器连上来就开始发，后面来的全错过；--max-wait 90是兜底，凑不够人数也不能无限等，九十秒后有几台发几台；--full-duplex允许同时收发，在全双工链路上能提升吞吐。客户端那条管道最后落到partclone -r的恢复模式，-s -表示从标准输入读，这样整个链路不需要在本地留一份几十 GB 的临时文件。

不过组播的实际配置会因设备和版本不同而差别很大，管理器 1.3 里通常把这一层包装成了任务下发，底层的--min-clients之类的参数一般在任务详情里能改。如果界面里没有暴露，就退回命令行手动跑一次，先验证网络通不通，再回头怪工具。

4.3 客户端记录：MAC、分组与命名绑定

批量装机的麻烦不在装，在于装完之后四十台机器名字都一样、IP 都一样，你还得一台台查 MAC 改主机名。管理器的客户端列表就是解决这个的，我一般会把它维护成一张表：

这张表的价值在装机之后。首次启动的脚本按 MAC 去查询这张表，拿到主机名、分组、要装的软件清单，自动改完名、配完 IP、装上资产代理，整个过程不需要人守着。四十一台机器从按下电源到全部就绪，我最近一次记录是 38 分钟。

4.4 首次启动的收尾脚本

Windows 侧我用一个开机自启的批处理，从管理器的 HTTP 接口拉自己的配置：

@echo off set SRV=http://192.168.60.2 for /f "tokens=2 delims=:" %%a in ('getmac /fo list ^| findstr /i "物理地址"') do set MAC=%%a set MAC=%MAC: =% :: 按 MAC 拉取本机配置，拿不到就退出，不阻塞开机 curl -s -o C:\cfg.json "%SRV%/api/client?mac=%MAC%" || exit /b 1 :: 改名、设静态 IP、写资产标签，具体解析交给 PowerShell powershell -ExecutionPolicy Bypass -File C:\cfg.ps1 -Config C:\cfg.json

getmac输出的 MAC 带空格和冒号，%MAC: =%把空格去掉再拼进 URL，这一步漏了就会 404。|| exit /b 1保证配置服务不可用时脚本安静退出，而不是卡在开机界面等人按任意键——交付出去的现场没人会按。整个脚本必须在装完机之后从镜像里移走或者改成一次性执行，不然每次开机都跑一遍，会覆盖掉使用者后来改的设置。

5. 避坑清单：五个让部署卡住的经典现场

下面这五条是我踩过的，按“现象 → 原因 → 解决”记下来，遇到同类问题照着对号入座就行。

5.1 网络与启动阶段

现象：同一个机房，二十台机器里有六台反复重启，另外十四台正常进菜单。

原因：网段里有两台设备在发 DHCP。路由器先应答的那几台拿到了 IP 但没有next-server，客户端在DHCP...转两圈后放弃，走回本地硬盘启动，看起来就是“重启了”。这个故障最迷惑人的地方在于它是概率性的，重启几次可能又好了。

解决：把管理器的 DHCP 改成 ProxyDHCP 模式，只回 PXE 部分；或者把路由器上那个网段的 DHCP 关掉，统一由部署服务器发。改完用tcpdump -e看 offer 的源 MAC 是否唯一。这条我后来做成了标准动作：任何新网段上线前先抓一轮包，确认只有一个应答源。

现象：UEFI 机器能起，几台老机器一直停在No boot filename received。

原因：pxe-service只配了X86-64_EFI一条，老 BIOS 机器发的架构标识是x86PC，匹配不上就没有 bootfile。

解决：两条都配上，Legacy 指向undionly.kpxe，UEFI 指向ipxe.efi。另外 BIOS 里要把“网络启动”从 UEFI 模式改成 Legacy，或者启用 CSM，不然固件根本不会发x86PC的请求。

5.2 镜像与写盘阶段

现象：镜像分发到 80% 左右，几台客户端报校验失败，重试还是失败。

原因：组播用的是 UDP，没有重传机制，交换机某个端口瞬时拥塞就会丢块。千兆环境下如果同时还有别的上下行流量，很容易碰上一次。

解决：分发完成后强制做一次校验，gzip -t或者比对哈希；失败的客户端单独用单播 HTTP 重拉一遍。另外把--min-clients调小、分批开机能明显降低丢包率，别指望一次把四十台全灌完。

现象：写完盘重启，机器不进系统，卡在黑屏光标闪烁。

原因：目标盘上还有旧的 GPT 分区表残留，新写入的分区内容和残留的引导项对不上。用partclone只恢复分区，不负责清分区表。

解决：恢复前先清一遍分区表，wipefs -a /dev/sda或者sgdisk -Z /dev/sda，再做恢复。这一步做成流程里的固定环节，别图省事跳过。

5.3 固件与硬件差异

现象：新到的一批机器 PXE 能起，进 WinPE 之后找不到网络，装不了系统。

原因：boot.wim里没有这批机器网卡的驱动。新网卡型号的驱动往往要等厂商放出，PE 镜像里自然不会有。

解决：按 3.2 的方式用dism把驱动注入boot.wim，注入后重新做一次采集或者直接替换镜像库里的文件。同类问题还有存储控制器驱动——如果 PE 里认不到硬盘，思路完全一样。

现象：UEFI 机器开了 Secure Boot 之后，PXE 一启动就报安全违规然后跳回硬盘。

原因：ipxe.efi没有签名，Secure Boot 拒绝加载未签名的引导程序。

解决：机房场景下常规做法是在固件里把 Secure Boot 关掉，或者把自制证书导入固件信任列表。这是有安全取舍的决定，得跟设备管理方确认，不要自己拍板。

6. 进阶：把 1.3 的客户端记录接入自动化流程

客户端数量超过五十之后，在界面上一个个点已经跟不上节奏了。管理器 1.3 的客户端列表背后是一份可以被程序读写的数据，我一般不去点界面，而是拿一份 CSV 直接灌进去。表头固定五列：MAC、分组、主机名、资产编号、备注；空行和以#开头的行跳过，这样可以在文件里写注释。

# 按 CSV 批量注册客户端，注册前先过滤掉 MAC 重复的行 awk -F, '!/^#/ && NF>=4 { mac=tolower($1); gsub(/[ :-]/,"",mac); if (seen[mac]++) { print "DUP " $1 > "/dev/stderr"; next } print mac","$2","$3","$4 }' clients.csv > /tmp/clients.clean # 先空跑一次看行数对不对，再真正提交 wc -l < /tmp/clients.clean curl -s -X POST --data-binary @/tmp/clients.clean \ -H 'Content-Type: text/csv' http://192.168.60.2/api/clients/import

gsub(/[ :-]/,"",mac)把 MAC 里的冒号、空格、横线统一去掉再查重，因为手工维护的表格里这三种写法一定都会出现。seen[mac]++这个技巧在 awk 里是最省事的去重方式，命中重复的打到标准错误，不影响输出流。提交前先wc -l数一遍行数，是我从一次事故之后养成的习惯——那次 CSV 里混进了一个空行，导入脚本把一整批记录覆盖成了默认值。

导入完成不等于配置生效，我固定会验三个检查点：

第二条最容易被跳过。记录表改对了、界面显示也对了，但客户端缓存了旧的启动策略，实际启动时还是老菜单——这种情况必须用真机跑一遍才能发现，光看界面会误判。

从那以后我每次改 DHCP 配置或者批量导入客户端记录前，都会先在测试网段抓一轮 67/68 端口的包，确认应答源只有一台、bootfile 字段和预期一致，才敢推到生产网段。多花的这十分钟，比事后在机房里逐台排查省得多。希望帮到你。

本文还有配套的精品资源，点击获取