上半年来,把好几台中古笔记本出掉了。后果是手里有一堆 SATA 硬盘好像没了用武之地,本来说 T450s 应该是它们理想的去处的,可惜 SATA 口挑盘那叫一个严重,几乎就没有能装上去服了水土的。既然如此,那就另辟蹊径吧。
于是到小黄鱼上物色,简直不敢相信,傻多戴家的本子,便宜的令人乍舌。一开始的朴素需求就两条,CPU 最好是八代的、能用 SATA 硬盘、越便宜越好。于是放弃了 Latitude 的 7 系,在 5 系里面转悠。选来选去,看到一台 Latitude 5400,8GB+256GB 的配置,要价约 2500。内存和硬盘都太小,更何况那硬盘还是 m.2 的,于是跟卖家商量了一下,不要内存跟硬盘,包个顺丰 2100 元拿下。
到手后发现成色很好——这也是三太爷比较奇怪的一点——很多二手的戴尔本子都非常新,且在保。SATA 硬盘需要换转接线和硬盘架,这个在意料中,已经在淘宝单独下单,50 元。插上内存条,插上手边的一块现成的 Ubuntu m.2 系统盘。开机竟然毫无反应,心里不由得咯噔。倒不是别的,主要是嫌烦,前几天刚退回了一台带病的外星人,结果还被快递给摔坏了,倒赔了人家卖家 200 块。连着试了好几次,开机都不行,屏幕连背光都不亮。趁在下班前,连忙联系戴尔售后,正电话沟通呢,再一按电源键,嘿,有动静了。显示了个大意是检测到系统内存数量变化了的告警,再重启就没了。倒是 Ubuntu 没有能直接引导成功挺令我惊讶,看来 UEFI 引导的系统盘比 BIOS 的事儿多。不过既然证实了电脑本身没问题,那就安心等转接线吧。线到了一看,硬盘放不下,需要把电池换成小一号的。在役的是 68w 的,先拆下来。要换成一块 51w 的,也单独下了单,150 元,嘱咐店家带上电池连接线。
手里的 SATA 硬盘是 HP 的 OEM SSD,1TB 的容量,装了两个系统,Ubuntu 和 Windows 10,MBR 分区格式,BIOS 方式引导。熟悉老夫的人都知道,现成系统迁移是我的偏好,有无损转换的希望的话绝不会优先选择重装。
计划分为几步。
– 用 DiskGenius 将分区格式从 MBR 改变为 GPT;
– 想办法做出一个 ESP 分区出来;
– 从其他磁盘上把 ESP 分区所需的 EFI\boot 目录复制过来;
– 在 ESP 分区的 EFI 目录下,想办法建立 Ubuntu 和 Windows 的引导入口;
– 对 4 中的入口涉及到的各种配置进行调整,以便可以成功引导。
开始过程实录。
用 51nb 的 PE U 盘引导,将分区格式从 MBR 转变为 GPT —— 顺利完成;考察当前分区情况,依次如下:
– 770MB:Ubuntu 根(root)分区;
– 232GB:Ubuntu 系统分区;
– 233GB:Windows 10;
– 465.7GB:数据分区,Ext4 文件系统;
– 最后有 2.4GB 的空闲区域。
可知,如果要是在 MBR 分区表格式下,则已经无法再新增分区(已经是四个主分区了);但现在已经转成了 GPT 分区表格式,显然还可以增加新的分区。尽管末尾有 2.4GB 的空闲,但是出于某种执着,决定把 770MB 的根分区切分开,用其前 256MB 创建为 ESP 分区。使用 DiskGenius 调整容量(调整该分区前的空余容量为 256MB)完毕,在空出来的空间上,右键菜单中选择建立新分区(不要选择“建立 ESP/MSR 分区”),在界面里把文件系统选择为“EFI system partition”,容量等参数可能默认没有自动填充好,点一下“详细参数”按钮即可,然后确定。接着,保存分区表的变化,格式化此新分区,并为其分配一个盘符(以便于向其中复制文件),然后从一个现成的 UEFI 可引导系统盘的 ESP 分区中将 EFI 目录整个复制过来。
用的就是上面说过的那块 Ubuntu 的系统盘。根据并不精确的知识结构,其 EFI 目录下的 Boot 目录会被 UEFI 固件直接指定加载,而 Ubuntu 这样的存放具体系统的引导相关文件和信息的目录则要向 UEFI 固件进行某种方式的注册/报备(如 /EFI/Ubuntu/shimx64.efi),这儿,推测是 shimx64.efi 会加载 grubx64.efi,而后者会使用同目录下的 grub.cfg 作为配置文件。grub.cfg 文件中的内容如下:
1 2 3 |
search.fs_uuid fce45b0a-xxxx-yyyy-zzzz-0123-456789ab root set prefix=($root)'/boot/grub' configfile $prefix/grub.cfg |
看起来,这个 grub.cfg 指明了真正的实质性 grub.cfg 文件(应该也就是 Ubuntu 下,用 update-grub 命令生成的文件)所处的位置。
在我们以上的操作过程中,root 分区虽说被拆出来一部分,但是 DiskGenius 并未损坏其上的文件系统,因此理论上,上述 grub.cfg 的内容中,如果把 uuid 更新一下(如果必要),则是可以直接使用的。幸运的是,DiskGenius 直接就可以查看分区的 UUID:选中目标分区(此处即处理后的 root 分区),在右侧窗格中的分区参数标签页内,可以看到的“卷 UUID”即是(右键点击可以复制)。
至此,个人认为值得一次重新启动计算机了。预期结果是应该可以出现平常看到的 Ubuntu 的 Grub 菜单,但是(也许)并不能引导 Ubuntu 成功。事实结果是进入了 Grub 的命令行提示符。这个结果不是很好,但也不算太坏。
在这个提示符下,风扇转的很猛,略用 ls 命令做了一下观察后就关机了。当然不是用 poweroff 命令(因为没有),而是用 halt 命令。
那为什么没有出现 Grub 常规菜单呢?推测其原因很简单,因为 /boot/grub 目录下的 grub,还是 MBR 引导方式的版本,而不是 UEFI 引导所需要的版本。这个问题应该比较好解决,因为我们复制 ESP 分区上的内容时,源盘上的 Ubuntu 就是一份 UEFI 引导的系统,将其中的 Grub 也复制一份过来,把当前的 grub.cfg 保留下来再替换进去应该是可行的。重启进入 PE,试图复制 Grub 的企图受阻,好像 DiskGenius 对 Ext4 分区进行读操作没问题,写入是不可以的。改用 Ubuntu 的安装 U 盘应该可解,嗯,果然可以。
然而,过程中仍然在 grub.cfg 上遭遇了两次挫折(表现当然都是一样的,就是停留在 Grub 的命令提示符下)。第一次是 uuid 写错了,少了一个最后一个 – 号;第二次是没有把上头示例内容中,prefix 值路径里的 “boot/” 去除(这是因为 Ubuntu 的安装方式有差异导致的,如果安装时 root 分区是一个独立分区——正如本例——那就没有这个路径,这个路径是在 root 分区与系统分区为同一个分区时才存在的)。上面的小插曲过后,重启就看到了往日的 Grub 引导菜单,而且 Ubuntu 系统可以正常引导进入了。
接下来搞 Windows 10。仍然是进入到 PE 系统下,用 DiskGenius 给 ESP 分区分配一个盘符以方便后续的操作。首先,在 ESP 分区的 EFI 目录下创建 Microsoft 目录,然后到 Windows 10 所在分区的 \Windows\Boot\EFI 目录下把 bootmgfw.efi 和 boormgr.efi 两个文件复制到其中;然后再在 Microsoft 目录下创建 Boot 子目录,把 Windows 10 所在分区的 \Boot 目录下的 BCD 文件复制到其中。打开一个命令提示符(确保是具备管理员身份的),用 cd 命令进入到 Boot 子目录,然后执行以下命令序列(请注意 N 的实际用值,是 Windows 10 所在分区从 1 开始数的编号):
1 2 3 |
bcdedit.exe /store BCD /set {bootmgr} device partition=\Device\HarddiskVolumeN bcdedit.exe /store BCD /set {default} device partition=\Device\HarddiskVolumeN bcdedit.exe /store BCD /set {default} osdevice partition=\Device\HarddiskVolumeN |
经此操作后,即可重启进入机器的 UEFI 引导设置中把 Windows 10 加进去,引导文件指定为 ESP 分区里的 /EFI/Microsoft/bootmgfw.efi 即可。如此,则开机按 F12 键就能选择 Windows 10 系统了。
当然,再多做一些工作还可以把 Windows 10 加入到 Ubuntu 的 Grub 引导菜单中,本文不再赘述。