Patch for Kernel 5.6

This is really something Parallels should be doing. The fact that they won't (notice I don't say can't) gunzip a file, run a patch against it, gzip it back up, and test it to verify that it works, speaks volumes about their business. They could have released an update with this months ago and saved their users so much needless anguish and toil.

 

You're right, but there's no way we can say they're not doing that. I'm pretty sure what's being done by us users in this forum is getting incorporated, if not at least tested as a potential solution in their scheduled product build. I have seen fixes appear verbatim in code that was formally released later.

The problem is that they just don't release anything like that 4-6 months before the next scheduled major release date. I can understand that from purely a business decision, even though I don't like it as a subscriber and a long-time registered user (since version 3!).

Technically, this makes the platform always one version behind for quite a number of months and unusable for quite a number of people (also as evidenced in this thread). So the business decision is a rather short-sighted one as people look for alternatives.

It's also quite annoying having to pay $50/year for a subscription, the code of which I and others have helped to maintain, but... whatever. We do this for varying reasons.

I have mentioned before that if we're going to change the company's behavior and have them pay more attention to what's needed on the Linux front, maybe we should stop making it easy for them to continue theirs by changing ours first.

 

Good points, and I agree for the most part. The frustrating part for me is their business model seems to have a dual personality. They charge a subscription, so you would expect a SaaS, CICD experience. But they release their software upgrades and updates on a traditional cycle. And it's not like we're demanding new features or innovation more often (even though that could be expected on the SasS model). We're just expecting that small changes to the linux kernel would get simple patches to their tools so the darn VM will start and function.

It's a good product, and I like how the Linux VMs run so well without the tools. If copy-and-paste between guest & host weren't an absolute requirement for me, I'd probably just run it without tools and be a happy, satisfied user.

 

Worked great on Debian with Kernel 5.7.0.

 

Fedora 32 kernel is now up to 5.8.4. Still working...

 

Hi Mark, are you sure? I'm also running Fedora 32 and I am having issues with the latest 5.8 kernels.

The first issue I had was this error message "'struct mm_struct' has no member named 'mmap_sem'; did you mean 'mmap_base'?" As a matter of fact, in Kernel 5.8.x, mmap_sem has been renamed to mmap_lock and I had to change prltg_call.c in prl_fs. This was easy.

Now, I am having another issue which, for the time being, I have not been able to solve. When trying to compile prl_eth, I get:

ERROR: Kernel configuration is invalid.
include/generated/autoconf.h or include/config/auto.conf are missing.
Run 'make oldconfig && make prepare' on kernel src to fix it.

And I don't know what is wrong. Any tips?

 

I'm absolutely sure. Might also help to update to PD 16.0.1, which is what I'm running now without any tools modifications. I'm also currently running kernel 5.8.7 as it seems as if kernel updates are being released almost twice a week now.

If you're having autoconf issues it almost seems like you've modified the kernel but not fully (re).configured them prior to building. I've never run into that on a straight kernel update via dnf.

 

I'm still on Parallels Desktop 15. I'll wrestle a bit more to get Parallels Tools working with kernel 5.8 and, if I can't, I'll upgrade

 

Or you could install VMware Fusion 12; now free with registration.

 

I think it is a bit unfair to promote Fusion here. I don't like Parallels level of support for their product, nor the pricing model, nor the limitations they put on CPUs/memory. But I migrated from Fusion 12 Pro since I was tired of fighting with their support over unexpected crashes of my VMs when my laptop was returning from suspend (with VMware it was always a gamble whether my VM would crash or not). I did not choose Parallels for its name, but I was searching for any product that would support Apple's native hypervisor (yes, Apple has all the components supplied except for GUI) and Parallels Desktop was the only commercial offer on the market.

 

Fair enough. I appreciate your tact in your well thought out response. The reality is that I will continue to use Parallels along side its competitors. I don't have the skill to patch the kernel but a huge desire to continue to test various Linux distros. When I get one I like and a kernel update breaks it (again I don't have the skill to dig and fix these kinds of issues), rather than wait, I try it on one of the others virtualization platforms. I have success on Fusion with Linux but with Windows 10, not so much.

 

I don't think anyone is coming here to promote any competitor products. I think Parallels themselves are promoting their competitors by providing such poor support for the Linux kernel. Most people aren't looking for the "best" product. They just want something that works. And the fact is, if you stay up to date on security and kernel updates, then much of the time, this product here does not work. So then you are left with a choice between security and "it works". In a sane world, this should be a false choice, but with Parallels it's not. If you stay up to date, and you have a problem, they say you're "not supported" and don't lift a finger to help.

 

Unfortunately, Parallels Desktop could not be relied upon for Information Security. Their `prl_disp_service` is an overbloated binary that does lots of stuff under root. I tried to confine it (by removing the signature and running it under "fakeroot", but there are a few privileged calls I need to create a wrapper for and I don't have enough time to do so. I wish whoever architects their dispatcher just reads a bit on "privilege separation" and "the least privilege principle" - the highly privileged part should be minimal and the rest of processing should be performed under a non-privileged account.

 

Is there anything for linux-headers-5.9.0-kali1-amd64?

 

Hello community,
Im searching for a solution in 5.10.0-kali4-amd64.
Is there a solution for that?
Thanks for you help

 

@cheesi, I post a patch for every major kernel update Parallels is slow to provide updates tools for. There is a thread on 5.9 patch which should be applicable up to (but not including) 5.11.

 

Thanks Galaxy Master. I'm really new to all of that I'm trying your steps today. Hopefully I can manage it. Thanks for your help!