Fedora 36 Doesn't Boot

Z

Zshrc

Member
Trying to install the latest build of Fedora Linux 36 found here but it gets stuck at this screen after selecting "Install Fedora" in GRUB. I believe UTM had a similar issue that boiled down to a bug in QEMU introduced with Linux Kernel 5.17. Not saying Parallels uses QEMU, but could they be related? Should note this is on an M1 Mac using an arm64 image.
Screen Shot 2022-03-15 at 08.29.01.png
 
I have the same issue on updated Fedora 35 with Linux 5.16.14-200 on MacBook Pro with M1 Pro. VM boots without issues with Linux 5.14.10.
 
Another me too post. My fedora 35 vm started hanging after I updated the kernel from 5.16.13 to 5.16.14, so that narrows it down.
 
This must be another M1/ARM issue. My Intel mbp had no issues with 5.16.14.
I'm looking for a late 2019 Intel i9 to replace my early 2013 i7 mbp. Too many problems with M1 for this and other things. I kinda hate Apple for doing this.
 
Confirmed M1/ARM, Same issue with Ubuntu 20.04 LTS ... kernels 5.4.0-90 and 5.4.0-100 are OK, but 5.4.0-104 breaks with EFI_RNG_PROTOCOL

Note that the same EFI_RNG_PROTOCOL message appeared in the previous kernels, but 5.4.0.104 doesn't gracefully continue. Boot switches avoiding EFI fail.
 
Same problem for me on M1 MBP. Arch linux fails to boot, it simply hangs on bootloader screen (systemd boot). I set up a fresh ubuntu VM to chroot into my arch install to tinker with the bootloader, and after restarting the Ubuntu VM I encountered the same boatloader issue too (GRUB 2.04), however it was possible to use boot options from grub to get linux to start. Either way this is a crippling issue for Parallels and it needs to be patched as soon as possible.
 
I have the same problem with both OpenSUSE Leap AND Debian.
It seems as if there is an issue in support for the 5.10.0-13-arm64 kernel. I can, for either VM, reboot to the previous kernel, and it's working fine.
This is the first time I've had a problem like this with multiple distributions (usually it's only one that fails, and I end up reinstalling from a current ISO and it works).
 
Me too. My f35 vm with kernel 5.16.14 is booting after updating to parallels 17.1.2. A kernel rebuild with the latest tools was not necessary.
 
Tools rebuild/reboot was indeed still necessary.
Now, if they could finally remove the prl_vid reference from their dracut parallels_tools.config file. It keeps generating errors during a dnf kernel update.
 
Mark Fine said:
Tools rebuild/reboot was indeed still necessary.
Now, if they could finally remove the prl_vid reference from their dracut parallels_tools.config file. It keeps generating errors during a dnf kernel update.
Click to expand...
I couldn't get Parallel Tools to compile. Resulted in an error. What did you do to fix it?
 
Something's changed in 5.17.0 that broke the toolgate interface in prltg.c. Looks like it broke in several places, no less.
If you want the Parallels Linux team to be ahead of the power curve on beta releases you may be chasing your tail until late April or May, when the official F36 is released... and even then it's not a guarantee.
 
I'm in the same situation, Fedora 35 won't start after updating the kernel to 5.16.16-200 any ideas? I have the latest version of Parallels installed
 
Mark Fine said:
Something's changed in 5.17.0 that broke the toolgate interface in prltg.c. Looks like it broke in several places, no less.
If you want the Parallels Linux team to be ahead of the power curve on beta releases you may be chasing your tail until late April or May, when the official F36 is released... and even then it's not a guarantee.
Click to expand...
It's actually a pretty easy fix. It regards this commit and is a one-liner fix in Parallels tools. I've submitted the fix to Parallels Support, whether or not they implement it before Fedora 36 is beyond me ;)
 

Attachments

These kernel updates are coming 2 per week now. The chances of at least one new thing breaking in the next 7-8 weeks is pretty high.
 
You must log in or register to reply here.
Back
Top