/boot分区不足和“mdadm: /etc/mdadm/mdadm.conf defines no arrays”报错，本质上是磁盘空间管理和RAID配置初始化两个独立问题，但常在系统更新或迁移后同时爆发，先清理系统残留内核并重新生成mdadm.conf，再根据磁盘布局决定是扩容还是迁移，这是最稳妥的解决路径。
问题典型场景：服务器重启后的连环报错
一台用于生产环境的服务器，在经历了一次系统内核升级后，重启时出现了异常，登录系统后，终端提示“/boot分区使用率已达100%”，运行软件包更新时又弹出“W: mdadm: /etc/mdadm/mdadm.conf defines no arrays”，这两条信息同时出现,让很多运维人员一时摸不着头脑。
先明确一点：这不是硬件故障，而是系统配置层面的两个“坑”。/boot分区写满，通常是因为旧内核文件没有被自动清理，而mdadm.conf文件丢失或为空,则意味着软件RAID的配置信息没有被正确加载。
排查顺序：先看磁盘，再查RAID配置
遇到这类问题,我的习惯是先用一条命令快速定位磁盘占用情况：
df -hT
重点查看/boot分区的挂载点和已用百分比，如果使用率接近100%，那就直奔主题清理文件，查看/etc/mdadm/mdadm.conf文件的内容：
cat /etc/mdadm/mdadm.conf
正常情况下，这个文件里应该包含ARRAY和MAILADDR等定义行，如果文件为空，或者只有几行注释，就会触发“defines no arrays”的警告，这个警告的直接后果是：系统无法通过配置文件自动组装RAID阵列，一旦重启后遇到阵列降级或掉盘，系统可能无法自动恢复,甚至出现无法挂载根文件系统的严重情况。
清理/boot分区：给系统“瘦身”的实操步骤
/boot分区写满的元凶，绝大多数是残留的旧内核文件，每一次内核升级，都会在/boot下生成vmlinuz、initramfs、System.map等文件，系统默认只保留最新的几个版本，但部分第三方源或手动安装的内核包会被遗漏,久而久之空间就被蚕食殆尽。
先看看当前正在使用的内核版本：
uname -r
记住这个版本号，后面清理时一定要避开它,查看系统里安装了哪些内核包：
rpm -qa | grep kernel # CentOS/RHEL系列 dpkg --list | grep linux-image # Debian/Ubuntu系列
以CentOS为例，清理旧内核最稳妥、最标准的方式是用yum或dnf插件，而非直接rm文件,因为rpm包管理器的依赖关系需要被正确维护。
使用yum-autoremove或者package-cleanup工具：
yum install yum-utils -y package-cleanup --oldkernels --count=2
这里--count=2的含义是保留最近两个版本的内核，如果你担心误删，可以先手动删除再更新grub配置,手动操作路径：
- 在/boot目录下列出所有内核文件,找到与当前内核版本不同的旧版本号。
- 删除对应的四个文件：vmlinuz-旧版本、initramfs-旧版本.img、System.map-旧版本、config-旧版本。
- 执行
grub2-mkconfig -o /boot/grub2/grub.cfg刷新引导菜单。
清理完成后，/boot空间会释放出几百MB到1GB不等，这取决于积累了多少旧内核，如果空间仍然紧张，还可以检查/boot下是否有其他大文件，比如系统崩溃时留下的vmcore文件，这类文件体积较大,可以直接删除。
修复mdadm.conf：重建RAID定义的关键一步
/boot清理完毕，接下来处理mdadm.conf，这个文件的作用，是记录软件RAID的阵列成员磁盘、UUID和元数据版本，当系统启动时，mdadm --assemble --scan命令会读取这个文件,自动组装处于非活动状态的阵列。
文件为空的原因,常见的有几种：
- 初始安装系统时没有配置RAID,文件本身就是空的。
- 有人手动编辑过该文件,但未保存成功。
- 磁盘阵列信息发生了变化,旧的定义已失效。
“defines no arrays”这个警告，核心含义是：操作系统在启动过程中找不到任何有效的RAID定义,因此所有MD设备都不会被自动激活。
重新生成mdadm.conf，标准做法是用mdadm命令扫描当前已激活的阵列信息：
mdadm --detail --scan >> /etc/mdadm/mdadm.conf
这条命令会把当前MD设备的UUID和成员磁盘信息追加写入配置文件，执行前,务必确认当前阵列已经是active状态：
cat /proc/mdstat
如果输出中显示类似“md0 : active raid1 sda1[0] sdb1[1]”的内容，说明阵列工作正常，直接执行上述命令即可，如果阵列处于inactive状态,则需要先手动组装：
mdadm --assemble --scan
在修改文件之后，还有一个细节容易被忽略：更新initramfs镜像，因为mdadm.conf在引导早期阶段就会被读取，而initramfs里可能会打包一份旧配置,重新生成initramfs：
mkinitrd -f /boot/initramfs-$(uname -r).img $(uname -r)
重新生成后重启系统,警告便会消失。
根因分析：两个问题为何常常“结伴而行”
在实际排查中，我发现这两个报错同时出现的频次并不低，原因在于：在运行yum update或dnf update时，系统会同时更新内核包和mdadm工具包，内核更新会触发/boot分区写入新文件，mdadm升级则可能改写配置文件，如果此时/boot空间已满，内核安装会部分失败，而mdadm的新配置又未能正确生成,就会同时留下这两个隐患。
另一个常见场景是服务器硬件迁移，比如将整块系统盘从一台机器挂载到另一台，新主机的udev规则和磁盘UUID如果与原系统不一致，mdadm.conf中的定义可能无法正确匹配，此时系统会自动清空或跳过配置文件,导致同样的问题。
行业共识认为，出现这类配置类故障，优先考虑恢复配置文件，而非急于重装系统，重装是最后手段,因为业务数据迁移成本和停机时间代价很高。
服务器测评角度：哪种磁盘布局能规避这类问题
作为一名长期处理服务器问题的运维人员，我的经验是，这类问题在特定磁盘分区方案下更容易触发,对比两种常见布局：
| 分区方案 | 是否易出现/boot不足 | 是否有mdadm.conf风险 | 适用场景 |
|---|---|---|---|
| /boot独立分区（默认） | 较容易，空间通常仅1GB | 中，RAID1时配置需正确 | 传统BIOS引导的服务器 |
| /boot/efi（EFI分区） | 较少，更新频率低 | 低，配置较简单 | UEFI引导的现代服务器 |
| /boot与LVM结合 | 较容易，受LVM大小限制 | 高，LVM在RAID上叠加时 | 老系统改造、扩展场景 |
从服务器测评角度看，如果你的服务器是UEFI引导，且使用LVM管理根文件系统，我建议将/boot也并入LVM逻辑卷，这样可以在空间不足时用lvextend轻松扩容，从根本上避免“满了才去清理”的被动局面。
但是如果你的服务器是传统BIOS引导，且内核更新频繁，预留2GB以上的独立/boot分区是更省心的选择，毕竟,一块大硬盘的成本远远低于一次半夜的紧急故障处理。
实操中容易踩的坑：保留内核版本数别压太低
清理旧内核时，很多人为了腾空间，把保留版本数设为1，即只保留当前内核，这样做看似省空间，实则隐患极大，如果新内核存在驱动兼容性问题，你需要回滚旧内核时，原内核已经被删除,系统就无法正常引导。
业内专家指出，生产环境至少保留两个版本的内核：一个是当前正在运行的最新版本，另一个是上一个确认稳定的版本，这也是我在所有自动化清理脚本中，将--count参数设为2的原因。
临时救急手法：空间严重不足时的备选方案
boot空间已经满到无法执行任何软件包操作，连yum install都报错,可以先挂载一个临时文件来缓解？
一个临时手段是：删除/boot下最新的initramfs文件（前提是你有一个备份或者能重建），然后立刻执行yum reinstall kernel -y，让包管理器重新生成完整文件，另一种做法是，从另一台同版本系统的机器上拷贝一个initramfs文件，但这种方式涉及内核模块匹配问题，只能用来应急启动,不推荐长期使用。
最稳妥的临时放法是挂载一个额外的存储空间，但这对服务器硬件有要求，我的建议是，在部署新机器时，直接把/boot分区设置为2GB，这个容量对一般企业服务器来说,足以支撑5年以上的内核升级周期。
事后的预防：定期检查与自动化脚本
处理完问题后，建议写一个简单的定时任务，每周检查一次/boot空间使用率,脚本逻辑不算复杂：
#!/bin/bash
# 每周末检查 /boot 使用率，超过80%时自动清理旧内核
THRESHOLD=80
USE_RATE=$(df -h /boot | tail -1 | awk '{print $5}' | sed 's/%//')
if [ "$USE_RATE" -gt "$THRESHOLD" ]; then
package-cleanup --oldkernels --count=2 --assumeyes
fi
把这个脚本放到/etc/cron.weekly/目录下，就能在无人值守的情况下自动处理空间告警，同理，也可以在脚本末尾加上一条命令检查mdadm.conf是否为空,为空时自动重建：
if [ ! -s /etc/mdadm/mdadm.conf ]; then
mdadm --detail --scan > /etc/mdadm/mdadm.conf
fi
数据迁移场景中的额外考量
如果你的服务器原本是RAID1，后续由于数据量增长，先从软件层将阵列迁移到了新的硬件阵列卡上，那么mdadm.conf完全清空是正常的，不再需要软件RAID定义，此时直接删除或注释掉mdadm相关的启动脚本,也能让警告消失。
不过删除前，需确认系统根目录确实已经不在软件RAID上，否则重启后会出现无法挂载根文件系统的问题，这种场景下，验证方法是在修改前执行mount | grep md,查看是否有任何分区依赖MD设备。
Q&A：围绕“/boot不足”与mdadm报错的常见疑问
Q1：/boot分区出现不足，能否直接把新内核安装到根目录或/home目录？
不建议这样做，引导加载程序（GRUB）在BIOS模式下访问分区的能力与根文件系统的驱动加载顺序不匹配，内核安装在非/boot路径上，GRUB无法在系统启动早期读取到该文件，会导致无法引导进入系统，正确做法是给/boot分区扩容,或者删除旧内核文件腾出空间。
Q2：mdadm.conf文件始终提示defines no arrays，但系统中确实有RAID阵列在工作，这是为什么？
可能的原因是该文件被只读方式保护或修改被恢复了，在系统运行时执行mdadm --detail --scan能输出阵列信息，说明内核中的MD设备是正常的，但如果该文件在initramfs内部被旧版本覆盖，重启后警告会依然存在，需要重新生成initramfs，并确保在grub配置中加载了正确的rd.md.conf参数。
Q3：修复mdadm.conf后执行mdadm –detail –scan，出现“no arrays found”提示，这意味着什么？
说明当前系统中没有任何已激活的软件RAID阵列，如果你的磁盘确实组过阵列，且数据仍然存在，不要慌乱，先查看/etc/mdadm/mdadm.conf中是否曾经有过ARRAY定义记录，或者检查/proc/mdstat是否为全空状态，如果数据分区没有挂载，尝试用mdadm --examine --scan扫描所有磁盘，找到具有RAID元数据的磁盘后手动组装，如果之前使用的是硬件RAID，则与mdadm无关,该提示属正常现象。
首发原创文章，作者：王坚，如若转载，请注明出处：https://idctop.com/article/668885.html
