那天下班前机房新上架的20台无盘终端全部开机失败屏幕画面极其统一一行白色的英文提示“please reboot and try again”然后无论按哪个键开机后又是同样的画面跟复读机一样。管理员群里瞬间就炸了有人怀疑交换机配置被改有人说是不是PXE服务器挂了还有人直接说这批终端是不是硬件有问题。作为常年跟无盘环境打交道的运维我看这个报错的第一反应不是硬件而是启动链路的某个环节断了。无盘环境里客户端没有本地硬盘整个系统的启动依赖网络完成PXE、DHCP、TFTP、NFS或iSCSI任何一个环节掉链子最终都会以各种“看不懂的英文提示”呈现在你面前。这次这个“please reboot and try again”如果非要翻译成大白话那就是固件里的PXE启动客户端在喊我找不到能启动的东西你重启再试一次吧。这篇文章我就围绕这个报错把无盘环境从加电到进入系统的完整链路拆开讲一遍重点说清楚这条提示到底是谁弹出来的、在链路中的哪个位置触发、以及如何一步步定位到根因。当然我也会把这些年处理过的真实案例和排查命令一起放出来希望能帮遇到同样问题的朋友少走弯路。1. 先弄清楚这个报错到底发生在启动链路的哪一环1.1 无盘环境开机启动的一次完整旅程要理解无盘环境下的报错必须先理解无盘环境是如何“无中生有”地启动一个操作系统的。有盘机器开机时BIOS或UEFI会直接定位到本地硬盘上的引导程序而无盘机没有这块硬盘它必须通过网络把所有本该在本地完成的工作一次做完。一次完整的无盘启动流程大致是这样的客户端加电网卡上的PXE ROM被激活向网络中广播DHCP Discover请求。DHCP服务器收到请求后不仅会分配IP地址还会附带两个关键信息next-server即TFTP服务器地址和bootfile启动文件名。客户端通过TFTP协议从服务器下载bootfile常见的是pxelinux.0或bootx64.efi。bootloader成功加载后会去读取配置文件通常是pxelinux.cfg/default根据配置继续下载内核vmlinuz和内存文件系统initrd.img。内核和initrd加载到内存后内核会挂载真正的根文件系统无盘环境里通常是NFS或iSCSI。根文件系统挂载成功后系统才会真正进入类似普通机器开机后那个“启动操作系统”的流程。大家注意看这六步里任何一步失败屏幕上都会出现一个报错。而且越靠前的环节失败报错就越“原始”。如果你看到的是“please reboot and try again”这种连有效技术信息都没有的提示大概率说明连bootloader都还没成功跑起来。1.2 谁在说“please reboot and try again”这个报错不是Linux或Windows弹出来的它来自客户端固件里的PXE启动代码。无论是传统BIOS时代的Intel Boot Agent还是UEFI环境下内置的PXE client它们在启动引导阶段都有一套自己的错误处理逻辑。当PXE ROM发出DHCP请求后如果在规定时间内没有等到任何响应或者明明拿到了TFTP服务器地址却下载不到文件PXE ROM就会放弃这一次网络启动并在屏幕上给出提示。“please reboot and try again”就是这类提示里非常典型的一种它本质上是PXE ROM的“最后遗言”。换句话说看到这个提示你先不要把注意力放在操作系统层面什么内核panic、驱动加载失败、根文件系统损坏通通不用去想。问题几乎可以锁定在DHCP阶段或TFTP下载阶段。这就像你网购一个商品物流信息显示“派送失败”你要查的是快递员和仓库而不是纠结商品内部的零件装得好不好。1.3 为什么无盘环境最容易卡在这个提示搞无盘的人都懂一个道理无盘环境比有盘环境“脆”得多因为它的启动链路被拉得很长依赖项太多。有盘环境开机依赖的是SATA线和硬盘固件而无盘环境依赖的是DHCP服务、TFTP服务、NFS服务、网络交换机、网线质量、VLAN配置甚至防火墙策略。任何一个环节出现波动客户端看到的都是同一个“please reboot and try again”。尤其是一些规模不大、没有专职网络管理的机房DHCP服务和TFTP服务可能都挤在一台老旧的服务器上服务之间互相抢资源某一个服务挂了整个机房就全灭了。另外一个容易被忽略的问题是时间戳和文件大小写。Linux系统中的文件名是严格区分大小写的PXE环境里的TFTP服务默认也是区分大小写的。如果你的配置文件里写的是VMLINUZ而实际文件叫vmlinuzPXE ROM下载时就会报文件不存在最终还是回到这个提示。这种低级错误在真实机房里出现过太多次我后面详细讲。2. 排查思路三步法快速锁定故障环节遇到这个报错别急着重启服务器或者换交换机更不要一堆人围在终端前面反复按电源键。我自己的排查习惯是三步走一看DHCP二测TFTP三查启动参数。2.1 第一步先看客户端有没有拿到有效的DHCP地址PXE启动的前提是有IP地址。如果客户端根本拿不到IPPXE ROM自然无法进入下一步最终报“please reboot and try again”是必然的。怎么判断客户端有没有拿到IP最简单的办法是看客户端屏幕上PXE ROM运行时的提示信息。大多数PXE ROM在从DHCP获取到地址后会显示一行类似CLIENT IP: 192.168.1.100的信息。如果你看到屏幕上长时间处于PXE-E51: NO DHCP OR PROXYDHCP OFFERS RECEIVED之类的提示那就说明DHCP根本没下发成功。还有一种情况是屏幕上压根不显示IP信息一晃而过就报错了。这时候更可靠的办法是到DHCP服务器上抓包确认。假设你的DHCP服务跑在一台Linux服务器上eth0是服务网卡可以执行tcpdump -i eth0 -n port 67 or port 68观察是否有来自客户端的DHCP Discover报文以及服务器是否回应了DHCP Offer。如果只有Discover没有Offer问题出在DHCP服务本身或者交换机上的DHCP Snooping策略如果连Discover都没有问题可能出在客户端的PXE ROM配置或VLAN隔离上。有一点要注意有些交换机开启了DHCP Snooping会把非信任端口的DHCP Offer直接丢弃表现为客户端反复请求却一直拿不到地址。遇到这种情况检查一下交换机端口配置通常比排查服务器更有效。2.2 第二步手动验证TFTP下载是否正常确认客户端拿到IP之后下一步就是看TFTP下载是否成功。PXE ROM在DHCP阶段拿到next-server和bootfile之后会立刻发起TFTP下载请求。如果下载失败PXE ROM同样会以“please reboot and try again”收场。手动验证TFTP服务是否正常可以在任意一台能访问到该TFTP服务器的机器上执行tftp 192.168.1.10 -c get pxelinux.0如果这条命令执行后文件能正常下载到本地说明TFTP服务本身是通的。如果提示超时或文件未找到那就需要登录到TFTP服务器上检查服务状态和文件路径。TFTP服务常见的坑有两个。一个是没有启动服务或者服务启动失败执行systemctl status tftpd-hpa或者systemctl status tftp就能看到状态。另一个是文件权限不对很多TFTP服务默认以nobody用户运行如果pxelinux.0所在的目录或文件权限设置太严格TFTP进程根本没有权限读取客户端这边会收到file not found的响应。顺带说一句TFTP服务监听的默认端口是UDP 69如果服务器上开了防火墙一定要先放行这个端口。用UFW管理防火墙的Linux发行版可以执行ufw allow 69/udp2.3 第三步顺着bootloader的路径检查内核与根文件系统如果DHCP正常、TFTP也能下载下载下来的bootloader也执行了但仍然报错或者卡在后续阶段那就需要把排查重心放到bootloader加载之后的内容上。虽然这一步的报错通常不会再是“please reboot and try again”但实践中经常出现多个问题叠加的情况也就是说你修好了TFTP下载紧接着又会暴露出下一个问题。bootloader加载后会去pxelinux.cfg目录下寻找配置文件。它查找配置文件的顺序是有讲究的先根据客户端机器的GUID查找再根据MAC地址查找然后根据IP地址用十六进制逐级降位匹配最后才轮到default文件。如果这些文件都没有PXE启动会进入一个类似boot:的提示符此时系统并不会自动启动。假设default文件存在而且内容至少是下面这种形式default linux label linux kernel vmlinuz append initrdinitrd.img rootnfs:192.168.1.10:/nfsroot ipdhcp rw那么bootloader会继续通过TFTP下载vmlinuz和initrd.img。这两个文件同样受TFTP权限和路径影响。文件下载完成后内核启动接着就进入挂载根文件系统的环节。对于NFS根目录的无盘环境需要确保服务器上的NFS服务已启动、exports文件已经导出对应目录、防火墙放行了NFS相关端口。3. 实战修复四种常见根因的处理方法理论说完了接下来直接上实战。这些年处理过的“please reboot and try again”故障绝大多数落在下面四个根因里。3.1 TFTP目录里根本没有可下载的启动文件这个根因听着离谱但真实发生的频率非常高尤其是有人重新搭建过PXE服务器或者有人清理过磁盘却忘了通知运维。有一次我帮朋友处理一个无盘机房的故障所有客户端都在同样的位置报错。我登录到TFTP服务器上一看/var/lib/tftpboot/目录下干干净净只有一个测试用的文本文件。pxelinux.0、vmlinuz、initrd.img全都不知去向。后来才知道前一天有同事在服务器上做过空间清理把不认识的文件都删了。如果你的TFTP目录也面临这种“家底太薄”的情况解决方案很简单把系统镜像里的相关文件复制过来即可。如果你用的是Syslinux提供的pxelinux.0一般安装syslinux-common之后就能在/usr/lib/syslinux/modules/bios/目录下找到它cp /usr/lib/syslinux/modules/bios/pxelinux.0 /var/lib/tftpboot/ cp /boot/vmlinuz-$(uname -r) /var/lib/tftpboot/vmlinuz cp /boot/initrd.img-$(uname -r) /var/lib/tftpboot/initrd.img复制完之后记得把文件权限设置为644目录权限设置为755chmod 644 /var/lib/tftpboot/pxelinux.0 /var/lib/tftpboot/vmlinuz /var/lib/tftpboot/initrd.img chmod 755 /var/lib/tftpboot每次都因为权限问题重蹈覆辙的朋友建议直接把这句命令写进部署文档里。3.2 DHCP下发的next-server和启动文件名不对如果说TFTP目录缺文件是“仓库里没货”那DHCP配置错误就是“快递单上的地址写错了”。客户端虽然拿到了IP但不知道去哪台服务器下载启动文件或者拿到一个根本不对的文件名照样补了也启动不了。ISC DHCP服务的配置里关键参数是next-server和filename。一个典型且能兼容多数PXE客户端的配置片段如下subnet 192.168.1.0 netmask 255.255.255.0 { range 192.168.1.100 192.168.1.200; next-server 192.168.1.10; filename pxelinux.0; }如果你的环境中还跑着其他DHCP服务比如路由器自带的、Windows Server自带的或者用dnsmasq搭的也要逐一检查。dnsmasq里的写法是dhcp-range192.168.1.100,192.168.1.200,12h dhcp-optionoption:router,192.168.1.1 dhcp-bootpxelinux.0,192.168.1.10改完配置后重启DHCP服务然后重启一台客户端测试。这里有个细节客户端PXE ROM本身有缓存你可能需要在客户端关机后拔掉网线再插上或者彻底断电再开机否则测试结果不一定准。3.3 rootnfs挂载超时根文件系统不可达当PXE引导成功、内核也加载完成之后下一步是挂载根文件系统。对于采用NFS作为根文件系统的无盘方案这一环节出了问题提示往往不再是“please reboot and try again”而是内核打印一大段网络和文件系统错误最后停在Kernel panic - not syncing: VFS: Unable to mount root fs这里。但为什么我要在讨论这个报错时也提NFS因为在PXE环境里很多朋友会把NFS的配置错误和前面PXE的错误混在一起排查结果走了弯路。NFS挂载失败最常见的三个原因第一NFS服务没启动或者在重启服务器后忘了将其设为开机自启。检查命令systemctl status nfs-server第二exports文件配置错误。比如客户端网段写错导致挂载请求被拒绝。一个可用的exports配置示例/nfsroot 192.168.1.0/24(rw,sync,no_root_squash,no_subtree_check)第三内核启动参数里的NFS路径写错了。常见错误包括IP地址写错、路径写错、漏写挂载协议。下面是一个相对完整可用的内核参数示例root/dev/nfs nfsroot192.168.1.10:/nfsroot,nfsvers4 ipdhcp rw建议先在服务器上手工mount一遍确认NFS目录本身可访问再去查客户端启动参数。3.4 固件与文件架构不匹配UEFI和32/64位这个坑在近几年的机房里越来越常见因为老机器的BIOS启动和新机器的UEFI启动用的是完全不同的启动文件。传统BIOS启动时PXE ROM下载的是pxelinux.0而UEFI环境下PXE ROM通常只认EFI程序比如bootx64.efi或grubx64.efi。如果你在UEFI客户端上配置了传统BIOS的bootfile客户端下载下来的文件格式不对PXE ROM同样会陷入“panic”状态最终报出类似“please reboot and try again”的提示。处理方法是分别建立两套PXE启动配置。对于UEFI环境用grub2提供的EFI文件或者用ipxe的EFI版本。同时要注意架构匹配x86_64的UEFI客户端必须用64位EFI程序ARM架构的客户端则需要对应的固件。有个小技巧DHCP服务器可以根据客户端PXE ROM发送的Option 60和Option 93来区分请求类型从而分发不同的启动文件。ISCDHCP里可以用class匹配来实现配置示例如下class pxeclients { match if substring (option vendor-class-identifier, 0, 9) PXEClient; filename pxelinux.0; next-server 192.168.1.10; }如果你已经在生产环境里跑UEFI和BIOS的混合机型强烈建议尽早建立两套完全独立的PXE启动入口不要图省事把所有客户端都指向同一个文件。4. 踩坑实录与速查表那些年我处理过的真实案例4.1 案例复盘文件名大小写差点让我重装系统有一回接到一个无盘网吧老板的电话说所有客户机开机都是“please reboot and try again”。我到现场后发现TFTP服务正常、DHCP也正常手动用tftp命令下载pxelinux.0也成功。百思不得其解后来在客户端屏幕上一秒闪过的调试信息里看到了GET /pxelinux.0返回File Not Found的字样。我回到服务器上查看发现TFTP根目录下有一个文件叫Pxelinux.0大写P开头。手动用tftp下载时我敲的是全小写系统居然也返回了200不对仔细一看tftp客户端当时下载到的其实是另一个同名冲突的文件或者更准确地说是服务器上存在两个TFTP服务监听在不同端口我测试的是另一个。这类问题排查起来最浪费时间。所以务必记住PXE环境里文件名严格区分大小写配置里写什么就必须是什么。统一小写能少很多麻烦我自己后来的脚本里都会加上一句unified to lowercase的说明。案例复盘结论先把所有启动相关文件名统一改小写配置文件里也同步改成小写删除TFTP目录下的同名冲突文件保证只有一个数据源。4.2 案例复盘防火墙静默丢弃UDP包最难排查还有一个案例让我印象极深。那次问题只在少数几台机器上出现其他机器全部正常。正常机器和异常机器还是同一个型号只是接在不同交换机上。后来排查交换机配置发现这两台交换机上针对UDP 69端口的ACL策略不一样异常客户端所在的交换机把UDP 69的访问全部丢弃了导致TFTP请求无法到达服务器。我为什么会对这个案例印象深因为防火墙和ACL策略导致的UDP超时客户端那边不会立刻报错而是反复重试到最终放弃时已经过去了接近一分钟用户体感就是等待很久后弹出一个“please reboot and try again”。排查这种问题最好的工具是抓包。在TFTP服务器上执行tcpdump -i eth0 -n port 69 -XX如果发现只有客户端发出的TFTP RRQ请求却没有任何来自服务器的响应或ACK包那几乎可以判定是中间链路把UDP包丢弃了。顺着交换机ACL、服务器防火墙一层层去找比反复重启客户端高效得多。4.3 故障速查表看到现象直接对表找方向经验多了以后我发现很多排查动作是可以固化成速查表的。下面这个表是我自己办公桌玻璃垫下压着的一张“救命卡”遇到类似故障先对表再动手。现象/观察点优先排查方向常见根因解决手段PXE ROM提示无IP地址DHCP服务、交换机SnoopingDHCP服务未启动/端口被ACL丢弃重启DHCP服务检查交换机策略屏幕一闪而过报错且能看到IPTFTP下载、文件路径、文件权限启动文件不存在/权限不足/TFTP服务异常补充文件、修改权限、重启服务能进入bootloader但找不到内核pxelinux.cfg文件、内核文件路径配置文件缺失/文件名匹配错误核对default和label配置内核加载完卡在挂载根文件系统NFS服务、exports导出、防火墙NFS未启动/目录未导出/防火墙拦截修正exports放行端口UEFI机器无法PXE引导EFI启动文件、DHCP的bootfilebootfile配置成了BIOS版文件区分UEFI和BIOS配置两套入口这张表并不能覆盖所有场景但它能帮你快速排除掉最高概率的问题剩下的小概率问题再靠抓包和日志去深挖。5. 从救火到防火无盘启动环境的日常维护建议5.1 搭建一套最小可用PXE目录标定“健康基线”很多人搞了几年无盘环境却没有一套标准的文件目录基线。出了故障之后连“原本应该有哪些文件”都说不清楚只能靠比正常机器来猜。我强烈建议你在每台PXE服务器上整理出一份清单记录TFTP目录下应有的关键文件和对应权限最好再写一个校验脚本定期比对。我自己惯用的目录结构长这样/var/lib/tftpboot/ ├── pxelinux.0 ├── vmlinuz ├── initrd.img ├── bootx64.efi └── pxelinux.cfg/ └── default一个最简单的健康基线检查脚本可以这样写#!/bin/bash TFTP_DIR/var/lib/tftpboot for f in pxelinux.0 vmlinuz initrd.img; do if [ ! -f $TFTP_DIR/$f ]; then echo MISSING: $f fi done脚本不用写得复杂关键是定期跑、出结果就处理。很多故障其实在爆发之前就已经露出了端倪只是没人注意到。5.2 维护记录和升级习惯避免二次翻车无盘环境的维护还有一个容易被忽视的点每次升级内核、更新服务器系统或更换镜像之后都要同步检查PXE目录里的文件是否匹配。内核升级后/boot/vmlinuz和initrd.img的版本会发生变化如果你还在用旧名字复制新文件启动时可能因为内核模块不匹配或initrd缺驱动而卡住。我的习惯是每次升级后手动做一次完整的PXE开机测试用一台专门的测试终端从头走到登录界面而不是直接把所有生产客户端重启一遍。这个测试流程虽然简单但能拦截掉一大批因为版本不同步引发的启动问题。顺便说一句测试终端最好和实际生产终端同型号、同固件版本否则UEFI启动文件的差异测不出来。跑运维这些年我最大的体会是无盘环境里没有所谓的“灵异事件”所有报错背后都有一条清晰的逻辑链条。只要肯按链路逐个排查再顽固的“please reboot and try again”也能被揪出来。希望这篇文章能帮你少熬几个通宵更希望你在下次遇到类似报错时第一反应不是“又要背锅了”而是拿起工具从DHCP和TFTP开始一步步找到真相。