Official ubuntu-20-04-live-server does not boot

Hi,
I am on Parallels Desktop 17 for Mac Pro Edition version 17.1.1 (51537) on a Macbook Pro M1 with MacOS Monterey 12.2.1. I have downloaded official ubuntu-20-04-live-server-arm64 images from the Ubuntu web site and installed them using Parallels. After the installation completes successfully, the VM reboots and then it freezes on EFI stub messages (screenshot attached). The VM is unable to boot into Ubuntu OS.

I have tried ubuntu-20-04.4-live-server-arm64.iso ubuntu-20-04.3-live-server-arm64.iso and ubuntu-20-04.2-live-server-arm64.iso, but the same behavior occurs: installation works, but it freezes when booting the installed OS.

Earlier, I was able to install and run ubuntu-20.04 under Parallels (same M1 system), but now it does not seem to work anymore. I have an older Ubuntu 20.0.4 installation and I am able to boot into it. I have not tried to update it, and I will probably wait with that until there a workaround in case it gets stuck as well.

When using the "Download Ubuntu Linux" option under the Installation Assistant, the installation works it is able to reboot. However, that does not help my use case where I need to install from the official image.

I have tried setting vm.bios.efi=0 under Hardware-->Boot order-->Advanced settings but it did not help. I also tried having the ISO "loaded" in the CD device during boot (another suggestion from your site), but that did not help either.

Looking forward to some advice on how to proceed.

Regards,
Dragos

 

Hello all,

Same thing here. Not able to install Ubuntu Server 20.04.x from official site. However a previous (months ago) VM installed using official ISO (20.04.02) is working flawlessly.

Looking forward for instructions for a workaround or fix available.

Regards,

Hernan

 

Same problem here.

 

Same here, very odd. Updated today and this error occurred. Tried reinstalling with original iso but issue persists. Ubuntu desktop works normally.

 

Same problem here.

 

I have the same problem. Actually, I had a previous Ubuntu VM running on a previous version of Parallels on my M1 Mini (Monterey) that was running just fine. I updated Parallels, updated Ubuntu with apt and it stopped working with the same EFI stub error. The desktop version downloads, installs and works just fine. The server version does not.

Please help, this is a show-stopper for me!

 

I have the same problem and I've been struggling with it for days. Any Ubuntu version after 18.04 refuses to boot unless you boot from the previous kernel. It seems that kernel 4.15.0 works, but 5.4.0 (after upgrading Ubuntu 18.04 to 20.04) does not. Nor do any other later kernel versions (tried natively installing Ubuntu 20.004 and 21.10). I would dearly love to know a work-around for this issue if anyone has got to the bottom of it!

 

I have experienced the same problem. I deleted the Ubuntu and reinstalled it from Parallels. But this time I didn't update Ubuntu and I didn't install Parallels Installation Tools. I have been testing it by powering off and restarting. So far it seems to be working. I hope the Parallels team can find a better solution to this problem. It is really nervous to work with an unstable vm.

 

I contacted Parallels Support on twitter and they told me to send them technical data via "Help" -> "Send Technical Data..." (according to this link: https://kb.parallels.com/9058 ) when the bug occurs.

 

Same here. Today I restarted the VM and it does not boot anymore. I get the same as the screenshot above when trying to boot with recovery and this when choosing the standard boot:

 

It seems to be a kernel issue, "5.13.0-35" doesn't boot.
Went on a hunt yesterday, not just Parallels but all other VM software is the same. One has already rolled out a fix.
Submitted a support ticket, hopefully they investigate.

 

I am having the same issue with Ubuntu 20 Server and Desktop:

• Ubuntu 20.04.4 Server hangs with 5.4.0-104, but I can boot if I select 5.4.0-91 during Advanced boot options
• Ubuntu 20.04.4 Desktop hangs with 5.13.0-35, but I can boot if 5.13.0-25 is selected.

As a temporary workaround:

• /etc/default/grub - GRUB_DEFAULT=0 -> GRUB_DEFAULT='Advanced options for Ubuntu>Ubuntu, with Linux 5.4.0-91-generic'
• update-grub

Hoping for a quick resolution from Parallels as this is a significant impact to our current workload.

 

SO after some tries and every time I installed a new Ubuntu from the standard Parallels installation I was getting the same error after the second reboot. I now did this command right after Ubuntu installation to prevent automatic updates of the kernel and it seems stable for now...

I checked the kernel version with "uname -r" and then made it hold with:

Code:

sudo apt-mark hold 5.13.0-25-generic

 

Who has the fix? Do you have a pointer to the issue or fix? The other commercial desktop VMM I tried also had the same issue as parallels

 

Hello all,

I was able to boot from Ubuntu 21.04 iso image using 5.11.0-49-generic kernel.
Tried with 21.10 but 64K boundary image error appeared.
BTW, when installing, I cancel all security updates, just to keep original iso files deployed.

Regards,

 

UTM

 

If anyone from parallels is listening this is probably because the newer kernels contain this kernel commit

commit 9e45365f1469ef2b934f9d035975dbc9ad352116
Author: Joey Gouly <joey.gouly@arm.com>
Date: Fri Dec 10 16:54:31 2021 +0000

arm64: add ID_AA64ISAR2_EL1 sys register

This is a new ID register, introduced in 8.7.

Signed-off-by: Joey Gouly <joey.gouly@arm.com>
Cc: Will Deacon <will@kernel.org>
Cc: Marc Zyngier <maz@kernel.org>
Cc: James Morse <james.morse@arm.com>
Cc: Alexandru Elisei <alexandru.elisei@arm.com>
Cc: Suzuki K Poulose <suzuki.poulose@arm.com>
Cc: Reiji Watanabe <reijiw@google.com>
Acked-by: Marc Zyngier <maz@kernel.org>
Link:
https://lore.kernel.org/r/20211210165432.8106-3-joey.gouly@arm.com
Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>

And parallels is probably aborting when it is being read, unimplemented system registers should Read as Zero / Write ignored rather than abort. There was a very similar bug in QEMU/UTM which was fixed last week.

 

That is to say unimplemented CPUID system registers should RAZ/WI not all unimplemented system registers.

 

Adding myself to the list....