会，直接修改 /etc/fstab 会导致启动失败，大概率黑屏或卡在 initramfs；因系统按顺序挂载，若 uuid 错、设备名变或 lvm 未激活，/home 或 /data 挂载失败将引发依赖服务（如 pam、gdm、ssh）全面崩溃。
直接改 /etc/fstab 会导致启动失败吗？
会，而且大概率黑屏或卡在 initramfs。因为系统启动时按 /etc/fstab 顺序挂载，如果新设备还没就绪（比如 UUID 错、设备名变、LVM 未激活），/home 或 /data 挂载失败，后续依赖它的服务（如 PAM、GDM、SSH）全崩。别信“改完 fstab 重启就行”这种说法。
真正安全的做法是：先让新分区可访问，再用 mount --bind 把它“顶替”进原路径，验证无误后再更新 fstab —— 这样整个过程无需重启，用户登录、进程读写完全无感。
mount --bind 和直接 umount + mount 的区别在哪？
mount --bind 是视图映射，不改变底层设备挂载状态；而 umount /home && mount /dev/sdb1 /home 是真实卸载+重挂，期间所有对 /home 的访问都会报 “No such file or directory”。生产环境绝对不能这么干。
- bind mount 不中断任何进程：正在运行的桌面会话、SSH 登录、systemd 用户实例照常工作
- 原
/home内容仍可通过备份挂载点访问（如mount --bind /home /home_bkp） - fstab 中需显式声明 bind 类型：一行写设备挂载，另一行写 bind 映射，且 bind 行必须加
bind和x-systemd.requires=xxx（避免顺序错乱）
复制数据时 cp -aX 和 rsync -aAX 哪个更稳妥？
优先用 rsync -aAX --progress /home/ /mnt/newhome/。原因很实际：
-
cp -aX在遇到 SELinux 上下文冲突（比如 XFS 默认不存扩展属性）时可能静默失败，rsync会报 warning 并继续 -
rsync支持断点续传，大目录迁移中途出错不用重来 -
--progress能看到实时进度，cp只有完成才吐结果 - 务必注意末尾斜杠：
/home/表示复制内容，/home表示复制目录本身——少一个斜杠，/mnt/newhome/home就多套一层
fstab 里 UUID 和设备名混用会出什么问题？
设备名（如 /dev/sdb1）在内核加载顺序变化、UDEV 规则更新、热插拔后极易变动，导致开机挂载错盘甚至挂载到错误路径（比如把数据库盘挂成 /home）。UUID 是唯一且稳定的，但必须确认它对应的是你真正想挂的分区。
验证方法很简单：
- 运行
blkid /dev/sdb1，记下输出的 UUID 字符串 - 临时挂载该设备：
mount /dev/sdb1 /mnt/test && ls /mnt/test，确认内容是你刚复制的家目录 - fstab 中写成：
UUID=xxxx-xxxx /mnt/newhome xfs defaults 0 0，再另起一行：/mnt/newhome /home none bind 0 0 - 执行
mount -a测试语法，再df -h /home看是否显示新设备
最易被忽略的是 SELinux 上下文和 ~/.Xauthority 权限：迁移后若图形界面打不开，八成是 restorecon -Rv /home 没跑，或者 root 用户的 .Xauthority 被复制成了普通用户权限。这些细节不修，bind mount 再稳也白搭。
