【原创】Dell Latitude 5400 整顿纪录

dandycheung

笔者注：虽说本篇的操作是在 Dell Latitude 5400 上完成的，但其实是通用操作，其他品牌的电脑也都适用。

上半年来，把好几台中古笔记本出掉了。后果是手里有一堆 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 文件中的内容如下：

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 目录下把 bootm***.efi 和 boormgr.efi 两个文件复制到其中；然后再在 Microsoft 目录下创建 Boot 子目录，把 Windows 10 所在分区的 \Boot 目录下的 BCD 文件复制到其中。打开一个命令提示符（确保是具备管理员身份的），用 cd 命令进入到 Boot 子目录，然后执行以下命令序列（请注意 N 的实际用值，是 Windows 10 所在分区从 1 开始数的编号）：

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/bootm***.efi 即可。如此，则开机按 F12 键就能选择 Windows 10 系统了。

当然，再多做一些工作还可以把 Windows 10 加入到 Ubuntu 的 Grub 引导菜单中，不再赘述。