VMware Communities
RoyalKinks
Contributor
Contributor

Can't start a Debian 11 VM after updating the kernel

Hi !

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 :

linux.png

Thx!

20 Replies
scott28tt
VMware Employee
VMware Employee

Which VMware product are you using?

 


-------------------------------------------------------------------------------------------------------------------------------------------------------------

Although I am a VMware employee I contribute to VMware Communities voluntarily (ie. not in any official capacity)
VMware Training & Certification blog
Reply
0 Kudos
RoyalKinks
Contributor
Contributor

I use VMware Fusion (up-to-date)

Reply
0 Kudos
scott28tt
VMware Employee
VMware Employee

The Tech Preview version of Fusion on an M1 Mac?

 


-------------------------------------------------------------------------------------------------------------------------------------------------------------

Although I am a VMware employee I contribute to VMware Communities voluntarily (ie. not in any official capacity)
VMware Training & Certification blog
Reply
0 Kudos
RoyalKinks
Contributor
Contributor

Yes, it's this one.

Reply
0 Kudos
scott28tt
VMware Employee
VMware Employee

Thread reported so moderators know it should be moved to the area for the Fusion Tech Preview.

 


-------------------------------------------------------------------------------------------------------------------------------------------------------------

Although I am a VMware employee I contribute to VMware Communities voluntarily (ie. not in any official capacity)
VMware Training & Certification blog
adaptiveoptics
Contributor
Contributor

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. 😉 

Reply
0 Kudos
RoyalKinks
Contributor
Contributor

Thx for the info 🙂

If you know what kernel security feature prevents to boot with the new kernel version I would be interested. 🙂

Reply
0 Kudos
ColoradoMarmot
Champion
Champion

the PM posted that this has been escalated as an issue.  Terrible timing coming a week after the update.

Reply
0 Kudos
rhaleblianbeta
Enthusiast
Enthusiast

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.

Reply
0 Kudos
Mikero
Community Manager
Community Manager

Technogeezer
Immortal
Immortal

@Mikero is that failure to release the firmware fb video device the root cause behind all of this, or are Spectre fixes to blame? I'm hearing some mixed messages on that one...

- Paul (Technogeezer)
Editor of the Unofficial Fusion Companion Guides
Reply
0 Kudos
thoschl
Contributor
Contributor

Reply
0 Kudos
adaptiveoptics
Contributor
Contributor

I have a feeling this problem is the same problem being addressed in the Ubuntu problem reported here:

https://communities.vmware.com/t5/Fusion-for-Apple-Silicon-Tech/Building-Ubuntu-VM-challenges/m-p/28...

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. 😉

Reply
0 Kudos
HansMeiserWtf
Contributor
Contributor

Same issue her ... any idea how to solve this?

Reply
0 Kudos
adaptiveoptics
Contributor
Contributor

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.

Reply
0 Kudos
ColoradoMarmot
Champion
Champion

Known issue - check here:         Tips/Techniques/Gotchas for the Tech Preview               

It's a bug in Linux that was introduced a while back.

Reply
0 Kudos
steevdave
Contributor
Contributor

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

steevdave_0-1656008131438.png

 

 

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...

 

Reply
0 Kudos
Technogeezer
Immortal
Immortal

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. 

- Paul (Technogeezer)
Editor of the Unofficial Fusion Companion Guides
Reply
0 Kudos
steevdave
Contributor
Contributor

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.

Reply
0 Kudos