莱夢/boot 独立分区空间不足，是 Linux 服务器运维里最常见也最容易被忽略的老问题。系统跑着跑着，内核一升级，/boot 立马就满，yum update 甚至 apt upgrade 都可能直接报 No space left on device，搞不好服务器重启都进不了系统。我这些年处理过不少类似的故障，也见过很多同事一上来就准备重装系统，其实只要搞清楚 /boot 分区结构、内核清理逻辑和扩容工具的用法，这个问题完全可以在线化解。这篇就把完整的排查、救急和扩容流程都写出来，给被 /boot 折磨过的朋友，也给刚入门的运维新人一个可照抄的作业。
1. 为什么/boot总是空间不足？先搞清楚问题根源
1.1 一个几百MB分区的“慢性死亡”
传统 Linux 安装习惯会把 /boot 单独分出来，尤其是 CentOS/RHEL 系列，安装器默认就给 /boot 分配 500MB 到 1GB。这个容量在新装系统时看起来够用，但内核迭代几次之后就开始紧张。一个内核要装三样东西：vmlinuz（内核本体）、initramfs/initrd（初始内存盘）、System.map 和 config 文件，一套下来大概 40 到 80MB。发行版默认保留 2 到 3 个旧内核，再加上偶尔升级失败没清理的残留，300GB 的根分区没事，500MB 的 /boot 却先满了，这几乎是必然发生的事情。
还有一个容易忽略的点：/boot 不仅是内核文件的家，还承载着 grub 引导配置、grub 的残留模块、内存测试工具 memtest 等。有些机器上 /boot 里还混着旧版本内核卸载不干净留下的 .rpmnew 或 .dpkg-old 文件，这些东西单个看不大，累积起来也很可观。df -h 看的时候 /boot 使用率 100%，但 du -sh /boot/* 一查，往往能发现一堆早就该被清理却一直没被清理的配置文件。
1.2 为什么说它“难扩”
/ boot 独立分区难扩展，本质是分区布局问题。传统 MBR 或 GPT 磁盘上，/boot 通常位于磁盘靠前的位置，后面紧跟着根分区或其他分区。要给 /boot 扩容，必须满足三个条件之一：后面有空闲空间、后面分区能缩小、或者能在分区表里重新排列。问题是根分区正在被系统使用，没法在线缩小，这就让“原地扩容”变得很困难。
更麻烦的是，很多服务器当初安装时并没有预留连续的空闲空间，/boot 前后都被别的分区“夹住”。这种情况下，必须借助 Live 环境（比如 GParted Live、SystemRescueCD、Ubuntu 安装盘）启动系统，再对分区表进行操作。听起来有点复杂，但操作路径其实很固定：先备份，再缩小后面的分区，腾出空间，然后扩展 /boot，最后修复引导。整个过程只要按顺序来，成功率非常高。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 扩容前必做：先把“软性空间”挤出来
2.1 清理旧内核：最立竿见影的急救措施
如果你暂时没法重启服务器，也没有维护窗口，最现实的急救方案是清理旧内核。这一步往往能瞬间释放一两百MB空间，让系统先恢复元气。CentOS/RHEL 系的操作：
bash复制# 查看当前正在使用的内核
uname -r
# 列出系统已安装的内核
rpm -qa | grep ^kernel-
# 删除旧内核（把具体的旧版本号换成实际值）
yum remove kernel-3.10.0-1160.el7.x86_64 kernel-3.10.0-1127.el7.x86_64
删除之后需要重新生成 grub 配置：
bash复制grub2-mkconfig -o /boot/grub2/grub.cfg
Debian/Ubuntu 系则是这样：
bash复制# 查看当前内核
uname -r
# 列出所有已安装的内核镜像
dpkg --list | grep linux-image
# 删除旧内核（注意不要把当前内核删了）
apt purge linux-image-5.4.0-26-generic
Ubuntu 会自动帮你跑 update-grub，但如果你用 dd 方式安装的 grub，建议还是手动再确认一遍引导配置。清理动作一定要看准 `uname