我通过安装 Kali 2017.3(讽刺的是,现在的 Debian 内核版本相同)4.14.0 86_64 重新安装了 Linux Parrot Security 3.9 内核版本 4.14.0 86_64。
现在我对硬盘进行了完全分区,像往常一样手动分区大小为/dev/sda1-boot 512M,/dev/sda2-swap 8G,/dev/sda3-/root-25G,/dev/sda4 /home-rest。
我有 2 个硬盘,按正确顺序首先启动 Linux,除非我按 F11,否则 Linux 硬盘位于第一个 SATA 电缆插槽中,而我在第二个 SATA 电缆插槽上有一个单独的 Windows 硬盘。我不喜欢在同一个硬盘上同时启动 Windows 和 Linux。
通常,当我开机时,我会按 F11 进行启动选项,两个 HDD 都会显示,我会进行相应的选择,我使用 Windows 进行游戏,使用 Linux 进行其他操作。
但是现在,当我按 F11 时,旧的 Kali 仍然是第一个选项,因为 /dev/sda3 Windows 作为第二个启动选项出现(因为它已经使用此设置一年多了),但 Parrot 也出现了/dev/sda3 (与应该被覆盖的 Kali 相同)我可以选择 /dev/sda3/Parrot 并且它工作正常。 Windows 工作正常,但如果我选择 /dev/sda3/Kali (应该已被覆盖),它会启动到 grub 错误,并且出现 grub saving> 提示。
最后,我一直使用的方式是 Linux 启动,除非我按 F11 并选择 Windows HDD,但因为我收到此 Grub 错误 Grub Rescue> 并且最后一个 Kali 的 Grub 似乎没有被删除,所以我总是必须现在按 F11。这并不是说我无法进入我的新 Parrot 操作系统,它现在构建在与 Kali 相同的内核上,我认为 Debian 9 只是一种不同的存储库更新方法。它工作得很好,我只是希望我的系统尽可能正确。
我应该怎么办?我似乎与 /dev/sda3 上有一个真正的发行版有冲突,而另一个人认为它有,但实际上没有?
答案1
按 F11 听起来就像您正在访问 BIOS 启动菜单。如果它包含 Windows、Parrot 或 Kali 等操作系统名称,则表明您可能正在使用 UEFI 样式启动。
如果这是真的,那么摆脱 Kali 残余的最便捷方法就是efibootmgr
在 Linux 中使用该工具。
在 UEFI 式引导中,有关引导加载程序的三项内容存储在 NVRAM(= 存储 BIOS 设置的位置)中:
- 包含特定操作系统的 UEFI 引导加载程序的分区的 UUID(这通常是一个小的 FAT32 分区,称为 ESP 或 (U)EFI 系统分区)
- 该操作系统的引导加载程序文件的名称
- 该操作系统的描述性名称
即使您完全删除特定操作系统的引导加载程序并覆盖其拥有的所有分区,该信息仍将保留在 NVRAM 中。某些 UEFI 固件将提供一种通过 UEFI BIOS 设置菜单删除任何过时的启动设置的方法,但不幸的是,市场上有一些 UEFI 固件版本没有该选项。
当您在 UEFI 系统中运行时efibootmgr -v
,您应该会看到当前存储在 NVRAM 中的 UEFI 启动设置列表。该BootCurrent
值标识最近用于引导系统的引导选项。有一个Timeout
值通常设置为 0。然后有一个BootOrder
列表,用于标识固件尝试各种配置的启动选项的顺序:每个启动选项由 4 位数字标识,例如 0000、0001、0002等等。
最后,还有实际的启动选项。每个引导选项行都会以“BootNNNN”的形式列出引导选项的四位数字(例如,Boot0000 表示第一个引导选项)。然后是操作系统的描述性名称,然后是引导加载程序分区 UUID 和该分区上的引导加载程序文件路径名。在该行的末尾,可以选择有一些引导加载程序的参数。
要删除 Kali 启动选项的残余部分,请在列表中找到其四位数字。然后就可以使用efibootmgr -B -b NNNN
删除它了。
例如,如果您看到 Kali 是引导选项 Boot0002,那么您可以使用以下命令将其删除:
efibootmgr -B -b 0002
该efibootmgr
命令必须以 root 身份运行(或以 前缀sudo
)。
答案2
我没有在这里寻求帮助的经验。如果管理员可以推荐正确的地方来询问这个问题,或者帮助我将其转移到正确的论坛,请提前致谢,如果这是错误的地方,我提前道歉。
你说得对,在这里,很好!然而,Parrot Security 和 Kali 是以安全为中心的发行版,不适合胆小的人!当您使用它们时,您应该是经验丰富的 Linux 管理员。
基本上,您遇到的问题是旧的 Kali grub 条目仍然存在。
grub 配置存储在其中,/etc/grub.d/*
因此您必须确保其中没有文件包含 Kali 条目,并且有 Parrot Security 条目。然后你运行sudo update-grub
它应该可以解决你的问题。
要检查 Kali 不存在:grep Kali /etc/grub.d/*
那么grep Parrot /etc/grub.d/*
,如果两个命令都找到“stuff”,并且两个条目不在同一个文件中,那么您应该可以安全地删除包含 Kali 的文件。