Patch for Kernel 5.6

G

(GalaxyMaster)

Hunter
Today I updated my Arch Linux and got kernel 5.6.3. DKMS complained that it can't rebuild Parallel Tools, so I investigated.

In kernel 5.6 there was a major change to the procfs interface (https://patchwork.kernel.org/patch/11363867/).
Long story short, the attached file is a patch against Parallel Tools 15.1.2.47123 to make that version compile on kernels above 5.6. I tested it on 5.6.3 and it seems fine (I am currently writing this from a VM that runs 5.6.3). The patch is hacky - I wanted to introduce support as fast as I could since I have other things to do, but should be OK until Parallels release a proper update.
 

Attachments

It's a little different for 15.1.4.47270 (and likely for 15.1.3.47xxx), but the structures being modded are the same as 15.1.2.47123.
Not real hard to manually make the changes if you can read a diff file.

Thanks for the work @(GalaxyMaster).
 
Thank you @(GalaxyMaster)
Like a lot of people, I've upgraded to Parallels Desktop 15.1.4.47270 and I've attached the corresponding patch file if someone needs it (untar with "tar xvf prl_mod.tar.gz" and tar with "tar zcvf prl_mod.tar.gz . dkms.conf Makefile.kmods" before and after applying the patch).
I'm now running Parallel Tools on Fedora Linux 31 with the latest 5.6.6 Linux kernel. Thanks again.
 

Attachments

Hi again,

I've just upgraded to Linux kernel 5.6.7 on Fedora 31 and, after the DNF had completed (and the Parallels Tools modules compiled), I still needed to set up the symbolic links correctly:

cd 5.6.7-200.fc31.x86_64/weak-updates/
ln -s /lib/modules/5.6.7-200.fc31.x86_64/extra/prl_eth.ko.xz
ln -s /lib/modules/5.6.7-200.fc31.x86_64/extra/prl_fs_freeze.ko.xz
ln -s /lib/modules/5.6.7-200.fc31.x86_64/extra/prl_fs.ko.xz
ln -s /lib/modules/5.6.7-200.fc31.x86_64/extra/prl_tg.ko.xz
ln -s /lib/modules/5.6.7-200.fc31.x86_64/extra/prl_vid.ko.xz

After rebooting, everything is working fine.
 
In other words, the modules are being compiled correctly in extras but, for some reason, the correct symbolic links are not being created.

I have observed that, as a matter of fact, these symbolic links are being placed in the /lib/modules of the running kernel (5.6.6-200 in my case). It's probably a bug in the installer script.
 
Well, here's what's weirder... I had already done the changes for 5.6.6 and let 5.6.7 install using dnf - which reported an error due to to a mismatch with <linux/proc_fs.h>. After tracking everything down, turns out it was only a warning being treated as an error, and it built the new kernel's tools in extra anyway.
No weak-updates links were created for the new kernel either. Getting to the punchline: It still worked on a reboot, implying that weak-updates isn't really needed?
 
Even stranger... My process is to copy the tools image to a local directory with the modified kmods retarred and gzipped (without deleting the code). This way it can be easily modified on the fly. Then, if there's a problem with the dnf install process I can just run .install from the local version.

So I just did that and there were no warnings or errors. Everything updated just fine. It even created the weak-updates links for 5.6.7. So there must be a separate script for dnf that's broken...

All just in time for Fedora 32, which was released yesterday. Assuming the kernel build is ok, I'm going to guess that updating to 32 is good to go.
 
AvinashM said:
Yes.

I have upgraded to Fedora 32 (using dnf) and the modules compiled fine with the latest 5.6.10 kernel.
Click to expand...
I tried Fedora 32 (KDE) with kernel 5.6.6-300, it doesn't success. Could you share the prl_mod.tar.gz file in your github? Thank you.
 
AvinashM said:
Hi, here is my prl_mod.tar.gz which works well for me. (For some reason, I have had to change the extension from .tar.gz to .zip to be able to upload -- please change it back)
Click to expand...
This works for Fedora 32 KDE, but when reboot it stuck at black screen, you can CTL+ALT+F2 then login from the terminal, issue startx command to go to the normal KDE desktop. It needs this little more effort to go to the normal Desktop.
 
AvinashM said:
Thank you @(GalaxyMaster)
Like a lot of people, I've upgraded to Parallels Desktop 15.1.4.47270 and I've attached the corresponding patch file if someone needs it (untar with "tar xvf prl_mod.tar.gz" and tar with "tar zcvf prl_mod.tar.gz . dkms.conf Makefile.kmods" before and after applying the patch).
I'm now running Parallel Tools on Fedora Linux 31 with the latest 5.6.6 Linux kernel. Thanks again.
Click to expand...
With this Patch I got Kali Linux 2020.2 working again. PT installed without any issues after patching.
 
I'm also having issues with Kali Linux 2020. I'm fairly new to Linux, wonder if someone can explain the patches mentioned above - whether it's the user made one or how to patch from kernel.org.

Thanks!
 
Based on the last three posts in this thread, I really don't know a diplomatic way to say this effectively, so I'll just say it:

This procedure assumes the user already has a basic knowledge and prior experience of applying code patches from a simple diff file to the underlying source code on the virtual install CD. For example, the patches may not necessarily be something that can be applied automatically in every instance. In fact, I sometimes apply them manually, line by line, just in case they don't align properly, or the diff was created from a version that's different from the one I started with, just to be safe.

Bottom line warning: This is not a trivial thing to attempt. If your current Linux VM and installation of Parallels in general is something you don't want to mess up, I don't recommend cutting your teeth on something like this.
 
You must log in or register to reply here.
Back
Top