Can you try removing "quiet splash" from the kernel command line arguments in grub and add "verbose" ?

Yup. I will do it now.

I went into the grub options and changed quiet splash to verbose but I got the same error results as the recovery mode. Images attached as proof.

Screen Shot 2022-03-21 at 15.13.57.jpg (190,282 bytes)   

Screen Shot 2022-03-21 at 15.13.57.jpg (190,282 bytes)   

Screen Shot 2022-03-21 at 15.14.22.jpg (210,633 bytes)   

Screen Shot 2022-03-21 at 15.14.22.jpg (210,633 bytes)   

Screen Shot 2022-03-21 at 15.13.28.jpg (107,900 bytes)   

Screen Shot 2022-03-21 at 15.13.28.jpg (107,900 bytes)   

I'm seeing the same issue here, I'm updating my VMWare install just to test if it's an issue in Parallels or with the kernel itself.

We do keep older kernels installed, so you should be able to choose an older kernel from the advanced menu, as a workaround, for now.

VMware Fusion shows the exact same issue.

Actual hardware (Pinebook Pro) does not have the issue. It could be due to an EFI change in the kernel version, I will have to look over the changes from kali4-kali5 to check.

I'm still not entirely sure if the bug is in the kernel itself, or in the virtualization softwares, but when I add more to the kernel command line (console=efifb earlyconsole=efifb efi=debug) I end up with:

efibug.png (29,772 bytes)   

efibug.png (29,772 bytes)   

Upstream mailing list issue https://lore.kernel.org/all/[email protected]/ - this appears to be a hypervisor issue, so we likely need to contact Parallels and VMWare about this. Looks like it is the back ported fixes for Spectre v2 mitigations that is causing the issue.

Based on a read through the thread, as well as the linked QEMU issue, this will be hitting Parallels, VMware Fusion as well as UTM (based on QEMU), until they all update (QEMU update is possibly available already?) due to no ID register is allowed to be undefined (UNDEF).

I was also experiencing this issue - running macOS Monterey 12.3 on a MacBook Pro with M1 Max so kali ARM VM in Parallels. Ended up blocking the linux-image-arm64 and linux-headers-arm64 packages from updating as a workaround. I just updated to Parallels 17.1.2 and ran a dist-upgrade, bringing the kernel to linux-image-5.16.0-kali5-arm64 / 5.16.14-1kali1. It worked fine with no more hang after "Loading initial ramdisk", so one of those two changes must have addressed the problem.

The changelog for Parallels does not specifically state that it fixed this issue, but does say the update "addresses overall stability and performance issues."

Good enough!

If it helps anyone, here are notes for reference on holding back those two packages as a workaround but letting everything else update. I attached it as an image because the DPI on the firewall for this bug tracker seems to think these notes are an exploit when they are included in-line or as a text attachment.

hold back kernel.png (243,754 bytes)   

hold back kernel.png (243,754 bytes)   

We do have a kernel package in the kali-experimental repository with the 3 commits that cause this breakage removed, however, with 17.1.2 of Parallels, you should be okay now. Unfortunately, we're still waiting for a fixed version for VMware Fusion.

We won't be carrying these reverts forever, so hopefully they have a new release soon. I'll try pinging the VMware person I know on Twitter and see if we can get a response.

We have added linux-image-5.16.0-kali6 to the kali-rolling repositories which has the patches reverted, so this bug is now resolved. Thanks for the report!