logo标签列表

升级到Ubuntu 19.10后找不到grub_file_filters。

grub219.04grubrescue19.10
我将Ubuntu从19.04升级到了19.10。升级过程没有出现错误，但是重启后，grub在启动时报错并进入了救援模式。
error: symbol 'grub_file_filters' not found. 
Entering rescue mode... 
grub rescue>

这是一台实体机器，而不是虚拟机，我在双启动中安装了Windows和Linux。
我通过ls命令找到了我的Linux分区，但不太清楚接下来该怎么做。
insmod normal也出现了相同的错误。
你可以尝试用以下方式启动你的系统：https://unix.stackexchange.com/questions/148041/recovering-from-grub-rescue-crash - nobody
我试过了。一旦我到达insmod命令，就会弹出相同的错误。 - Eugene msc
你有Ubuntu的实时会话吗？如果有的话，你熟悉如何构建chroot吗？ - nobody
很遗憾，对于你的两个问题，答案都是否定的。 - Eugene msc
3请参阅：如何使Grub菜单在启动时显示而不是出现Grub最小Bash样式？ - WinEunuuchs2Unix
OP已经有了一个解决方案，但在将18.04升级到20.04的过程中遇到了类似的问题，这是在一个装有2个SSD的W10-Ubuntu双启动系统上：除了使用grub-install/update-grub来修复Ubuntu引导（参考其他答案；同时从grub rescue开始），我还需要将MBR转换为GPT https://www.windowscentral.com/how-convert-mbr-disk-gpt-move-bios-uefi-windows-10 （从BIOS转换为UEFI）在我的W10 SSD上，以便另一个update-grub可以重新添加W10到grub引导菜单。 - Blupon
11个回答
在我的情况下，我有一个Xubuntu 18.04的虚拟机，在升级到20.04之后，出现了grub错误。所以我按照这里所描述的步骤进行操作，这是针对Kali的，但对于任何Linux / grub安装都应该适用：

  1. 使用Ubuntu / Xubuntu ISO Live进入实时模式（我使用的是Ubuntu 20.04，因为我已经在我的计算机上下载了它）。

  2. 一旦进入内部，我打开了终端并运行了以下命令：

# So we can run the next commands as `root`:
sudo su

# To figure which partition had my Xubuntu installation (partition type `Linux`)
# in my case it was `/dev/sda1`, we can use:
fdisk -l
# If you used a logical volume, your volume should be named `/dev/mapper/ubuntu--vg-root` and not `/dev/sdxx`

# Let's mount a few things:
mount /dev/sda1 /mnt
mount --bind /dev /mnt/dev
mount --bind /dev/pts /mnt/dev/pts
mount --bind /proc /mnt/proc
mount --bind /sys /mnt/sys

chroot /mnt

# Now let's try to fix Grub:
grub-install /dev/sda

如果一切顺利，您应该会看到一条类似的消息：
安装完成。没有报告任何错误。
现在我们可以进行清理和重启操作：
# To change back chroot:
exit

# And now we can umount all:
umount /mnt/dev/pts
umount /mnt/dev
umount /mnt/proc
umount /mnt/sys
umount /mnt

# Now we can reboot:
reboot
3当我从Ubuntu 18.04 LTS升级到20.04时，我遇到了同样的问题。按照这个答案中的指示，使用Ubuntu 20.04的启动盘完美地解决了我的问题。 - afosbenner
我也将我的ThinkPad W520从18.04升级到了20.04，遇到了同样的问题。按照上面的方法（我有Ubuntu 18.04的ISO文件），问题得到了解决。非常感谢你和视频的帮助。 - Bashar Al-Abdulhadi
今天差点让我心脏病发作，试图将Ubuntu 18.04升级到20.04，但只需要快速重新安装grub，系统就恢复正常运行了。 - Silvio Mayolo
我有一个EFI引导分区，这个步骤中需要额外挂载吗？ - Bram
如果你遇到关于“blocklists”的错误，请尝试使用“--force”选项。 - Trake Vital
有相同的问题，通过启动一个 19.10 "救援" USB 启动盘，然后在终端中修复：（其中 sda 是您的磁盘，sda1 是磁盘上的分区。）
$ sudo mount /dev/sda1 /mnt
$ sudo grub-install --root-directory=/mnt /dev/sda

注意 - 如果您有多个物理磁盘，您的BIOS可能会在另一个磁盘上查找。您可能需要为每个物理磁盘执行此操作。
1这个应该是答案。只需要重新安装Grub即可。如果你在从18.04升级到20.04的默认Ubuntu升级过程中遇到这个错误，可以通过启动一个Live Ubuntu USB驱动器，进入shell并输入这些命令来解决问题。对我来说只花了3分钟就解决了。 - G_Style
我同意，这个方法在从Ubuntu 18升级到20的过程中帮助了我。 - MadPhysicist
升级到Ubuntu 20后，对我来说很有效。挽救了我的下午。谢谢！ - Anne Gunn
1如果我执行info grub-install，我没有看到root-directory这个选项，但是有一个boot-directory选项。你确定这个信息是正确的吗？ - Bram

我无法让 boot-repair（或 boot-repair-disk）运行，但通过从一个带有 Ubuntu 19.10 的 Live USB 启动、挂载旧硬盘、进入 chroot 并运行 grub-install 和 update-grub 来解决了这个问题。

这里有一个launchpad bug，建议采用这里描述的 chroot 解决方法。

我在更新到Ubuntu 19.10后也遇到了完全相同的问题。以下是我（刚刚）解决它的方法：
首先，你有两个问题，而不是一个。你的安装出了问题，Grub引导加载程序也乱了。只运行一个修复程序是无法解决所有问题的。你需要使用"boot-repair-disk"和最新版本的Ubuntu（都在USB启动驱动器上，不要使用DVD）。
如果你首先尝试从Ubuntu Live光盘进行"修复安装"，完成后仍然会看到"grub rescue>"提示符。所以，首先你必须使用"boot-repair-disk"。告诉它修复带有Ubuntu的损坏引导分区。如果你不确定分区ID，可以从"开始"菜单（左下角）启动"GParted"。
修复引导分区。这至少应该能恢复Grub。尝试启动Ubuntu。如果可以正常工作，那就完成了。如果不能，从USB启动Live "CD"。
双击桌面上的“安装Ubuntu 19.10”图标（不用担心，会有一个选项可以修复而不丢失旧程序/文件）。
我建议在安装过程中勾选下载所有更新，包括第三方软件。
安装程序应该能检测到您损坏的分区并给出修复选项（第一个选项）。可能需要禁用一些第三方软件源。这没什么大不了的，稍后可以轻松恢复。
（注意：如果之前需要输入密码登录，请不要尝试选择“无密码登录”。完成后将无法进入系统。）
完成后，您应该已经安装了Ubuntu 19.10，并且大部分/全部现有应用程序仍然安装在系统中（尽管工具栏快捷方式将被重置）。我不得不重新安装一些第三方应用程序，但它们的配置仍然存在，所以没有丢失任何数据。
我大约一周前也遇到了完全相同的问题。我通过从sourceforge下载boot-repair-disk来解决它。如果你有合适的CD驱动器，你需要制作一个可启动的USB键或CD。关于如何做这个的在线指南有很多。希望你能够在一个可以操作的系统上完成这个步骤。你可以在Windows上完成它。
也许可以通过grub rescue提示符和grub提示符来修复它。我首先尝试了这个方法，但是按照我在网上找到的指南没有成功。
祝你好运！
我只能通过使用一个活动的USB启动盘和引导修复来解决这个问题，就像WinEunuuchs2Unix的评论中所说的那样。在grub rescue模式下尝试的任何操作都没有起作用。 - Eugene msc
谢谢。我做了同样的事情，而且成功了。我使用Ubuntu Live CD中的Ubuntu会话将ISO文件写入了一个USB设备中。 - mfnx
我在双系统中遇到了类似的问题。运行了一次引导修复，并按照所有步骤进行操作，结果一切恢复正常。
重复接受答案的副本 - karel

对于在升级云端虚拟系统时遇到此问题的读者们，您可以通过重新安装 grub 并在系统升级之前执行update-grub来减轻这个问题。也许仅在重新启动进入升级后的系统之前更新 grub 就能够减轻这个问题，但我不愿冒险，并且现在没有时间测试。

我以艰难的方式学到了这一点，但幸运的是（或许我应该说自然地？）在尝试进行系统升级之前，我有一个系统的快照，因此在阅读了可能的原因后，我恢复了快照，重新执行了系统升级，然后重新安装了 grub。

遗憾的是，在云服务提供商的文档中还没有记录这个问题，或者在找到解决方法之前，无法保证面临这个问题的用户们已做好准备。

我还在 Launchpad 中报告了相关问题。

我正在将我的解决方案复制到这里，似乎这个更明显一些。
不起作用的方法：
  1. 我遇到了同样的问题，@rapid3642提供的解决方案不起作用。对于我来说，CHROOT情况并不适用，因为我可以使用并且能够正常登录到Linux。我还尝试在Ubuntu系统/分区上直接运行上述命令（没有挂载部分，因为我已经安装并运行了Ubuntu）。
  2. Rescatux也没有起作用，尽管它似乎是一个清洁的图形界面实用程序。
我使用了Kristina Kovacek的评论来了解我们需要做什么。
我找到适合我的解决方案是使用boot-repair-disk工具。有趣的是，它在默认模式下并没有起作用（即Recommended Repair部分），而是需要进行以下更改：
高级选项 -> Grub位置
  1. 将默认引导操作系统更改为Linux（是的，您可以登录Windows，但需要保留Linux作为主操作系统）
  2. 取消勾选独立的/boot /boot/efi分区
  3. 将Grub安装到<您的Linux分区，例如/dev/sda>
我还删除了另一个选项，确保GRUB默认查看Windows，但我不记得具体是什么（尽管我刚刚执行了该过程几分钟前）。
请注意，有一些需要遵循的说明和需要手动执行的命令，其中包括从Linux分区中清除grub-install（回顾起来可能已经足够）。
我相信事情可以用其他方法来完成，特别是@mugsy的答案似乎差不多。然而，我的答案没有使用Gparted和任何高级工具。