继续玩弄 MacBook Pro。上面两块硬盘，一块在硬盘位，1TB 机械硬盘，Windows，一块在光驱位，240GB SSD，Ubuntu 15.04。周五下班，把它从单位背回到家，计划好了的，Windows 系统上好多是家里的内容，要退下来。换上了一块前阵子新买的 1TB 的盘，就是接替摔坏的薄盘的那块，上面有两个系统，Ubuntu 15.04 和 Debian 8.1。然后，好玩儿的来了。这是和上一篇博文可以共享的前情提要。花开两朵，既然已经表了 Debian 那一朵，今日就再表 Ubuntu 这一朵。
上文书其实也提到了，Ubuntu 陷入了登录怪圈不能自拔，在网上寻找资料没有些微裨益的三太爷考虑有没有其他处理方法。接着就想到，能不能把 SSD 上的 Ubuntu 克隆到机械硬盘上呢？考虑了一下可能的坑，大致有：1、磁盘空间大小问题；2、克隆方法和工具问题；3、分区表处理的问题。头一个经过确认，目标分区大小足够，不成问题，第二个其实也不是真正的问题，因为只是要在不止一个可行方案里做一个选择，但第三个就要好好想一想。忘了交代的是，机械硬盘上的两个系统最开始是在 Surface Pro 3 上安装的，分区表是 GPT 格式的，而 SSD 还是 MBR 的分区格式，也因此，两块盘上的 Ubuntu 支持 Grub 的安装显然不相同，直接克隆必然会导致无法引导。
经过一番思考，三太爷做出了如下的迁移方案：把目标分区上原来的 /boot 目录、vmlinuz 和 initrd.img 文件以及 /etc/fstab 文件备份了下来，然后用 dd 进行分区复制，然后再把上述备份酌情恢复，之所以要说酌情，是我摸不准 fstab 文件究竟是否需要。所有步骤按照预想的顺利执行完毕，重启傻眼了，原来检测到的三个系统的选择菜单不出现了，出现了 Grub 提示符！心里一紧，想起 Grub 自身之前应该也在这个分区上的。这一情况和预想发生了偏差，原以为至多是选中克隆分区上的系统才出现引导失败，其他两个仍然可用。提示的文字说，TAB 键可以列出所有可用的命令，快速浏览了一遍，莫知所从。最后福至心灵鬼使神差，敲了个 initrd，奇迹出现了，竟然把 Debian 8 给引导起来了！进去以后的第一件事就是执行 grub-install 命令，把遗失的 Grub 补回来，紧接着就是 update-grub，确保菜单项也都恢复。再重启，果然三个系统都出现了，选中期望的那个，晕，又进了命令行！定睛一看，和刚才不一样，提示符变成了 (initramfs)。在上面，有如下描述：
Gave up waiting for root device. Common problems:
– Boot args (cat /proc/cmdline)
– Check rootdelay= (did the system wait long enough?)
– Check root= (did the system wait for the right device?)
– Missing modules (cat /proc/modules; ls /dev)
ALERT! /dev/disk/by-uuid/59313d6a-9c60-4b6e-aa6c-2fb7ef81ad56 does not exist. Dropping to a shell!
长话短说（中间走了些弯路），最后发现命中了上面 Boot 参数问题的第二条。在 Grub 菜单里，用编辑功能查看引导脚本发现，Grub 为当前磁盘分配的 UUID 与下面紧接着的 linux 命令里的 root 设备的 UUID 不一致，手动把 root UUID 改正，F10 即可以把克隆过来的这一份 Ubuntu 正常引导起来，总算不负我望！
剩下还要做的就是把这个 UUID 永久化到 Grub 配置文件里，而无须每次启动都手动修改。在 ESP 分区的 grub.cfg 里发现一处，但修改后没有效果。又做了不少探寻，最后是引导到 Debian 里，把 Ubuntu 分区手动 mount 起来，将其 /boot 目录下的一份 grub.cfg 里面所有出现的错误 UUID 都替换为正确的 UUID，保存退出，恢复文件权限，执行 update-grub，这才算结束。
资料一般都说，grub.cfg 是不建议手工修改的，因为它通常是工具生成的，但三爷一看生成它的工具貌似是 mkimage 这样的名字，心中自然就怯了几分，唯恐再拖出什么不可收拾的东西来。
重启一切正常，一份 MBR 上的 Ubuntu 成功转型为 GPT 现代化版本，是为记。