☰

在添加带有 Ubuntu 16 的 SSD 后，双启动（Win7 + Ubuntu14）在 Win 7 上失败

tag-icon • tag-icon dual-boot hard-drive uefi ssd grubrescue
在添加带有 Ubuntu 16 的 SSD 后，双启动（Win7 + Ubuntu14）在 Win 7 上失败

我有一台华硕笔记本电脑，配备 HDD 并通过 grub2 实现双启动：Windows 7、Ubuntu 14。

当 5 年后 HDD 开始出现坏块故障时，我将 SSD 添加到 SATA 端口 2。我将 SSD 设为具有自己的 EFI 分区的单启动 Ubuntu 16 - 以便在有一天 HDD 完全发生故障时移除 HDD 并仅使用 SSD 继续运行。

我在从 Live USB 安装 Ubuntu 16 时手动对 SSD 进行了分区：在安装对话框中选择了“其他”，小心地将/boot/efi、/boot和挂载/到/home我刚刚从 Live USB 创建的 SSD 分区，并检查 HDD 分区是否处于“不使用此分区”状态。

不幸的是，我没有检查 HDD 上的 EFI 分区。因此，尽管指定 sdb1（SSD 的 /boot/efi）为 ，Use as: EFI System Partition尽管选择 /dev/sdb（SSD）为Device for boot loader installation，但引导加载程序最终还是位于 HDD 上，而不是我计划的 SSD 上。这是因为 HDD 上的 EFI 分区也配置为Use as: EFI System Partition。

由此产生的两个问题是：

  1. ESP（EFI）位于 HDD 上，而不是 SSD 上。

  2. Windows 7 陷入 grub 救援，而 Ubuntu 16 和 Ubuntu 14 都可以正常启动。我想知道这两个问题是否相关。

为了解决问题 1，我将 HDD 的 EFI 内容复制到 SSD 的 EFI，并更改/boot/efi映射/etc/fstab以指向 SSD 的 EFI（UUID=E2A1-9FFE，/dev/sdb1）：

# /boot/efi was on /dev/sda1 during installation
#UUID=40BE-2040  /boot/efi       vfat    umask=0077      0       1
# redirecting /boot/efi from /dev/sda1 to /dev/sdb1
UUID=E2A1-9FFE  /boot/efi       vfat    umask=0077      0       1

现在，Ubuntu 启动时会挂载正确的 EFI 分区（在 SSD 上）/boot/efi（尽管我没有检查是否使用了正确的 EFI期间启动时）。可以吗通过复制文件 + 更改 fstab 来解决问题 1？

和我该如何解决问题 2? 在 grub 中选择时Windows Boot Manager (on /dev/sda1)，我看到此错误和此配置set：

error: symbol `grub_term_highlight_color` not found.
grub rescue> set
lang=
locale_dir=
prefix=(hd0,gpt6)/grub
root=hd0,gpt6
secondary_locale_dir=

当选择Windows Boot Manager (on /dev/sdb1)grub 时，我看到这个错误和这个配置set：

error: file `/grub/x86_64-efi/normal.mod` not found.
grub rescue> set
prefix=(hd1,gpt6)/grub
root=hd1,gpt6

在 BIOS（UEFI）中，启动设备分别称为：

Windows Boot Manager (P0: ST1000...)
Windows Boot Manager (P1: Samsung SSD 850 PRO ...)

但是，当 USB 端口中有 Live USB 时，从 BIOS（Esc）中选择启动设备会产生数字移位一位的set输出：hd

error: symbol `grub_term_highlight_color` not found.
grub rescue> set
lang=
locale_dir=
prefix=(hd1,gpt6)/grub
root=hd1,gpt6
secondary_locale_dir=

和

error: file `/grub/x86_64-efi/normal.mod` not found.
grub rescue> set
prefix=(hd2,gpt6)/grub
root=hd2,gpt6

我觉得这样没问题，尽管不能 100% 确定这不是 Win7 启动失败的原因。

以下是来自启动修复的信息：从 pastebin 中的 boot-repair 中粘贴。

我担心运行启动修复程序，因为它建议修复似乎正在修复 Ubuntu 的启动问题，而不是 Win 的启动问题。（我仍未了解其rename-ms-efi含义。）

我也曾想过移除 SSD 并尝试仅使用 HDD 启动，但担心 EFI 分区会变得更加糟糕（例如通过自动修复），我将无法再启动到 Ubuntu 14。听起来可能很愚蠢。但毕竟，在原始 Win7 旁边引入 Ubuntu 14 会导致 grub 无法从休眠状态恢复 Win7。所以，我担心 grub 再次“做得很好”。

任何帮助都将不胜感激！

同时我将为 SSD 分区创建备份。

答案1

非常感谢您的提示，@oldfred！

我开始深入研究链条目，发现和/boot/grub/grub.cfg上的文件有所不同。来自 HDD（ ）的原始文件包含我用于启动 Win7 的菜单项，而的没有。我不记得自定义菜单项是我创建的还是在 Win7 旁边安装 Ubuntu 12 时由 grub 创建的。sdasdbgrub.cfgsdagrub.cfgsdb这和这可以帮助其他人手动创建自定义菜单项。

以下是我使 Win7 再次启动所执行的两个步骤：

  1. 将缺失内容/etc/grub.d/25_custom从复制sdb到sda。

内容/etc/grub.d/25_custom：

#!/bin/sh
exec tail -n +3 $0

menuentry "Windows UEFI bkpbootmgfw.efi" {
search --fs-uuid --no-floppy --set=root 40BE-2040
chainloader (${root})/EFI/Microsoft/Boot/bkpbootmgfw.efi
}

menuentry "Windows Boot UEFI loader" {
search --fs-uuid --no-floppy --set=root 40BE-2040
chainloader (${root})/EFI/Boot/bkpbootx64.efi
}

menuentry "efi/EFI/Boot/bkpbootx64.efi" {
search --fs-uuid --no-floppy --set=root 84ba8463-a7a4-4a32-a429-f28e606435f2
chainloader (${root})/efi/EFI/Boot/bkpbootx64.efi
}

其中40BE-2040和84ba8463-a7a4-4a32-a429-f28e606435f2分别是 HDD 上 Ubuntu 14 的 EFI 分区和 /boot 分区：

/dev/sda1: LABEL="SYSTEM" UUID="40BE-2040" TYPE="vfat" PARTLABEL="EFI system partition" PARTUUID="41d1ad3d-8c17-44cd-9e4f-e6554d3c532b"
/dev/sda6: UUID="84ba8463-a7a4-4a32-a429-f28e606435f2" TYPE="ext4" PARTUUID="7f61e2e3-7b36-49a0-a357-90032497db30"

sudo update-grub然后更新grub.cfg。

要启动 Win7，我使用第二个菜单项：Windows Boot UEFI loader。

  1. 如果您的加密交换分区损坏，请按照以下步骤恢复：punygeek.blogspot.com.ee/2012/10/ubuntu-1204-how-to-solve-disk-drive-for.html

在我的情况下，交换分区损坏可能是因为sdb在调查非唯一分区名称/标签是否是导致 Win7 无法启动的原因时更改了 EFI 分区的名称和标签。交换分区在 Ubuntu 16 启动时开始要求输入密码。我无法通过更新 和 中的 UUID 来修复它/etc/fstab。/etc/crypttab只有/etc/initramfs-tools/conf.d/resume上面的链接有助于修复加密的交换分区。运行sudo ecryptfs-setup-swap确实失败了，但重新启动后，交换分区被正确加密：

> lsblk
├─sdb3           8:19   0     8G  0 part  
│ └─cryptswap1 253:0    0     8G  0 crypt [SWAP]

并且的输出swapon -s与上面的链接显示的不同：

Filename                Type        Size    Used    Priority
/dev/dm-0                               partition   8388092 0   -1

但它似乎是正确的交换分区：

> ls -l /dev/mapper/cryptswap1
lrwxrwxrwx 1 root root 7 sept  25 14:02 /dev/mapper/cryptswap1 -> ../dm-0

相关内容