I can't start my Debian 11 VM with Linux kernel 5.10.0-13-arm64. I have to boot with 5.10.0-11-arm64. Anyone knows how to fix this ?
Maybe the latest kernel needs to load a specific module about VMware I don't know...
When I try to boot with the 5.10.0-13-arm64 kernel, I get stuck here :
Which VMware product are you using?
The Tech Preview version of Fusion on an M1 Mac?
Thread reported so moderators know it should be moved to the area for the Fusion Tech Preview.
Yes I just ran into this problem too - I have to boot into older versions of the kernel.
I read on another post here that a recent kernel security update has caused our VMWare virtualization to hang and that we need to wait for VMWare to address the "bug".
So it looks like manually booting into old kernel versions is the way to go for now. If I was reading good info. 😉
> what kernel security feature prevents to boot with the new kernel version
A pointer is here in the forum threads, if you can't find it somebody can repost it time permitting.
I have a feeling this problem is the same problem being addressed in the Ubuntu problem reported here:
And in that, it looks like in reading there that the solution is both a Linux kernel patch, and an update to VMWare, both of which have apparently been done.
Now it's a matter of the distributions putting out the new kernel release, and VMWare pushing out a new version of Fusion.
That's from my memory though which I wouldn't trust for a second. 😉
Well, I solved it by switching to using UTM instead. I know that's not a solution for VMWare, but I just couldn't wait any more.
I was very skeptical about UTM at first, but it's been performing flawlessly. I don't think it would do very well in a GUI environment though. Not sure.
It's easy to use if you're familiar with QEMU/KVM in Linux.
It looks like the same, or similar bug is back - recently Kali has updated to the 5.18 kernel, and I believe with 5.17 we had been reverting the patches. We are not reverting the patches anymore as I'd thought VMware had put out a release with the fix. It seems that either the same issue still exists, or due to use not reverting those patches anymore, it's finally rearing its head. This does not affect other virtualization systems.
Changing the boot options to add earlycon=efifb console=efifb and I see
Going to edit to add - I ran faddr2line vmlinuxfile __cpuinfo_store_cpu+0x84 and it just spits out __cpuinfo_store_cpu+0x84/0x260: ?? ??:0
So I'm not sure where to go from here...
I think there are two issues that VMware has not really described accurately.
One issue is related to the console graphics adapter memory provided by EFI. There’s another issue preventing boot that is much more pervasive with distributions including Ubuntu. This issue is not a Linux bug. It’s the failure of the Tech Preview to implement access to a valid ARM architecture CPU capability register. It looks like the Linux kernel started to access this register starting with the security updates in March. @Mikero hints about this in one of the recent posts but fails to do justice to it as the real reason that all of our latest Linux distributions have stopped working.
Actually no, it's the same issue, hitting ID_AA64ISAR2_EL1 causes the panic.
Sorry @Technogeezer the actually no was meant as a reply to my response, not yours!
In Kali, we had been reverting those patches, and I figured that there had been a release to fix that already.