今天尝试将 Ubuntu 18.04 升级到 20.04。该系统是在 Hyper-V 上作为虚拟机运行的服务器类型安装，主要运行 letsencrypt 和 nginx。
实际上我尝试了两次，两次升级都让我的系统无法默认启动。第一次尝试是，我尝试接受 boot/grub 菜单的维护版本，但由于无法正常重新启动，我又尝试了一次，这次保留了自己的版本。两次升级都让我的系统无法启动。
第二次升级时，我又做了一些实验。系统重新启动后，我被卡住了，无法启动。当我关闭电源并再次打开电源时，我得到了一个启动菜单，其中包含 Ubuntu、Ubuntu 高级选项和 UEFI 固件设置选项。使用高级选项，我得到了具有各种内核选项的 Ubuntu，带有 Linux 5.4.0-73-generic（无恢复模式）和 Linux 4.15.0-143-generic（无恢复模式）。带有 4.15.0-143 的变体实际上可以工作，而 5.4.0-73 则不能工作。
我确实有一些运行 20.04 和内核 5.4.0 的虚拟机，因此我认为这是升级或以前的安装导致的问题。
知道要寻找什么吗？
谢谢，约阿希姆
答案1
我昨天也遇到了同样的问题。如果我接受 boot/grub 菜单的维护者版本并接受升级到 grub2，虚拟机在升级后不会启动。
我认为问题在于升级到 grub2。我尝试在终端中使用 ssh 连接以正常顺序升级虚拟机服务器
sudo apt update
sudo apt upgrade
sudo upt autoremove
sudo apt dist-upgade
sudo do-release-upgrade
第二次尝试升级时，提示“正在计算更改”。在此之前，升级已将存储库更改为 20.04 存储库，当我按下 ctrl-c 时。我尝试手动升级上面的迭代命令。我收到同样的问题，要求我接受使用 Grub 2 进行链式启动，并使用 menu.lst 中的设置，我回答不。它建议我运行“upgrade-from-grub-legacy”，但我没有这样做。
结果是我的虚拟服务器中有 20.04 软件包，但它运行的是 4 系列的最新 Ubuntu 18.04 内核，使用旧版 grub，该 grub 使用 menu.lst，但不使用 grub.cfg，但系统在升级内核时使用 grub.cfg，而那些更新的内核不是将在我的虚拟服务器上运行的内核。
问题是，如果我不运行“upgrade-from-grub-legacy”，虚拟是否会在启动时再次挂起？我可以尝试，但备份需要一些时间。这能解决问题吗？5 系列 20.0.4 的内核基本上比 4 系列 18.0.4 的内核更好，因为奇数系列是稳定的，偶数系列是开发人员的，所以在产品时间内总是使用偶数系列内核是个坏主意，我不明白为什么 Ubuntu 在其一些 LTS Ubuntu 中使用偶数系列内核。这没有意义。
继续测试并备份虚拟服务器并运行“upgrade-from-grub-legacy”，输出（由于我的语言环境，某些输出是芬兰语）
core.img doesn't exist, trying to create it.
Asennetaan i386-pc-alustalle.
Asennus on päättynyt. Virheitä ei löytynyt.
dpkg: varoitus: version 'dummy-version' has bad syntax: version number does not start with digit
dpkg: varoitus: version 'dummy-version' has bad syntax: version number does not start with digit
Sourcing file `/etc/default/grub'
Sourcing file `/etc/default/grub.d/init-select.cfg'
Tuottaa grub-asetustiedoston ...
Linux-levykuva löytyi: /boot/vmlinuz-5.4.0-73-generic
Löytyi initrd-levykuva: /boot/initrd.img-5.4.0-73-generic
Linux-levykuva löytyi: /boot/vmlinuz-4.15.0-143-generic
Löytyi initrd-levykuva: /boot/initrd.img-4.15.0-143-generic
Linux-levykuva löytyi: /boot/vmlinuz-4.15.0-122-generic
Löytyi initrd-levykuva: /boot/initrd.img-4.15.0-122-generic
Linux-levykuva löytyi: /boot/vmlinuz-3.2.0-23-virtual
Löytyi initrd-levykuva: /boot/initrd.img-3.2.0-23-virtual
Linux-levykuva löytyi: /boot/vmlinuz-3.2.0-23-generic
Löytyi initrd-levykuva: /boot/initrd.img-3.2.0-23-generic
Linux-levykuva löytyi: /boot/vmlinuz-2.6.32-33-server
Löytyi initrd-levykuva: /boot/initrd.img-2.6.32-33-server
Linux-levykuva löytyi: /boot/vmlinuz-2.6.31-23-server
Löytyi initrd-levykuva: /boot/initrd.img-2.6.31-23-server
Linux-levykuva löytyi: /boot/vmlinuz-2.6.28-11-server
Löytyi initrd-levykuva: /boot/initrd.img-2.6.28-11-server
Linux-levykuva löytyi: /boot/vmlinuz-2.6.27-9-server
Löytyi initrd-levykuva: /boot/initrd.img-2.6.27-9-server
valmis
dpkg-maintscript-helper: error: environment variable DPKG_MAINTSCRIPT_NAME is required
如果我重新启动虚拟服务器，它会转到 grub（是 grb 还是 grub2？）并且我可以选择要启动的内核，但 /boot/vmlinuz-5.4.0-73-generic 不在列表中。如果我按回车键，则 uname -a 输出
Linux MyVirtualServer 4.15.0-122-generic #124-Ubuntu SMP Thu Oct 15 13:03:05 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux
这对于 menu.lst 配置文件有意义，但对于 grub.cfg 没有意义，因此旧版 grub 仍在运行。我现在无法尝试 5 系列内核。为此我必须升级到 grub2，但在虚拟机中如何做到这一点？
答案2
即使是进行小更新（而不仅仅是主要版本升级），也务必要确保更新 grub 时没有重大错误。如果确实出现错误，有时可以修复它们前重新启动。
如果您知道存在问题，请在升级结束时使用命令提示符重新运行 grub 安装程序，而不是重新启动。即使没有错误，这样做通常也是安全的。ubuntu 中的命令是：
update-grub
grub-install
第一个命令更新 grub 菜单，并查找新内核并删除不再可用的内核。第二个命令将重新安装 EFI 引导加载程序。如果您仍在使用旧版引导加载程序，则需要使用此命令指定要安装引导加载程序的驱动器。（对于旧版，您可以多次运行它，如果您从多个驱动器启动以实现冗余，并且您的 BIOS 支持它，则每个驱动器运行一次。）
当您重新运行这些命令时，您可能会收到错误，这些错误可能会指导您采取哪些措施来解决问题。例如，我最近不得不调整 EFI 分区的大小，因为 grub 引导加载程序已经增大。（幸运的是，它与交换分区相邻，所以这并不太难。）
请注意，如果单个内核安装出现错误，上述命令无法解决问题。例如，如果您有一个单独的 /boot 分区，并且它已满，则需要重新安装在已满时更新的所有内核。您可以通过调整分区大小或删除未使用的旧内核来解决这个问题。（最简单的方法是使用 apt autoremove 或 apt remove，但紧急情况下您可以小心地手动删除一些部分。）一旦有可用空间，您可以对每个受影响的内核包使用 dpkg-reconfigure 来触发 initrd 的重建和内核部分的复制。此外，有时 apt 会记住失败的内容，重新运行 apt upgrade 可能会给出下一步如何重新运行失败部分的指示。
如果 Ubuntu 18 到 Ubuntu 20 的升级触发了 grub legacy 到 grub2 的升级，网上有关于如何解决此问题的指南。过渡管理器允许您保留两个引导加载程序，因此您可以测试新的引导加载程序，但如果失败，则可以返回到旧的引导加载程序。使用新引导加载程序成功启动后，可以安全地完成指南中的步骤以删除旧引导加载程序。
请注意，如果您已经犯了重新启动的错误并且启动失败，并且 grub 菜单中剩下的任何选项都无法成功启动，最坏的情况是可以使用 ubuntu 20 安装介质在救援模式下启动并尝试修复。救援模式中有一个自动修复功能，有时可以正常工作，但您可能需要转到命令行，此时可以释放空间（或重新分区 - 但这很棘手）并再次尝试修复，或者 chroot 到已安装的操作系统并重试上述步骤以尝试手动进行修复。
请注意，对已安装的操作系统的磁盘进行重新分区或手动删除 /boot 中的内核片段是专家级操作，需要极其小心并充分了解所有后果。
答案3
我遇到了同样的问题，也遇到了同样的情况。我的问题更复杂，因为我的 qcow2 虚拟服务器映像文件的开头只有 32 个扇区可用，所以 grub2 未安装。我使用 gparted 修复了分区问题，并使用 qemu-nbd 移动了第一个分区以在主机中安装虚拟映像，然后使用 gparted 向右移动了第一个分区，即使我收到警告，如果分区中有 /boot，则很危险。现在我在 /dev/sda 的开头有 4096 个扇区可用。我只有 32 个扇区，这对于 grub2 安装的 core.img 来说太少了。
结果成功了，当我在虚拟服务器中安装了旧版 grub 时，它使用 menu.lst 设置启动成功 - 现在我可以运行
sudo grub-install /dev/sda
安装 grub2，它在 Ubuntu 20.04 中使用，并使用在系统更新时更新的 grub.cfg。但是使用 grub2 启动后失败，如果我强制关闭电源并打开，我会看到 grub2 菜单，我可以在菜单中选择 5 系列内核，但它无法启动，内核崩溃并锁定。
如果我进入 grub2 启动菜单并选择最后的 4 系列内核，虚拟服务器就会启动并且似乎运行正常。
因此，我们有 2 台虚拟 Ubuntu 20.04 机器，它们不运行 5 系列内核，但可以运行 4 系列内核。我的看法是，Ubuntu 的页面应该有一个警告，在解决此问题之前，不应将虚拟机升级到 20.04！