Linux

背景

某台 Linux 主机使用 LVM 管理根分区，系统原本可以正常启动。后续为了统一命名规范，对卷组名称进行了重命名。重命名本身成功，LVM 层状态正常，但随后出现了两个典型问题：

  1. update-initramfs 报错，提示无法解析旧的逻辑卷路径
  2. update-grub 报错，提示无法获取旧根设备的 canonical path

这类问题的本质并不在于 LVM 重命名失败，而在于启动链路中的历史引用没有被同步更新。
也就是说，LVM 元数据已经变了，但 GRUB、内核命令行、initramfs、fstab 等位置仍然残留旧名字。

本文记录一次完整的排查与修复过程，并总结出一套可复用的方法。

现象

在卷组重命名之后，LVM 状态看起来已经正常，例如：

  • PV 正常
  • VG 名称已变更
  • LV 正常激活
  • /dev/mapper/新卷组-root 已存在

但是执行以下命令时会出错：

update-initramfs -u -k all

报错类似：

cryptsetup: ERROR: Couldn't resolve device /dev/mapper/旧卷组-root
cryptsetup: WARNING: Couldn't determine root device

继续执行：

update-grub

又会报错：

/usr/sbin/grub-probe: error: failed to get canonical path of `/dev/mapper/旧卷组-root'.

这说明系统运行态已经基于新逻辑卷工作，但启动配置里仍然有旧名字残留。

问题本质

LVM 的卷组名变更，只会修改 LVM 层对象名称，不会自动替换所有系统配置中的旧引用。

一台主机的启动链路通常至少涉及以下几个层面：

  1. 运行态挂载源
  2. /etc/fstab
  3. GRUB 配置
  4. 内核启动参数
  5. initramfs
  6. resume 参数
  7. 历史备份配置或归档文件

只要其中一个关键环节还保留旧根卷路径，就可能导致：

  • grub-probe 找不到设备
  • update-initramfs 误判根设备
  • 重启后进入紧急模式
  • 恢复模式中仍引用旧逻辑卷名

第一步：确认 LVM 当前状态

先确认 LVM 本身是否已经完成重命名。

pvs
vgs
lvs
ls -l /dev/mapper
findmnt -no SOURCE /

理想状态应该是：

  • 卷组名已经是新名字
  • 逻辑卷名仍为 root
  • /dev/mapper/新卷组-root 存在
  • 当前根分区来源已经是 /dev/mapper/新卷组-root

如果这一步都不正常，不要继续改 GRUB，而应该先回到 LVM 层处理。

第二步：全局搜索旧名称残留

核心思路很简单：不要猜，直接搜。

例如搜索旧卷组名、旧逻辑卷路径、旧 mapper 路径：

grep -RniE '旧卷组|/dev/mapper/旧卷组-root|/dev/旧卷组/root' /etc /boot 2>/dev/null

实际排查时，常见残留位置包括：

  • /etc/fstab
  • /boot/grub/grub.cfg
  • /etc/default/grub
  • /etc/initramfs-tools/conf.d/resume
  • /etc/crypttab
  • 某些 initramfs 相关配置目录
  • LVM archive / backup 文件

这里需要区分两类结果：

1. 真正会影响启动的配置

这些必须修正：

  • /etc/fstab
  • /etc/default/grub
  • /boot/grub/grub.cfg（由 update-grub 生成，不直接手改）
  • resume 配置
  • crypttab（若存在且实际使用）
  • initramfs hook 相关配置

2. 历史归档文件

例如：

  • /etc/lvm/archive/*
  • /etc/lvm/backup/*

这些通常只是历史记录，不影响当前启动，不必处理。

第三步：处理 fstab

根分区写法有两种主流思路：

方案 A：用 UUID

优点是稳定，不依赖 LVM 名称
缺点是可读性差

UUID=<ROOT-UUID>   /   ext4   defaults   0 1

方案 B：用逻辑卷路径

优点是直观，和系统结构一致
缺点是如果以后再改卷组名，还要同步调整

/dev/mapper/<VG>-root   /   ext4   defaults   0 1

如果目标是统一风格、强调结构可读性，那么逻辑卷路径写法更清晰。

EFI 分区则建议继续使用 UUID，例如：

UUID=<EFI-UUID>   /boot/efi   vfat   defaults,noatime   0 2

如果系统里存在 swap 逻辑卷，但当前不想启用，可以保留注释而不删除：

#/dev/mapper/<VG>-swap   none   swap   sw   0 0

这样结构完整，后续需要恢复时也方便。

修改完成后执行：

mount -a
findmnt -no SOURCE /
findmnt -no SOURCE /boot/efi
swapon --show

如果没有报错，说明 fstab 基本正确。

第四步：处理 GRUB 根参数

这是这次问题的关键点之一。

即使 /etc/default/grub 里看起来是空的，grub.cfg 仍然可能通过自动探测写入旧的：

root=/dev/mapper/旧卷组-root

一种稳妥办法是显式指定根分区 UUID：

GRUB_CMDLINE_LINUX="root=UUID=<ROOT-UUID>"

这样可以让 GRUB 在重新生成配置时，明确写入新的根参数来源，避免继续依赖旧 mapper 名称。

修改后执行：

update-grub

再检查：

grep -n 'root=' /boot/grub/grub.cfg

如果结果中已经变成新逻辑卷或新 UUID 组合，说明问题正在收敛。

需要注意的是，grub.cfg 中同时出现：

  • root=/dev/mapper/新卷组-root
  • root=UUID=<ROOT-UUID>

这是可以接受的。
GRUB 自动探测出的设备路径与手动指定的 UUID 可以同时存在，并不会冲突到无法启动的程度。

第五步：临时兜底手段

如果 update-grub 在切换前无法执行，提示找不到旧逻辑卷路径，可以临时创建一个兼容软链接，先让 GRUB 工具链通过探测。

例如：

ln -s /dev/mapper/新卷组-root /dev/mapper/旧卷组-root

这是一个过渡手段，目的是让：

  • grub-probe
  • update-grub
  • update-initramfs

先顺利跑通。

等新的 grub.cfg 和 initramfs 都生成完成后，这个临时软链接就不再重要了。

这个办法很实用，尤其适合已经在线运行、又不想立刻重启救援的场景。

第六步：处理 initramfs 报错

当 update-initramfs 报：

Couldn't resolve device /dev/mapper/旧卷组-root

说明 initramfs 阶段仍在试图识别旧根卷。

如果已经确认：

  • fstab 正确
  • GRUB_CMDLINE_LINUX 正确
  • 旧路径只是历史残留

那么通常在 GRUB 修正后，再执行：

update-initramfs -u -k all

就能恢复正常。

如果系统启用了 resume，还要额外检查：

cat /etc/initramfs-tools/conf.d/resume

若其中仍引用旧 swap 路径或旧 UUID，需要一并修正，或者直接停用 resume。

第七步：不使用 swap 时，别忘了去掉 resume

这是另一个非常容易忽略的点。

即便已经在 fstab 里把 swap 注释掉，只要 GRUB 命令行还保留：

resume=UUID=<SWAP-UUID>

系统仍会在启动时尝试恢复休眠映像。

如果明确不打算使用 swap，也不打算使用休眠，那么应当把 resume 一并去掉。

做法可以是直接修改 GRUB 配置源，再重新生成：

sed -i 's/ resume=UUID=[^ "]*//g' /etc/default/grub
update-grub
update-initramfs -u -k all

这样可以让系统状态更干净，避免后续误判。

第八步：最终核对项

静态配置完成后，建议至少核对以下内容：

pvs
vgs
lvs
lsblk -f
findmnt -no SOURCE /
cat /etc/fstab
grep -n 'root=' /boot/grub/grub.cfg
grep -n 'resume=' /boot/grub/grub.cfg
cat /proc/cmdline
swapon --show

理想状态如下：

LVM

  • VG 为新名字
  • LV 为 root（及可选的 swap）
  • /dev/mapper/新卷组-root 存在

挂载

  • / 实际来自 /dev/mapper/新卷组-root
  • /boot/efi 指向正确的 vfat 分区

GRUB

  • grub.cfg 中不再出现旧卷组名
  • root= 已切换为新逻辑卷或正确 UUID
  • 不再存在无用的 resume=...

swap

  • swapon --show 无输出，表示当前未启用

运行态说明

如果此时 cat /proc/cmdline 里仍显示旧参数，不一定是失败。
因为它反映的是本次启动时传给内核的参数。只要新的 GRUB 和 initramfs 已经生成，通常只需在下一次重启后才会体现为新值。

最终采用的统一风格

这次整理后，系统配置统一为以下风格：

fstab

UUID=<EFI-UUID>                /boot/efi   vfat   defaults,noatime   0 2
/dev/mapper/<VG>-root          /           ext4   defaults           0 1
#/dev/mapper/<VG>-swap         none        swap   sw                 0 0

特点是：

  • EFI 用 UUID，稳定
  • 根分区用 /dev/mapper/<VG>-root，可读性高
  • swap 保留为注释，结构完整但默认不启用

GRUB

GRUB_CMDLINE_LINUX="root=UUID=<ROOT-UUID>"

特点是：

  • 启动时明确指定根分区
  • 避免 GRUB 继续依赖旧逻辑卷名
  • 对卷组改名场景更稳妥

经验总结

1. LVM 重命名不是结束，只是开始

真正麻烦的不是 vgrename，而是重命名后的启动链路一致性修复。

2. 排查时不要凭印象，直接全局搜索

只要旧名字还存在于关键配置中，就有潜在风险。

3. fstab、GRUB、initramfs 必须一起看

只改其中一处，通常不够。

4. resume 经常被忽略

如果不使用 swap，最好连 resume 一起清掉。

5. 可以先用软链接救急，再做正式修复

这在在线系统上非常有效，尤其适合不方便立刻进入救援模式的场景。

6. 运行态参数和静态配置不是一回事

/proc/cmdline 反映的是“当前这次启动”，不是“磁盘上已经写好的下次启动配置”。

结语

这次修复并不复杂，但很典型。
本质上是一次“命名修改引发的启动链路不一致”问题，而不是 LVM 本身故障。

只要抓住三个关键点：

  • 先确认当前 LVM 真实状态
  • 再搜索旧引用残留
  • 最后统一修复 fstab、GRUB、initramfs、resume

这类问题就能比较平稳地处理掉。

对于长期维护的 Linux 主机来说，卷组名、逻辑卷名、挂载方式、启动参数的命名风格最好从一开始就保持一致。
否则后面一旦重构，系统虽然还能跑，但历史命名残留很容易在启动链路里反咬一口。

Leave a Reply

Your email address will not be published. Required fields are marked *