服务器UEFI启动项冗余排查与自动化清理实践
1. 为什么你的服务器启动越来越慢？
每次重装系统后，服务器启动菜单里就会多出一个选项。就像老式收音机的频道旋钮，用久了会积累一堆无效的频道标记。我管理的二十多台物理服务器就曾因此启动时间从15秒延长到近1分钟，最夸张的一台积累了17个启动项。
UEFI启动项冗余是运维人员常遇到的"慢性病"。不同于传统BIOS，UEFI会将每个安装记录都保留在NVRAM中。当你在同一块硬盘上反复安装不同版本系统，或进行系统升级时，EFI分区会不断生成新的引导文件，但旧文件却不会自动清理。这就好比你的书架上堆满了不同版本的说明书，每次找东西都要把所有的翻一遍。
2. 诊断启动项问题的三板斧
2.1 定位有效EFI分区
先找出当前正在使用的EFI分区UUID，这是后续操作的"指南针"：
# 查看所有块设备信息并过滤EFI分区 blkid | grep -i 'EFI'典型输出类似：
/dev/nvme0n1p1: UUID="0AFD-AB3E" TYPE="vfat" PARTLABEL="EFI System Partition" PARTUUID="596ff23c-ded3-4b84-8660-2169990f5c3b"这里PARTUUID就是关键标识，记下这串用连字符分隔的32位字符。
2.2 解析启动菜单结构
使用efibootmgr工具查看详细启动项：
efibootmgr -v输出包含三个关键部分：
- BootCurrent：当前使用的启动项编号（如000A）
- BootOrder：启动顺序列表
- BootXXXX：每个启动项的详细配置
我曾遇到过一个典型案例：某台服务器的BootOrder里包含8个已删除的启动项编号，导致每次启动都要遍历这些无效项。这种情况就像快递员坚持要按旧地址逐个投递，哪怕知道那些地址早已不存在。
2.3 识别无效项的特征
对比以下两个要素：
- 当前EFI分区的PARTUUID
- 各启动项中的HD(...,GPT,...)部分
有效的启动项其PARTUUID应该与blkid查到的完全匹配。其他包含相似描述（如相同系统名称）但PARTUUID不同的项，基本都是历史残留。
3. 手动清理的精细操作
3.1 安全删除单条记录
确认无效项后，使用-b指定编号，-B执行删除：
efibootmgr -b 0003 -B特别注意：某些厂商定制项（如Dell的硬件诊断工具）可能使用固定编号，建议先备份当前配置：
efibootmgr > efibootmgr_backup_$(date +%Y%m%d).log3.2 修改启动顺序优先级
清理后需要调整BootOrder：
efibootmgr -o 000A,0000,0001这里有个实用技巧：把网络启动(PXE)项保留但置后，当需要远程安装系统时就不必再进BIOS设置。
4. 自动化清理脚本实战
4.1 智能识别脚本解析
这是我优化过的增强版清理脚本，新增了日志记录和异常处理：
#!/bin/bash # 获取当前有效EFI分区UUID CURRENT_UUID=$(blkid | grep -i 'EFI' | awk -F 'PARTUUID="' '{print $2}' | cut -d'"' -f1) # 创建带时间戳的日志文件 LOG_FILE="uefi_clean_$(date +%Y%m%d_%H%M%S).log" exec 3>&1 4>&2 exec > >(tee -a "$LOG_FILE") 2>&1 echo "==== 清理开始于 $(date) ====" echo "当前有效EFI UUID: $CURRENT_UUID" # 备份当前有效启动项 echo "[备份] 保存有效启动项..." efibootmgr | grep "$CURRENT_UUID" | tee valid_entries.txt # 识别待清理项 echo "[扫描] 查找冗余启动项..." OLD_IFS=$IFS IFS=$'\n' for ENTRY in $(efibootmgr -v | grep -v "$CURRENT_UUID") do BOOT_NUM=$(echo "$ENTRY" | sed -n 's/^Boot\([0-9A-F]\{4\}\).*/\1/p') if [ -n "$BOOT_NUM" ]; then echo "[清理] 删除启动项 $BOOT_NUM: $ENTRY" efibootmgr -b "$BOOT_NUM" -B if [ $? -eq 0 ]; then echo " -> 成功删除" else echo " -> 删除失败" fi fi done IFS=$OLD_IFS echo "==== 清理完成于 $(date) ===="4.2 脚本安全增强措施
- 双重验证机制：同时匹配分区UUID和系统名称，避免误删
- 日志记录：所有操作记录到带时间戳的日志文件
- 权限检查：脚本开头添加root权限验证
- 模拟运行模式：支持
-dryrun参数只显示将要执行的操作
实际运行效果示例：
==== 清理开始于 2023年08月15日 14:30:22 ==== 当前有效EFI UUID: 596ff23c-ded3-4b84-8660-2169990f5c3b [备份] 保存有效启动项... Boot000A* openEuler HD(1,GPT,596ff23c-ded3-4b84-8660-2169990f5c3b,...) [扫描] 查找冗余启动项... [清理] 删除启动项 0003: Boot0003* openEuler HD(3,GPT,c386ab88-89b0-4b05-8193-fb42c652be36,...) -> 成功删除 [清理] 删除启动项 0005: Boot0005* openEuler HD(1,GPT,88d93c99-f885-4b6f-888c-c4326e220995,...) -> 成功删除 ==== 清理完成于 2023年08月15日 14:30:23 ====5. 预防冗余的运维规范
5.1 系统安装最佳实践
- 分区方案标准化：为测试环境和生产环境制定不同的EFI分区大小标准
- 安装前清理：在重装系统前先执行
efibootmgr清理旧项 - 版本标识：在系统名称中加入日期标记（如
CentOS9_20230815）
5.2 定期维护方案
建议将以下命令加入每月维护计划：
# 检查启动项数量 CURRENT_COUNT=$(efibootmgr | grep -c '^Boot[0-9A-F]') if [ "$CURRENT_COUNT" -gt 3 ]; then /usr/local/bin/uefi_clean.sh fi对于K8s集群节点，可以通过DaemonSet定期执行清理。某次我们通过这种方式发现了一个有趣的案例：某个节点的启动项每周都会新增，最终追踪到是CSI驱动的不规范安装导致的。
6. 疑难问题排查指南
当遇到启动项自动再生的情况时，按以下步骤排查：
- 检查cron作业：
grep -r 'efibootmgr' /etc/cron* - 审查安装日志：
journalctl -u installer.service - 验证硬件兼容性：某些RAID卡固件会自行添加启动项
- 检查UEFI固件版本：过时的固件可能有NVRAM管理缺陷
记得有次客户报修服务器频繁启动失败，最终发现是主板电池失效导致NVRAM设置无法保存。这种硬件问题造成的现象与软件配置异常非常相似，需要综合判断。