Parallels 17 + Ubuntu 20 crashing every time

I installed a Demo version of Parallels 17 so I could run Ubuntu version of Linux. When I try to run Ubuntu I just see a black screen and no matter where I click the mouse and screen just freeze.

 

Hi,
Please reproduce the problem. Then go to menu of Parallels Desktop -> Help -> Send technical data. Post here the report number

 

Hi,

Thanks for reaching out, I have send the technical data, the report number is 377864754

 

I appear to be having the same issue.

I'm running Parallels Version 17.0.1 (51482) on an M1 MBP / Ubuntu 20.04.3 LTS (aarch64)

The issue appears to have started when Ubuntu released kernel 5.11.0-34-generic. If I reset my vm after Parallels freezes, I can get to the Grub boot menu and if I select the previously installed kernel (5.11.0-27-generic) it will boot fine.

If another data point is useful, I also sent in the technical data and the report number is 378312652.

 

I am running 21.04 Ubuntu and my VMs still work. However, after the 5.11.0-34 kernel release boot up takes a long time (like several minutes) it seems the kernel is doing some time of system integrity check that takes a long time. FYI.

 

Same problem. Fresh upgrade to Parallels 17. Downloaded Ubuntu 20.0.4. System update, reboot is crazy slow. Stop VM and start again. This time it stops with error:
ACPI Error: AE_NOT_FOUND, Evaluating _CRS ... etc

Has anyone had any luck in how to handle this?

 

Wait for two minutes and check if it booted.
If not, try to switch virtual terminal by pressing CTRL+F2/CTRL+F3 and so on.

 

The same problem occurs. It takes a few minutes to start Ubuntu. Definitely problems with 5.11.0-34 kernel compatibility.

 

Yep. I switched back to 5.11.0-31 version. My M1 Mac was showing high CPU usage on 5.11.0-34 in Activity Monitor.

 

Same here on a MPB Late 2019 with Intel, Parallels 17.0.1 under Big Sur. After BlackScreen for appr. 2min., Ubuntu 20.04.3 LTS is starting as usual but then its causing high CPU Load.

Can you please explain how to switch back to 5.11.0-31 ? I´am not so experienced with this kind of "switchback".

 

Seeing the same thing on 18.04 with a recent upgrade to kernel 4.15.0-156.

 

If I reboot from the previous kernel (power up VM, hold down SHIFT key until GRUB menu comes up, select "Advanced options for Ubuntu", select "Ubuntu, with Linux 4.15.0-154-generic") it comes up without a hitch.

 

I uninstalled the offending kernel from my VM. There are several ways to go about it. Command line using apt-get or my preferred way is using synaptic the gui front end for apt. It is not installed in Ubuntu by default but is in the repositories so just doing a sudo apt install synaptic will install it. Synaptic will update the grub boot loader after uninstalling the kernel.

In synaptic click on sections on the left and scroll through the list and click on kernel. Find the offending version in that list and right-click to mark it for unstall then click apply, then reboot.

 

@RayR2 and @DavidK35
Thank you very much to both of you. I´ve learned something new and my Ubuntu VM is running again without a problem.
kind regards UweP2

 

For what it is worth, my Ubuntu 20.04 grub boot gave me an option for:
Linux ubuntu20 5.11.0-25-generic #27~20.04.1-Ubuntu SMP Tue Jul 13 17:41:23 UTC 2021 x86_64 x86_64 x86_64 GNU/Linux
And that version also works.

 

I have Ubuntu 20.04 and I have a similar problem in 16 and, now, 17: it takes 2 minutes to boot and that gap can be seen in dmesg output. Until recently, it was fine but I can't tell if it was a Parallels update or a kernel update or what. The information you are providing above seems to be pointing to a kernel update. I have kernel 5.11.0-34-generic

I have found that changing the configuration of the VM so that the CD is NOT set as disconnected but is set to load an accessible or inaccessible ISO (inaccessible because it was deleted or moved) the boot delay disappears. It seems to be caused because Parallels is telling the kernel that a CD is available and the kernel is trying to find it. If you select an inaccessible ISO (e.g. the installation media which you deleted ages ago but which Parallels remembers in its list), you get a warning from Parallels that it will not connect the CD at boot time and it's sometimes true to its word, no delay. NOTE: I have had various luck with choosing a non-existing ISO image, hence the term sometimes!! You can select an image during the delay time during boot and it will immediately continue. If you don't have an ISO, download one from somewhere and try that you don't have to actually do anything with it except select it in the VM configuration.

It would seem that selecting 'disconnected' is not working. Connected to this is that system-udevd is ramping up to 100% CPU: investigation (udevadm monitor) shows that SR0 (the Virtual CD-Rom is constantly generating CHANGE events.) I created a systemctl service to disconnect the systemd-udev services and then reconnect them and this seems to prevent the 'runaway' systemd-udevd job but reading this thread and discovering the 'disconnected CD issue' makes me think that the service job is not needed. And indeed, disabling that service and rebooting with a connected ISO shows no runaway entries in udevadm monitor.

I don't know if this is connected to a kernel version or not but there is clearly something going on with Parallels attaching a CD-ROM when told not to. This feels like a Parallels bug: it should not be presenting a CD-ROM to the kernel if it is disconnected, or at least that's how I interpret that setting. Perhaps someone who has rolled back a kernel version can confirm that disconnected/connected ISO works properly.

 

Ping @Elric ^^^.

 

NOTE: I booted into an older kernel version with CD/DVD = disconnected and there is no problem. There is some interaction between Parallels and 5.11.0.34 kernel that is causing an issue.

 

Whoa dude! Nice sleuthing. I connected the Parallels tools iso to the VM as CD-ROM and the VM boots right up. Disconnect the CD-ROM and yes slow boot up. Nice find!

 

Also, if you want to boot into an older version of the kernel, press the ESC key when booting not the SHIFT key (at least in Ubuntu!) then take the advanced option displayed to you. Don't select a recovery version of the kernel.