为什么迁移后不能只看能否开机
很多迁移操作在表面上看起来是成功的：系统启动了，桌面进去了，文件管理器也能打开。但这并不代表迁移没有问题。Fedora作为一个较新的发行版，使用SELinux、Btrfs快照、GRUB2引导、systemd服务管理等一系列复杂机制，任何一个环节在迁移中出现了偏差，都可能导致系统在某个时刻突然出现异常，比如某个服务起不来、数据盘挂载失败、软件包状态错乱等。
尤其是从物理机迁移到虚拟机、或者更换硬盘这类操作，硬件环境发生了变化，内核加载的驱动模块、网络接口命名、磁盘设备标识都可能不同。如果只是登录进桌面就算验证通过，风险其实被留到了后面。因此迁移完成后，应该有一套系统化的验证流程，逐项确认关键组件的状态。
本文按照从底层到上层、从系统到应用的顺序，把验证工作分成几个大块，你可以照着清单一项一项过，全部通过之后再正式切换使用。
引导与文件系统的验证
首先要确认的是GRUB引导是否正常。虽然系统能启动说明引导大体没问题，但还是要检查一下/boot分区内容和内核镜像是否完整。可以查看当前运行的内核版本，并和/boot目录下的内核文件对照，确认迁移后内核文件没有丢失或损坏。
uname -r ls /boot/vmlinuz-* /boot/initramfs-*.img
如果uname -r显示的内核版本在/boot下找不到对应的vmlinuz文件，说明引导记录可能指向了错误的路径，或者分区没有正确挂载。这种情况下建议重新生成GRUB配置：
sudo grub2-mkconfig -o /boot/grub2/grub.cfg
接下来是文件系统层面。迁移后最容易出问题的是/etc/fstab里写死的UUID。新硬盘或新分区表生成后，分区UUID往往会变化，如果fstab还是旧的UUID，系统可能在启动时卡住或者跳过挂载。用以下命令对比实际分区的UUID和fstab中的配置：
lsblk -f cat /etc/fstab
如果发现不一致，要么修改fstab，要么用blkid确认后重新生成。另外，Fedora默认使用Btrfs文件系统，建议顺便执行一次sudo btrfs scrub start /来校验数据完整性，特别是用rsync或dd方式迁移的数据，scrub能发现潜在的坏块。挂载情况用findmnt检查一遍，确认所有该挂载的分区都已经就位，没有遗漏的数据盘。
SELinux、网络与服务状态检查
Selinux是Fedora的招牌特性，但迁移过程中文件的安全上下文容易丢失或错乱，尤其是用tar、rsync复制文件时如果没有保留xattr属性。可以先查看SELinux的整体状态：
sestatus sudo ausearch -m avc -ts recent
如果ausearch查到大量AVC拒绝记录，说明有文件的上下文不对。最直接的办法是对整个文件系统做一次自动修复重新打标签，然后重启：
sudo touch /.autorelabel sudo reboot
网络方面，注意迁移到新硬件后网卡名称可能变化，比如从enp3s0变成enp1s0。用ip addr和nmcli device status查看当前接口，如果连接配置里的接口名和实际不符，需要用nmcli con mod更新。DNS解析也别忘了测试，resolvectl status和ping ipipp.com各来一次。
服务层面，重点排查迁移后启动失败和异常退出的单元：
systemctl --failed journalctl -p err -b
systemctl --failed列出所有启动失败的单元，journalctl -p err -b则显示本次启动以来的错误级别日志。常见的问题包括数据库服务因为数据目录权限或上下文不对而启动失败、定时任务因为路径变化而报错。逐一修复后再用systemctl status确认目标服务都处于active状态。
数据完整性与软件环境一致性
数据是迁移最核心的部分。如果迁移前对重要数据做过校验和记录，迁移后直接比对即可：
cd /home/user/data
find . -type f -exec sha256sum {} \; > /tmp/after.sha256
diff /tmp/before.sha256 /tmp/after.sha256如果没有事前的校验记录，至少抽查几个大文件和重要配置，确认能正常打开、内容没有截断。数据库类应用还需要进入数据库执行完整性检查，比如MySQL用mysqlcheck，PostgreSQL跑ANALYZE并查看日志有无报错。
软件环境方面，检查RPM数据库是否完好：
rpm -Va | head -50 sudo dnf check
rpm -Va会列出与安装时记录不一致的文件，少量配置文件被修改是正常的，但如果出现大量二进制文件不一致，就要警惕数据损坏。dnf check则检查包依赖关系是否完好。另外建议执行一次sudo dnf update，一来验证软件源能正常访问，二来把迁移期间积累的更新补上。
最后别忘了用户层面的验证：普通用户能否正常登录、桌面环境配置是否保留、字体和输入法是否正常、crontab定时任务是否还在。把这些都过一遍之后，再观察运行几天，确认没有隐藏的异常，这次迁移才算真正收尾。
写在最后
系统迁移是个细致活，验证环节做得扎实，能省掉后面大量排障时间。建议把本文的检查命令整理成一个脚本，迁移完成后一键跑一遍，把关键输出保存下来留档，既方便对比也方便回溯。养成这个习惯之后，无论迁移到新硬盘、新机器还是虚拟化平台，你都能心中有数，从容应对。