Parallels 17 + Ubuntu 20 crashing every time
- Thread starter PabloD
- Start date
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'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.
JohannesH5
Bit poster
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?
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.
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".
David K. Hess
Junior Member
Seeing the same thing on 18.04 with a recent upgrade to kernel 4.15.0-156.
David K. Hess
Junior Member
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.
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.
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.
David K. Hess
Junior Member
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!