在外部驱动器上安装 Ubuntu Linux 后,无法在没有外部驱动器的情况下在内部驱动器上重新启动

在外部驱动器上安装 Ubuntu Linux 后,无法在没有外部驱动器的情况下在内部驱动器上重新启动

我在 Macbook pro 上使用 EFI 启动。 (我无法使用UEFI,因为机器太旧了。)

在内部驱动器上,我有 Ubuntu Linux 20.04。

我有一个不幸的想法,即通过 live USB 在外部驱动器上安装 Ubuntu Linux 20.04。 (我正在尝试使用增量备份进行克隆,显然没有现有的软件适用于 Linux。)

当连接外部驱动器启动时,我看到 GNU GRUB 2.04 启动菜单。默认情况下,外部驱动器将首先启动,但我可以选择在内部驱动器上启动。

当未连接外部驱动器时,我陷入 GRUB shell 中并且无法启动。我读过了如何在 Linux 上拯救无法启动的 GRUB 2但我总是以“结束内核恐慌...无法挂载 root fs...”结束。

无论如何,只要我仍然可以在没有 GRUB shell 的情况下启动,我只需要恢复内部驱动器即可正常启动 Ubuntu Linux。

这看起来很简单。

在内部驱动器上启动并断开外部驱动器后,我尝试过,sudo update-grub但没有帮助。

我尝试过更改启动顺序,sudo efibootmgr但情况变得更糟,因为我总是以 GRUB shell 结束。 (幸运的是,这种变化是可逆的。)

如果可能的话,最终我想摆脱 GRUB。 Mac 不需要 GRUB,因为当按下 alt 键启动时,它会在一个简单的图形菜单中显示所有可启动分区,因此无需 GRUB 即可轻松选择任何 EFI 分区并在其上启动。

第一次回答后编辑(谢谢)

“某些原因导致内部磁盘上的 GRUB 被重写”。是的,它是实时 Ubuntu Linux 安装程序,确实是一件危险的事情。我应该更加谨慎:在外部驱动器上安装 Ubuntu Linux 之前先卸载内部驱动器。事实上,我发现内部驱动器上的 /boot/efi 发生了一些变化。我完全按照中的说明恢复了文件Mac OS X 启动后 Ubuntu EFI 启动失败

重新启动后,连接外部驱动器后,我发现了一个新情况:没有 GRUB 菜单,所以我被迫使用 GRUB shell,但幸运的是我可以使用ls内部驱动器(而不是以前仅外部驱动器)并应用本教程如何在 Linux 上拯救无法启动的 GRUB 2在内部驱动器上启动。

所以现在我需要让启动自动进行,如果可能的话,保留在外部驱动器上启动的选项。

内部驱动器上的 grub.cfg:

mac2011-linux# pwd      
/boot/efi/EFI
mac2011-linux# more ubuntu/grub.cfg
search.fs_uuid 770e447c-7411-4cc7-bce4-b71504d828c3 root hd2,gpt4 
set prefix=($root)'/boot/grub'
configfile $prefix/grub.cfg

由于我没有单独的引导文件系统,因此前缀是正确的。我可以看到blkiduuid 770e447c-7411-4cc7-bce4-b71504d828c3/dev/sdb4外部驱动器上。这是不正确的。怎样才能修得干净呢?

mac2011-linux# ls
APPLE  BOOT  tools  ubuntu
mac2011-linux# mac2011-linux# ls -l BOOT
total 5367
-rwx------ 1 root root 1677176 mai 25 14:54 bootx64.efi
-rwx------ 1 root root 1334816 mai  8 21:48 BOOTX64.EFI-old
-rwx------ 1 root root 1213032 mai 24 23:04 fbx64.efi
-rwx------ 1 root root 1269496 mai 24 23:04 mmx64.efi
mac2011-linux# ls -l ubuntu
total 4183
-rwx------ 1 root root     108 mai 24 23:04 BOOTX64.CSV
-rwx------ 1 root root     126 mai 24 23:04 grub.cfg
-rwx------ 1 root root 1677176 mai 24 23:04 grubx64.efi
-rwx------ 1 root root 1269496 mai 24 23:04 mmx64.efi
-rwx------ 1 root root 1334816 mai 24 23:04 shimx64.efi

不知道ubuntu目录是否真正被读取。我知道 bootx64.efi 被读取,因为它是我自己安装的 grubx64.efi 的副本,并使 GRUB 针对内部驱动器。

现在我有了 GRUB,至少在我更熟悉 Linux 之前我会保留它,但我宁愿不添加 rEFInd,以避免额外的混乱。

我找到了这个ArchLinux 关于 GRUB 的文章特别是 UEFI 系统部分。这给了我检查 GRUB 安装的想法。我重复了sudo apt install grub2-common grub-efi-amd64一遍sudo update-grub,得到了一个/boot/efi/EFI/ubuntu/grub.cfg指向内部驱动器上正确分区的新指针。这可以修复内部驱动器上的干净重启问题。

看来 GRUB 没有正确安装在我的系统上。这可能是 Ubuntu Linux 20.04 发行版的一个小缺陷。

我仍然需要检查外部驱动器 Ubuntu Linux 是否也可以工作。

答案1

可能是某些原因导致内部磁盘上的 GRUB 被重写,因此它现在尝试从外部磁盘加载其配置。

首先,验证外部磁盘是否具有完全填充的 EFI 系统分区,并且/etc/fstab正确安装了 ESP外部磁盘的/boot/efi。如果缺少某些内容,请grub-install --force-extra-removable /dev/sd<external disk>在外部磁盘上重新安装 GRUB - 但是第一的确保正确的 ESP 安装到/boot/efi.

重新启动并使用efibootmgr -v。检查BootCurrent值和相应的启动项以验证系统是否确实做过完全从外部磁盘启动,并且没有回退到内部磁盘上的引导加载程序。现在您知道外部磁盘上有一个完全运行的 GRUB,它应该完全独立于内部磁盘。

然后挂载ESP分区内部的磁盘(如果尚未安装),并检查<mountpoint of internal ESP>/EFI/ubuntu/grub.cfg.它应该是一个小的 GRUB 配置文件,只有大约三行,告诉从哪里加载主 GRUB 配置文件。它通常通过 UUID 引用文件系统。它应该是这样的:

serch.fs_uuid <UUID of the filesystem containing /boot> root
set prefix=($root)'/grub'
configfile $prefix/grub.cfg

是的,即使第一行提到root,它并不一定意味着 Linux 根文件系统 - 它指的是 GRUB 的根,它是包含主 GRUB 配置文件和 GRUB 模块目录的文件系统。在 Debian/Ubuntu 中,这可能是 Linux 根文件系统或单独的/boot文件系统(如果/boot是单独的文件系统)。

如果该/boot目录包含在 Linux 根文件系统中,则可能会set prefix=$(root)'/boot/grub'改为第二行。一旦prefix变量设置正确,GRUB 将能够从中自动加载 GRUB 模块(例如,支持其他文件系统类型)。

这可能足以修复内部磁盘上出现故障的 GRUB。如果这没有帮助,您可能需要从外部磁盘启动,将内部磁盘的根文件系统挂载到/mnt,/boot内部磁盘的 , (如果它作为单独的文件系统存在)到/mnt/boot,将内部磁盘的 ESP 挂载到/mnt/boot/efi,等等直到您将内部磁盘的完整文件系统树安装在/mnt.然后 chroot 进入它:

mount -o rbind /dev /mnt/dev
mount -o bind /proc /mnt/proc
mount -o rbind /sys /mnt/sys
chroot /mnt /bin/bash

现在您应该能够grub-install /dev/sd<internal disk>在内部磁盘上重新安装 GRUB。此后,系统应该可以在拔掉外部磁盘的情况下再次启动。

摆脱 GRUB 在技术上是可行的,但根本没有引导加载程序(即使用内核中内置的 UEFI 存根)将使任何内核引导选项的使用变得极其尴尬。您首先需要启动到可以编辑 UEFI 启动项、添加/更改所需的启动选项,然后再次启动到“无引导加载程序”Linux。您可能想查看一些替代引导加载程序,例如rEFIndsystemd-boot

相关内容