卸载/安装操作系统时删除grub

我有两个分区,每个分区都安装了ubuntu。

我使用g-parted live删除了其中一个分区,当我重新启动时,我预计grub仍会显示其他分区,并在其上启动Ubuntu。 然而,相反,我得到一个错误,我不记得它说了什么,但它不会让我启动。

我不得不创建另一个分区并再次安装Ubuntu,只是为了让grub回来,这很痛苦。

几天后我创建了另一个分区并在其上安装了Windows 7,并且在启动过程中,grub再次消失,它只会从Windows启动,即使我在另一个分区上安装了Ubuntu。 所以,再次,我必须创建一个新的分区并安装Ubuntu只是为了让grub回来。

在创建和删除分区时有没有办法保持grub?

你总是可以用Boot Repair来修补你的grub。 对于那些需要它的人来说,这是一个非常有用的指南,或者如果你的grub因加载另一个操作系统而消失。

正如SimplySimon所说,启动修复有时可以解决问题。 然而,要了解正在发生的事情,有两种情况:

BIOS

在传统的基于BIOS的计算机上,固件(BIOS)读取硬盘的第一个扇区(也称为主引导记录,或MBR)并执行它包含的代码。 因此,MBR中的任何代码都控制着计算机的引导过程。 (现代计算机通过允许您指定要引导的硬盘来提供有限的控制,但这仅适用于多磁盘计算机。)

为了使计算机可引导,OS安装程序必须能够将引导加载程序安装到MBR。 也就是说,一些安装程序使此步骤可选,依赖于用户知道何时已安装另一个引导加载程序。 微软一直在为MBR 操作安装引导加载程序,而针对经验较少的用户的Linux发行版近年来也采用了相同的方法。

最终结果是您安装的最后一个操作系统将控制启动过程,除非最后安装的操作系统提供了专家级的启动加载程序安装控制。 如果这不是您想要的,则重新安装引导加载程序是唯一的选择。 Ubuntu的启动修复工具有助于自动执行此任务,但也有其他方法可以执行此任务。

EFI

较新的计算机使用EFI固件而不是BIOS。 (令人困惑的是,制造商和大多数用户继续使用术语“BIOS”参考EFI。这种用法在技术上是不正确的,恕我直言,它会引起混淆误解。)这些计算机将引导加载程序存储为EFI系统分区上的普通文件(ESP)。 您可以在ESP上存储任意数量的引导加载程序。 它们在通过Linux的efibootmgr创建的NVRAM条目或其他操作系统中的等效项中efibootmgr

当操作系统自行安装时,它通常会注册其引导加载程序并使其成为默认值; 但您通常可以在引导过程中按function键切换到另一个引导加载程序。 不幸的是,按下来管理启动过程的关键是完全非标准化的,有些计算机很粗鲁甚至在启动过程中甚至都没有激活键盘,因此可能无法做出这样的改变 – 至少,不是无需更改某些固件设置。

因此,在实践中,EFI行为看起来非常像BIOS行为:最后安装的OS的引导加载程序优先。 不同之处在于EFI下的恢复方法不需要重新安装引导加载程序; 它只需要使用efibootmgr或其他工具来更改启动顺序。 引导修复实用程序将执行此操作,但它还执行许多其他操作,其中一些通常是不必要的,并且从长远来看可能是有害的。 因此,我不是基于EFI的计算机上Boot Repair的忠实粉丝。 如果您很幸运,您的固件将提供永久调整启动顺序的方法,但此function相对较少。