Linux /boot分区扩容实战：LVM与传统分区方案全解析-代码聚汇网

Linux /boot分区扩容实战：LVM与传统分区方案全解析

/boot分区Linux扩容

|难度：普通|阅读约 36 分钟

1. /boot分区为什么总是不够用：先弄明白空间去了哪里

说实话，玩Linux这么久，我最怕的不是某个服务起不来，而是那种“一不小心就把系统搞进不去”的存储问题。/boot分区空间不足，看着不像大事，但真到内核升级失败、grub写不进新配置的时候，那叫一个难受。最近帮朋友处理一台服务器，/boot只有可怜的300MB，某次内核批量更新直接提示“磁盘空间不足”，新内核装不进去，旧内核又不敢乱删，整个系统卡在中间状态。这篇文章我就把/boot扩容这件事从头到尾梳理一遍，讲讲我踩过的坑、总结出来的方案，以及每一步背后的原因。

先说清楚/boot分区到底是干什么的。从Linux的启动流程来看，机器通电后BIOS/UEFI固件去读取启动设备，找到引导程序，比如GRUB2，再让GRUB加载内核镜像和initramfs到内存，最终把控制权交给操作系统。而/boot这个独立分区，就是专门存放这些启动所需的文件：vmlinuz（内核本体）、initramfs/initrd（初始内存盘）、grub配置目录、内核符号表System.map等。由于引导程序（尤其是传统BIOS+MBR模式下）对磁盘的访问能力有限，/boot放在磁盘靠前位置、保持小而规整，是历史遗留也是稳定性考量。

1.1 /boot分区到底存了些什么

你可以先在自己的机器上看看/boot目录的内容：

bash复制ls -lh /boot

我随便贴一份典型的输出：

bash复制total 120M
-rw-r--r-- 1 root root  47M May 10 10:00 vmlinuz-5.14.0-362.13.1.el9_3.x86_64
-rw-r--r-- 1 root root  62M May 10 10:00 initramfs-5.14.0-362.13.1.el9_3.x86_64.img
drwxr-xr-x 2 root root   4K May 10 10:00 grub2
-rw-r--r-- 1 root root  36M May  5 09:00 vmlinuz-5.14.0-362.8.1.el9_3.x86_64
-rw-r--r-- 1 root root  57M May  5 09:00 initramfs-5.14.0-362.8.1.el9_3.x86_64.img

你看，光是两套内核加上对应的initramfs，就已经轻松超过200MB。如果再算上grub2目录里的grub.cfg、字体文件、模块，以及可能存在的旧内核备份，一个500MB的分区装三套内核后就非常吃紧。这也是为什么很多发行版默认/boot只给200-500MB，平时够用，但只要内核频繁更新、又不及时清理旧版本，空间就会迅速告急。

initramfs是另一个“空间杀手”。这个文件本质上是启动时用到的临时根文件系统，里面打包了磁盘控制器驱动、文件系统驱动、lvm2工具、dm-crypt等模块。随着内核版本迭代，驱动模块越来越多、体积越来越大，initramfs从早期的十几MB膨胀到现在的50-80MB都很正常。如果你机器上有多个内核，每个内核都配一个50-80MB的initramfs，再叠加vmlinuz本体，空间消耗的速度远超你的直觉。

1.2 空间不足的常见触发场景

我见过太多人栽在这几个场景里：

第一个是长期不清理旧内核。CentOS/RHEL系默认不会自动删除旧内核，Ubuntu虽然偶尔会提示，但也不会主动清。系统更新三五次后，/boot里躺着四五套内核，分区直接爆掉。

第二个是一键更新工具或脚本没有判断空间。比如某些云平台的批量升级脚本，yum update或者apt upgrade时一口气下载了所有新内核，结果安装在写入/boot时发现空间已经满了，升级失败，系统处于“半更新”状态。这种状态最难收拾，因为包管理器可能已经改了部分依赖，你再手动装内核容易冲突。

第三个是恢复模式或救援模式产生的额外文件。比如你用grub2-mkconfig重新生成配置、手动把内核复制出来做备份、或者是某些安全加固脚本往/boot塞了额外的校验文件，都会加速空间消耗。

第四个容易被忽略的是/boot分区文件系统本身的特点。如果/boot用的是XFS，某些操作还涉及日志空间预留；如果是ext2/ext4，默认还会为root用户保留5%的空间（mke2fs的-m参数），300MB的分区实际可用可能只有285MB。你查df的时候看着数字还有几十MB，但真正写入大文件时却“No space left on device”，多半就是被这个保留块卡住了。

需要模型API调用？免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。

2. 扩容前必做的准备：把系统状态摸清楚再动手

遇到/boot空间不足，我见过不少人上来就fdisk乱搞，最后把系统搞崩，只能重装。分区层面的操作，最忌讳“想当然”。动手之前，先花十分钟把现状彻底搞清楚，这一步做扎实了，后面90%的坑都能避开。

2.1 先用这几条命令确认现状

先看文件系统使用率：

bash复制df -hT /boot

-T可以显示文件系统类型，这非常重要。ext4和XFS的扩容命令完全不同，后面我会细说。

再看分区和磁盘的整体布局：

bash复制lsblk

lsblk输出会清晰展示磁盘、分区、LVM逻辑卷之间的层级关系。我建议重点关注/boot在哪个分区、这个分区的前后有没有空闲空间、后面的空间是属于哪块磁盘的。

然后用blkid确认所有分区的UUID和文件系统类型：

bash复制blkid

注意，/boot分区操作完之后，UUID不能变（用resize2fs、xfs_growfs扩展文件系统不会改变UUID），但如果你用GParted移动或复制分区，UUID可能发生变化，这会直接导致GRUB找不到/boot。所以操作前把UUID记录下来，万一出问题还有据可查。

如果系统用了LVM，还要看卷组和逻辑卷的信息：

bash复制pvs
vgs
lvs
lvdisplay
vgdisplay

这三件套能让你快速判断：/boot到底是在LVM里，还是在传统分区里；卷组还有没有空闲的物理区块（Physical Extent, PE）；逻辑卷的路径是什么。

我自己的习惯是把这些命令的完整输出保存到一个临时文件里，比如/tmp/boot_status.txt，方便前后对照。这一步不是形式主义，因为后面扩容完成后你要对比验证，没有原始记录两眼一抹黑。

2.2 备份和风险评估

说实话，分区扩容这件事，风险高低完全取决于/boot所在的位置和它前后的邻居是谁。我把常见情况按风险从低到高排了个序，你自己对照：

场景	扩容方式	风险等级	说明
/boot在LVM逻辑卷中，卷组有剩余空间	LVM在线扩展	低	可在线操作，不影响业务
/boot是传统分区，磁盘末尾有未分配空间	在线或离线扩展分区	中	需要扩展分区表，最好离线或live环境
/boot是传统分区，后面紧挨着LVM PV或/分区	需要移动/缩小后续分区	高	必须先把后面分区的数据挪走或缩小，强烈建议live环境+完整备份
/boot是传统分区，前面有未分配空间	需要移动分区起始位置	极高	所有分区都往后挪，几乎等于重构磁盘布局，不推荐

我在实际操作中碰到最多的就是第三种：/boot是独立小分区，紧跟其后的是LVM的物理卷（PV），整个系统的大部分数据都在LVM里。你想扩大/boot，就得先缩LVM PV的尾巴，腾出空间，再把/boot分区往后扩展。这个操作理论上可以不停机完成，但PV缩小本身就比较敏感，一旦断电或者命令参数写错，数据丢失的风险很大。所以这种场景我强烈建议：

先做一份完整备份。生产环境至少要有整盘镜像或者关键数据快照，个人电脑退一步，至少把/etc、/home、数据库文件备份好。
准备一个Live USB或救援系统。推荐用系统同发行版的Live镜像，或者专门的分区工具GParted Live。离线环境下操作，能避开文件系统被占用的问题，心态也稳很多。
操作前记录所有分区的起始和结束扇区号，用fdisk -l或者parted print，万一操作失败还能手动恢复分区表。

提示：分区操作前，除了数据备份，还要把/boot目录下的文件做一份拷贝到外部存储。比如tar czf /backup/boot_backup.tgz /boot。这样即使GRUB配置损坏，也能在救援环境里把/boot内容恢复回来。

3. 方案选择：三种扩容路径各有适用场景

没有一种扩容方案能通吃所有情况。这一步最关键的是先搞清楚/boot在LVM里还是在普通分区里，然后根据磁盘布局选路线。我见过有人明明是LVM场景，却用GParted去调分区，结果把LVM元数据搞坏；也有人明明是传统分区，非要折腾在线lvextend，命令报错才回头。先选对路，比努力操作更重要。

3.1 方案适用性对比表

方案	适用条件	是否需要离线	是否需要Live USB	推荐指数
LVM在线扩容	/boot是LV，VG有剩余空间	不需要	不需要	五星
清理旧内核	空间只是暂时紧张，还能删除旧内核	不需要	不需要	四星，但治标不治本
GParted图形化调整	传统分区，且磁盘有空闲空间	强烈建议	需要	四星
缩小LVM PV再扩/boot	传统分区，后面是LVM PV且没空闲空间	可在线但风险高	建议	三星
新磁盘挂载替代/boot	原/boot实在没法扩，或机器可以加硬盘	不需要	不需要	三星，适合虚拟机/云主机

3.2 如果/boot在LVM里：在线扩容最省事

现代很多发行版，尤其是RHEL 8+、Rocky Linux、AlmaLinux，安装时如果选择自动分区，/boot通常会作为一个独立逻辑卷放在LVM里。这种情况下扩容非常简单：只要卷组里有空闲空间，lvextend + xfs_growfs/resize2fs两条命令就能搞定，完全不用重启，不影响正在运行的服务。

判断方法就是看lsblk输出，如果/boot那一行的类型是lvm，挂载点是/boot，说明它确实是逻辑卷。或者用lvs命令查看有没有名字类似/boot的LV。

我自己操作过一台Rocky Linux 9服务器，/boot逻辑卷只有500MB，内核装了三套直接爆掉。当时卷组还有几十GB未分配空间，整个扩容过程不到一分钟，零停机，非常丝滑。具体步骤我在第四节详细演示。

3.3 如果/boot是普通分区：调整分区表是重头戏

传统分区模式下，/boot通常是个primary分区，比如/dev/sda1。这时候扩容的思路是“先把分区边界扩大，再让文件系统填满新空间”。核心难点在于分区边界能不能扩、往哪边扩。

如果是虚拟机或者云主机，我建议优先看看能不能在磁盘末尾加一块未分配空间。比如VMware虚拟机扩容虚拟磁盘、KVM的qcow2镜像扩容，都会让磁盘整体变大，多出来的空间在磁盘末尾。这时候用parted或者GParted把/boot分区扩展到新空间即可。命令流程大概是：

bash复制parted /dev/sda
(parted) resizepart 1 100%
quit

如果是ext4文件系统，再执行：

bash复制resize2fs /dev/sda1

如果是XFS，则用：

bash复制xfs_growfs /boot

注意，resize2fs可以在线扩展ext4文件系统，不用卸载；但xfs_growfs必须挂载后才能执行，这个细节很多人记反。

3.4 空间实在不够的备选路径：清理旧内核

有时候你其实不需要扩容，只需要把积压的旧内核清掉就行了。比如某台机器/boot才200MB，日常只保持一套内核，那完全没必要折腾分区。

清理旧内核的通用思路是先列出已安装的内核包，再卸载非当前使用的版本。RHEL系用rpm或dnf，Debian/Ubuntu系用dpkg或apt，我在第六节专门写了一套安全的清理流程。但我得提醒你，清理旧内核只是缓兵之计，如果你预计后续内核更新会比较频繁，该扩容还是要扩容，否则过两个月又得清理一次。

4. 实操演示一：LVM场景下的/boot在线扩容

先看一个我上个月处理的案例，最能说明LVM方案的便利性。一台Rocky Linux 9服务器，/boot逻辑卷使用了94%，新内核怎么也装不进去。查了下LVM状态，卷组名字叫rl，还有20GB空闲空间，于是决定在线扩容。

4.1 确认卷组有可用空间

执行vgs看卷组剩余空间：

bash复制vgs

输出大概是：

bash复制  VG #PV #LV #SN Attr   VSize  VFree
  rl   1   3   0 wz--n- <99.00g 20.00g

VFree那列有20GB，说明空间充足。再确认/boot对应的逻辑卷路径：

bash复制lvs

bash复制  LV   VG Attr       LSize   Pool Origin Data%  Meta%  Move Log Cpy%Sync Convert
  root rl -wi-ao----  50.00g
  swap rl -wi-ao----   4.00g
  boot rl -wi-ao---- 500.00m

这里boot逻辑卷只有500MB，路径应该是/dev/mapper/rl-boot或/dev/rl/boot。确认好路径后，直接把它扩展到1.5GB。

4.2 扩展逻辑卷并让文件系统跟随变大

扩展逻辑卷：

bash复制lvextend -L +1G /dev/mapper/rl-boot

命令执行完会提示逻辑卷大小已从500MB变为1.5GB。但这只是逻辑卷层面的扩容，文件系统还没感知到新空间。这时要分文件系统类型来处理。

如果是XFS（Rocky 9默认/boot就是XFS），执行：

bash复制xfs_growfs /boot

如果是ext4，执行：

bash复制resize2fs /dev/mapper/rl-boot

注意两者差异：xfs_growfs后面跟的是挂载点，resize2fs后面跟的是设备路径。而且xfs_growfs要求/boot必须处于挂载状态，resize2fs则支持在线扩展，不用卸载。

4.3 扩容结果验证

最后再执行df确认结果：

bash复制df -hT /boot

看到1.5G、使用率降到正常范围，就完成了一次标准的LVM在线扩容。整个过程不需要重启，不影响业务，这也是我一直推荐有条件就把/boot放进LVM的原因。

注意：如果你的VG里没有空闲空间，就别想着lvextend了。先看看能不能把物理卷扩展到新磁盘空间上，比如虚拟机磁盘扩容后执行pvresize /dev/sda，再vgs确认VFree是否变大，然后再重复上面的步骤。

5. 实操演示二：传统分区场景下用Live系统调整分区

传统分区扩容就没那么轻松了，但也不是什么玄学。我把整个流程拆解成几步，你用GParted图形界面或者parted命令行都可以，这里我两条路都讲清楚。

5.1 为什么强烈建议用Live USB操作

传统分区调整最怕“文件系统被占用”。你在系统运行中直接resizepart，内核可能还持有旧的分区表信息，文件系统也在活跃使用中，强行操作极容易造成分区表不一致甚至损坏。所以我的建议是：

准备一个包含GParted的Live USB，常用的是GParted Live或者Ubuntu Live。
从U盘启动进入Live环境。前提是你测试过机器能从USB启动，如果主板开了Secure Boot可能还需要调整。
在Live环境里先mount检查一下/boot里的内容是否正常，确认备份没白做。

有的读者会问：能不能真机直接parted在线调？我坦诚讲，有的人成功了，但我不推荐你赌这个运气。数据无价，离线操作的成本只是多花十分钟重启而已。

5.2 用GParted图形界面完成分区调整

进入GParted后，先看分区图。假设你的/boot是/dev/sda1，后面紧跟的是/dev/sda2（LVM PV或/分区），而磁盘末尾有一块未分配空间。

操作逻辑是：如果未分配空间在/boot后面连续的空闲区域（不是磁盘末尾，而是紧邻/boot的空闲区），直接右键/dev/sda1 -> Resize/Move，把尾巴拉大，然后点击Apply，GParted会自动调整分区大小并扩展文件系统。

但如果未分配空间在磁盘末尾，而/boot和它之间隔着/dev/sda2，你就不能直接扩/boot了。这时候有两条路：

路线一：把/dev/sda2往右移。GParted支持移动分区位置（Move），但整个过程会重写/dev/sda2上所有数据，耗时取决于分区大小，比如移动500GB的根分区可能要半小时甚至更久。风险高一点，但能保留原有分区结构。
路线二：先缩/dev/sda2的尾部（前提是文件系统支持收缩，XFS不支持收缩，ext4可以），腾出空间给/boot，再扩展/boot。收缩分区有风险，但不用移动整块数据。

我在实际工作中通常会先评估：这台机器上的数据多不多？如果/分区或LVM PV很大，移动巨慢，不如直接把新内核清到只剩当前版本，或者考虑把/boot整体复制到新分区甚至新磁盘上。GParted的操作界面虽然直观，但在大分区上挪空间非常耗时，你可能要守着屏幕等很久。

5.3 命令行方式：parted + resize2fs的完整流程

如果你更习惯命令行，可以完全在parted里完成。假设/boot是/dev/sda1，后面跟的/dev/sda2是LVM PV，我现在要把/boot从500MB扩到1.5GB，前提是/dev/sda2尾部有1GB空闲或者已经收缩过。

先查看当前分区表：

bash复制parted /dev/sda print

确认/dev/sda1的起始扇区，例如是2048，结束扇区是1026047（500MB左右）。

然后启动交互模式：

bash复制parted /dev/sda
(parted) unit s
(parted) resizepart 1 3074047
(parted) quit

这里unit s表示以扇区为单位，resizepart 1 3074047意思是把第一个分区扩展到结束扇区3074047。1GB大约等于2097152个扇区，加在原来结束扇区1026047上，新的结束扇区就是3123199，不过我习惯稍微保守一点，用3074047给分区表和某些对齐留点余量。

注意，parted的resizepart在部分版本上需要分区处于未挂载状态，否则会报警告。这也是我一直强调用Live环境的原因。

分区调整完之后，再扩展文件系统。如果/boot是ext4：

bash复制resize2fs /dev/sda1

如果/boot是XFS，XFS不支持收缩但支持在线扩展，挂载后执行：

bash复制xfs_growfs /boot

5.4 常见坑：别忘了重新安装GRUB

我早期犯过一个错：分区扩容成功了，文件系统也变大了，但重启后机器直接卡在grub命令行界面。原因是GRUB安装时写入的是MBR和/boot目录里的引导镜像，分区变化后GRUB的核心镜像位置可能需要更新。尤其是你移动过/boot分区起始位置，或者重做过分区表，GRUB找不到原来的/boot。

解决办法是在Live环境里chroot进系统，重新生成GRUB配置并写引导：

bash复制mount /dev/sda2 /mnt
mount /dev/sda1 /mnt/boot
mount --bind /dev /mnt/dev
mount --bind /proc /mnt/proc
mount --bind /sys /mnt/sys
chroot /mnt /bin/bash
grub2-mkconfig -o /boot/grub2/grub.cfg
grub2-install /dev/sda

如果是Ubuntu/Debian系，grub2-install通常叫grub-install。更新完再重启验证。

提示：chroot之前最好把/etc/resolv.conf也bind进去，因为grub2-mkconfig可能不需要联网，但保不准有些脚本会调用网络工具，提前bind能少些麻烦。

6. 实操演示三：救急思路——几十条命令清理旧内核

如果你暂时不方便扩容，或者空间只是暂时紧张，清理旧内核是最快的应急手段。我在这台机器上只花了几分钟就腾出近300MB空间，足够继续安装新内核了。

6.1 查询已安装内核

RHEL系先看当前运行的内核版本：

bash复制uname -r

再看系统装了几个内核包：

bash复制rpm -qa | grep ^kernel

Debian/Ubuntu系对应的是：

bash复制dpkg --list | grep linux-image

筛选出需要保留的版本：当前运行的版本、回滚要用的上一个版本，其余都可以清。我一般保留最近两个版本。

6.2 删除旧内核的正确姿势

RHEL 7+ / Rocky / CentOS系，建议用dnf的autoremove功能：

bash复制dnf remove --oldinstallonly --setopt installonly_limit=2

这条命令表示只保留最新2套安装内核，其余旧内核全部移除。执行后会同步删除/boot下对应的vmlinuz、initramfs、System.map等文件，不用担心手动漏删。

如果没有这个选项，也可以手动指定版本删除：

bash复制dnf remove kernel-5.14.0-362.8.1.el9_3.x86_64

Ubuntu/Debian系：

bash复制sudo apt autoremove --purge

或者用byobu的purge-old-kernels。这些都是比较成熟的做法，比自己手动rm /boot/vmlinuz-*要安全得多，因为包管理器会同时清理依赖和元数据。

6.3 防止空间再次爆掉的习惯配置

清理完旧内核，空间看着宽裕了，但你得想明白一件事：如果不改习惯，过几个月还是会把/boot撑爆。我给大家几个实操性很强的建议：

加一个定时任务，每周查一次/boot使用率，超过80%就发告警。简单的cron脚本加df判断就能搞定。
有条件的用户，可以考虑在yum/dnf配置文件里设置installonly_limit=3，控制同时安装的内核套数。编辑/etc/dnf/dnf.conf，加入：

ini复制installonly_limit=3

这样系统会自动剔除最旧的内核包，从根源上避免/boot被历史内核堆满。

如果机器是虚拟化环境，最一劳永逸的办法是调整根文件系统布局：下次重装系统时别把/boot独立分区，而是把整个根分区放在LVM里，boot相关目录作为根下的普通目录。这样即使将来空间不够，也可以直接扩根分区，不存在独立/boot的容量焦虑。当然，这在某些加密或特殊引导场景下不适合，你需要评估自己的需求。

7. 常见问题与排查技巧实录

折腾分区扩容的过程中，我遇到过的奇怪问题不少。下面挑几个典型的，整理成速查表，省得你到出问题时抓瞎。

7.1 扩容后文件系统没变大怎么办

现象：lvextend或者parted resizepart都成功了，但df看/boot还是原来的大小。

原因：逻辑卷或者分区虽然变大了，但文件系统没有感知到新空间，需要手动执行扩展文件系统的命令。

处理：

ext4：确认没有卸载，直接执行resize2fs /dev/设备路径
XFS：确认分区已挂载，执行xfs_growfs /挂载点

7.2 调整分区时提示“无法移动分区的起始位置”

现象：用GParted移动分区时提示类似“cannot move the start of partition because ...”，或者parted resizepart时报错。

原因：分区前面没有空闲空间，而分区不能往前扩展；或者是目的位置有数据重叠。

处理：这是分区布局的限制，不是工具的bug。如果确实需要把/boot往前扩，只能先备份并删除分区，再以新的起始位置重建分区，然后恢复数据。这个过程非常繁琐，我一般直接绕开，考虑更换扩容方案。

7.3 GRUB启动不了、卡在grub rescue

现象：重启后进入grub rescue>界面，找不到正常的引导文件。

原因：分区调整后，GRUB的根目录（通常/boot所在分区）没有被正确找到，可能是分区号变了、UUID变了，或者GRUB核心镜像损坏。

处理：

在grub rescue命令行里手动指定路径。先输入ls看看有哪些磁盘分区，找到Linux分区，比如(hd0,gpt2)，然后：

text复制set root=(hd0,gpt2)
set prefix=(hd0,gpt2)/boot/grub2
insmod normal
normal

如果这能正常进入菜单，说明分区号变化了，进系统后用grub2-install /dev/sda重新安装。

如果GRUB损坏严重，只能进Live环境chroot重装grub，参考5.4节。
如果你之前记录了分区的UUID，也可以在grub命令行里用search命令：

text复制search --no-floppy --fs-uuid --set=root 你的UUID

7.4 /boot是XFS不是ext4时工具要用对

很多新手拿着网上搜到的教程一条条抄，遇到XFS的分区却用了resize2fs，结果提示“Bad magic number in super-block”，就慌了。

记住：resize2fs只支持ext2/ext3/ext4；XFS用xfs_growfs，而且不支持收缩（shrink）。如果你需要缩小一个XFS分区来腾空间，那很不幸，没有原生的在线收缩工具。可以考虑用xfsdump导出再重建文件系统，但操作复杂度立刻上一个台阶，这也是为什么我建议有条件就把/boot做成ext4或者ext2，至少在传统分区场景下调整起来方便很多。

7.5 常见问题速查表

问题现象	可能原因	解决方案
df显示没空间，但ls看不到大文件	initramfs、内核文件在/boot/lost+found或隐藏目录	du -sh /boot/* 逐个排查
lvextend后df没变化	没有执行文件系统扩展命令	resize2fs或xfs_growfs
/boot不是ext4也不是XFS	可能是btrfs	btrfs filesystem resize max /boot
扩容后重启进grub rescue	分区表变更导致GRUB找不到/boot	chroot重装GRUB，或手动set root
GParted提示分区忙	文件系统仍被挂载或swap占用	Live环境操作，或swapoff

写在最后的一点经验

/boot分区虽然小，但它在启动链路中扮演的角色非常关键。我自己的习惯是：能用LVM就一定用LVM，逻辑卷扩容真的太省心了；如果是传统分区，就提前给自己留好余地，比如安装系统时分区别卡得太死，给/boot前后各留一些空闲区间。扩容这件事，永远都是“事前规划一小时，胜过事后折腾一整天”。

再分享一个小技巧：每次升级内核之前，先手动跑一下df -h /boot，如果使用率超过70%，就先清理或扩容再升级。这个习惯帮我躲过了好几次“升级一半磁盘满”的尴尬。如果你手头的机器已经因为/boot空间不足而卡住，别急，按照这篇博文里的方案，先判断是LVM还是传统分区，再选对应的路径操作。生产环境多一份敬畏，动手前多做一次备份，稳妥永远比花活重要。