Ubuntu fails to start by default after upgrade 18.04 to 20.04

Question

I tried to upgrade an Ubuntu 18.04 to 20.04 today. The system is a server type installation running as a virtual machine on Hyper-V, primarily running letsencrypt and nginx.

Actually I tried twice, both upgrades left me with a system that doesn´t boot by default. The first iteration was I tried to accept maintainer version for the boot/grub menu, and as that didn´t restart properly, I tried another time, this time keeping my own version. Both upgrades left me with a system that was not booting.

With the second upgrade, I experimented a little more. When the system restarts, I am stuck with it doesn´t boot. When I then power off and power on again, I get a boot menu with the options Ubuntu, Advanced options for Ubuntu, and UEFI Firmware Settings. With Advanced I get Ubuntu with various kernel options, with Linux 5.4.0-73-generic w/o recovery mode, and Linux 4.15.0-143-generic w/o recovery mode. The variants with 4.15.0-143 actually work, whereas 5.4.0-73 doesn´t work.

I do have some VMs that run 20.04 with kernel 5.4.0-something, thus I assume it is an issue caused by the upgrade or previous installation.

Any idea what to look for?

Thanks, Joachim

Answer 1

I had same problem yesterday. If I accept maintainer's version for the boot/grub menu and accept upgrade to grub2, virtual machine does not boot after upgrade.

I think problem is upgrade to grub2. I tried to upgrade virtual machine server with normal sequence in terminal with ssh connection

sudo apt update
sudo apt upgrade
sudo upt autoremove
sudo apt dist-upgade
sudo do-release-upgrade

With second try upgrading was hanging with 'Calculating changes'. Before that upgrade has been changed repos to 20.04 repos and when I pressed ctrl-c. I tried to upgrade manually iterating command above. I got same question to accept chained booting with Grub 2 with setting from menu.lst and I answered no. It advised me to run 'upgrade-from-grub-legacy', but I haven't done it.

Result is that I have 20.04 packages in my virtual server, but it is running last Ubuntu's 18.04 kernel from 4-series, using legacy grub which uses menu.lst, but not grub.cfg, but the system uses grub.cfg, when it upgrades kernel and those updated kernels are not those that will be on run on my virtual server.

Question is if I run no 'upgrade-from-grub-legacy' does the virtual hang again in the boot? I can try, but taking a backup takes some time. And does this fix the problem? Kernel from 5-series 20.0.4 is basically better idea than from 18.0.4 kernel from 4 series, because odd series is stable and even series is developer one, so always using even series kernel is bad idea in product time and I don't understand why Ubuntu uses even series kernels in some its LTS Ubuntus's. It does not make sense.

Contuned testing ans made a backup of virtuual server and run 'upgrade-from-grub-legacy', output (some output are in finnish, because my locales)

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

If I reboot be virtual server, it goes to grub (Is it grb or grub2?) and I can choose my kernel to boot, but /boot/vmlinuz-5.4.0-73-generic in not in the list. If I just press return then uname -a outputs

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

This makes sense withe menu.lst config file, but not with grub.cfg, so legacy grub is still in run. I can't try 5 series kernel now. For that I have to upgrade to grub2, but how it is done in a virtual machine?

Answer 2

Even when doing minor updates, not just major version upgrades, it is important to make sure there are no significant errors when updating grub. If you do get errors, it is sometimes possible to fix them before rebooting.

If you know there is an issue, instead of rebooting at the end of the upgrade, use the command prompt to rerun the grub installer. Even if there are no errors, it is generally safe to do this. The commands in ubuntu are:

update-grub
grub-install

The first command updates the grub menu and will find new kernels and remove ones that are no longer available. The second command will reinstall the EFI bootloader. If you are still using a legacy bootloader, you need to specify the drive to install the bootloader on with this command. (For legacy, you can run it multiple times, one for each drive if you which boot off of multiple drives for redundancy, and your bios supports it.)

When you rerun these, you may get errors, and those errors may guide you to what you have to do to resolve the situation. For example, I recently had to resize my EFI partition because the grub bootloader has grown. (Luckily, it was adjacent to a swap partition, so this was not too difficult.)

Note that the above commands do not fix problems if individual kernel installations get errors. For example, if you have a separate /boot partition, and it fills up, you will need to reinstall any kernels that got updated when it was full. You can fix this either by resizing the partition, or by deleting older kernels that are not being used. (Easiest is with apt autoremove or apt remove, but you can remove pieces by hand with some care in an emergency.) Once space is available, you can use dpkg-reconfigure for each affected kernel package to trigger a rebuild of the initrd and copying of kernel pieces. Also, sometimes apt remembers what failed, and rerunning apt upgrade may give directions on what to do next to rerun the failed parts.

If The Ubuntu 18 to Ubuntu 20 upgrade triggered an upgrade of grub legacy to grub2, there are guides online about how to fix issues with this. The transition manager allows you to leave both bootloaders installed, so you can test the new one but fall back to the old one if it fails. Once you've succeeded booting with the new one, it is safe to finish the steps in the guide to remove the old one.

Note that if you already made the mistake of rebooting and the boot fails, and none of the options left in the grub menu boot successfully, worst case it is possible to use the ubuntu 20 install media to boot in rescue mode and attempt repairs. The rescue mode has an automated repair in it that sometimes works, but you may need to drop to command line, at which point it would be possible to free up space (or repartition -- but this is tricky) and try repair again, or chroot into the installed operating system and retry the steps as outlined above to attempt to manually effect a repair.

Note that repartitioning disks for an installed OS or hand removing kernel pieces in /boot are expert level operations and require extreme care and full understanding of all the consequences.

Answer 3

I had same problem and came to same situation. My problem was more complicated, because I has only 32 sector free in the beginning of my qcow2 virtual server imagefile, so grub2 was not installed. I fixed partitioning problem with gparted and moved first partition with qemu-nbd to mount virtual image in the host and gparted to move first partition right even if I got warning that it is dangerous if partition has /boot as I had. Now I have 4096 sectors free in the beginning of /dev/sda. I has only 32 sectors and that was too little for core.img, that grub2 installs.

Result was successful so that when I had legacy grub in my virtual server, it booted OK using menu.lst settings- I could now run

sudo grub-install /dev/sda

to install grub2, which is used in Ubuntu 20.04 and which uses grub.cfg which is updated when system is updated. But after booting with grub2 it fails and if I force power of and on, I get grub2 menu, where I can choose series 5 kernel, but it fails to start with kernel panic dedlocked.

If I got in the grub2 boot to menu and choose last series 4 kernel, virtual server starts and seems to work OK.

So here we have 2 virtual Ubuntu 20.04 machines, that don't run series 5 kernels, but can run series 4 kernels. My opinion is that in Ubuntu's pages should be a warning, that virtual machines should not be upgraded to 20.04 until this problem is solved!