一次 Ubuntu 系统迁移的故障分析

上周体验了 Mac 上排名第一的虚拟机软件 Parallels Desktop + 190x 的 Win 10,主观感觉能达到独立运行流畅度的 90%。Mac 250GB 的 SSD 显然不舍得存储一个虚拟机文件。于是展开了一场血雨腥风的迁移活动…

老本子上是 Ubuntu 18.04,一块 120GB 750EVO,另一块 250GB 860EVO。linux / 挂在小盘上,/var、/home、/boot 和 /tmp 挂在大盘上。

现在想把大盘拿出来专门用于外挂 Mac 存储虚拟机文件。

进入 Ubuntu Live CD,一顿操作 sudo mount、sudo cp …… ,好在是两盘对拷,速度还是比较快的。

这几个目录中的文件成功 copy 到了小盘的 / 下。

然后,开机。

提示磁盘有问题。

一顿 fsck 修复。

log 卡在奇怪的地方,而且每次都不太一样。

于是返回小盘仔细查看文件是不是 copy 的有错。

原来,在执行 cp 之前先尝试了几次 dd,但是中途打断了,之后继续使用 cp。问题可能就出在了 cp 上,目标目录是错的。造成的结果就是 /home/home/james。一顿操作修复了目录问题。

开机,进入登录画面的前一秒,Started Light Display Manager…

黑屏 1s,log 1s,黑屏1s,log 1s,如此循环往复。也无法通过 ctrl alt F1 切到无 gui 模式,因为一直在闪。

经过一番 bing 搜索,初步断定是 nvidia 显卡驱动的问题,于是准备卸载显卡驱动。但是从 recovery mode 下的 root 入口进入系统后,无论直接使用 apt-get 还是 dpkg 卸载 nvidia*,都没什么作用。

这一次 google 了一番,得出的答案是执行 dpkg-reconfigure lightdm。果然,这次没有再闪了。但是,输入密码回车登录系统的下一秒看到的还是登录画面,google 上了解了这个叫做 Login Loop,很生动的名字。

再一次 google 的目的性就很强了,找到了一篇关于 Login Loop 的文章,提示我检查 ~/.XAuthority 的权限。🤩恍然大悟!sudo cp 过来的文件归属还是 root:root 呢,所有 /home 下的文件都是如此!把所有文件的归属改好之后终于正常进入了桌面。

还是好好看一下 dd 命令的手册吧,这种系统迁移级别的操作还是 dd 比较稳妥,因为之前将小盘的那几个目录文件迁到大盘用的正是 dd。

😭Linux 的 permission 好好地给我上了一课!

发表评论

电子邮件地址不会被公开。 必填项已用*标注

This site uses Akismet to reduce spam. Learn how your comment data is processed.