Fedora 35 kernel 5.16.14 will not boot

[Technogeezer]

Fedora 35 just pushed an update to kernel version 5.16.14 - this will not boot. Prior kernel 5.16.11 would boot ok. There's no response from the kernel after GRUB loads it.

@treee and I have both encountered this. I

This issue also impacts OpenSUSE Tumbleweed as it's using the same kernel version.

So either something is broken in that kernel, or there's something that it doesn't like with the TP. Either way this is a potential showstopper for new Fedora or OpenSUSE users, and the community in general if it spreads to other distros as they pick up 5.16.14 kernels.

[treee]

For the fun of it I also checked if it matters if you use the current Tech Preview version or the older one but alas it doesn't. In my case I see Fedora 35 hang on boot with kernel 5.16.14 whereas OpenSUSE Tumbleweed will simple return to the grub bootmenu. Using the previous kernel of 5.16.11 results in both systems booting.

The Fedora vm that is stuck on boot is also pulling (almost) full cpu usage (I set it to 4 cpu's so it is pulling 398% cpu usage). Not seeing that with the OpenSUSE vm.

For those looking for a way to get their upgraded systems to boot again: select the old kernel in the grub menu and once booted make it the default option. In OpenSUSE you can do that with "yast bootloader", in Fedora you can do that with grub-customizer (you'd have to install that; the packagename is as I have typed it).

[lalons]

Just did an install and after the update, same issue.

[k_ronny]

Hi,

so far it is not possible to use any linux kernel of version 5.17-rc1 and later.

In the log file there is an entry like this:

2022-03-11T16:22:10.119Z Wa(03) vcpu-0 Unsupported MRS(S3_0_C0_C6_2)​

and the cause of that is this addition to the linux kernel:

https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/arch/arm64/include/asm/cpu...

It looks like this patch has been ported back to their (Fedora, OpenSUSE, ...) kernel v5.16... series.

if I understood Michael Roy correctly, the VMware Fusion team is aware of the problem.

[k_ronny]

I have to correct myself, the change has actually been added to the official version 5.16.14.

[mkubecek]

---

and the cause of that is this addition to the linux kernel:

https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/arch/arm64/include/asm/cpu...

---

That's highly unlikely as the commit you linked is arm64 specific so that I don't see how it could affect x86_64 kernel.

[treee]

And we don't see what x86_64 has to do with that. This the subforum for the Tech Preview which only runs on arm64 and does NOT support x86_64 in any way whatsoever. Are  you sure you have got the right forum? 😁

[mkubecek]

---

@treee wrote:

This the subforum for the Tech Preview which only runs on arm64 and does NOT support x86_64 in any way whatsoever.

---

Not really... it does actually show in the "Workspace / Desktop Hypervisor" section which mostly deals with Workstation and Player.

---

@treee wrote:

Are  you sure you have got the right forum? 😁

---

Are you?

---

[treee]

Yes and it shows on the VMware Technology Network as well...along with the subforum the topic is posted in (it is right below the title of it and says "in Fusion for Apple Silicon Tech Preview Discussions").

FYI Apple Silicon is arm64 architecture. The issue that we are discussing in this very topic is on arm64 only which is why that commit to arm64 is given (and also why anything x86_64 is completely irrelevant and offtopic).

So yes, you are in the wrong subforum (but welcome anyway). For x86_64 you'd need to use VMware Fusion Discussions.

[Technogeezer]

@mkubecek nobody is saying that it impacts x86-64 kernels. The observed issue of failure to boot is with a 5.16.14 aarch64/arm64 Linux kernel running on the tech preview on Apple Silicon.
I wasn’t specific on this in the initial post as this sub forum is specifically targeted for the tech preview on Apple Silicon. I made an assumption based on posting here that people would know I was referring to arm64 kernels. I’ll make this more clear next time to avoid confusion. 

[mkubecek]

It's not my fault that VMware recently put multiple (formerly separated) sections into one. If you don't want to keep confusing people, it would be nice to always mention what product you are talking about... but that's up to you, of course.

[k_ronny]

It has also been added to kernel version 5.10.105, 5.15.28.

[Technogeezer]

@k_ronny Ouch. This is getting worse by the minute.

I hope that this is something that either VMware or the kernel maintainers can fix sooner rather than later as it's only a matter of time before these changes get picked up by distributions.

[k_ronny]

Now it is also in kernel 5.4.186.

[fabienmagagnosc]

@Technogeezer=> same for 5.16.15, so you can update your post subject accordingly

[fabienmagagnosc]

The title of this thread is "Fusion-for-Apple-Silicon-Tech", so it's pretty clear it's not Intel cpus (x86, amd64), but Apple cpus (arm, aarch64)

[k_ronny]

@Technogeezer Either Apple or VMware need to do something about this. Some information on this topic can be found here:

https://lists.nongnu.org/archive/html/qemu-devel/2022-02/msg01519.html 

or here:

https://lore.kernel.org/stable/907327093697278cd816aafec9e20b3e@kernel.org/T/ 

[fabienmagagnosc]

@k_ronny=> it seems, according to the threads, that the CPU register is there, but the Apple Virtualization Layer is having trouble to handle it.

it's important to understand that Parallel, VMware and Qemu are all relying on the Apple hypervisor (the API are accessible here https://developer.apple.com/documentation/hypervisor) and that this is clearly an issue in the hypervisor layer as when using native boot it works perfectly

Until Apple solve this, the kernel team is clearly not keen to disable this register (come back in time as a regression for example), and prefer to move forward and do more use of this register.

So, we need to push Apple, more than any others companies involved here.

Note : I put those references, as they are different (for now), especially the Capabilities detected during intel creation process, and highlight the fact that VMware may have to support quite a lot of versions (at least 2) for the hypervisor "engine" and still mange maybe compliance with "old macos OS version" (I suppose people bying a Mac Pro intel, with Monterey, expect it to still be supported in the next 3-4 years on the OS then provided.

Reference from Apple on M1 VM API usage

https://developer.apple.com/documentation/hypervisor/apple_silicon

Reference from Apple on Intel VM API usage

https://developer.apple.com/documentation/hypervisor/intel-based_mac

[k_ronny]

@fabienmagagnosc I agree with this, but I know that at least qemu (in an unreleased version) works well with all newer kernel versions.

[Technogeezer]

Has anyone heard from VMware on this? We're quickly on the way to having a non-functional Tech Preview release. I'm not holding my breath for a quick fix if this turns out to be something that Apple has to fix, and not VMware.