Path for kernel 5.9.1

As usual, Arch updated the kernel to the latest and Parallel Tools failed to re-build. Attached is the patch (tested on both 16.0.0.48916 and 16.0.1.48919).

 

I did this same change locally and it fixes compilation on arch linux using kernel v5.9.3. But I'm not able to copy files fro host shared directory. It fails, complaining about no memory available.
I downgraded to kernel v5.8 just as a test and compilation works + I'm able to copy files from host shared directory.
So there's still something else missing to fix v5.9+

 

It would help if you provided a session dump showcasing the issue. I am running the latest Arch kernel and Parallels Tools with the above patch - no issues so far.

Well, I also patched a bug in the shared folders module to preserve the persistence of nodes (I think the very latest Tools addressed that as well, but did not have time to validate). The bug, however, was not preventing accessing data, but "cp" and "mv" were complaining that the source file was changing during the copy.

 

Here are a few logs, using exactly the patch you sent here.

$ uname -a
Linux archlinux 5.9.4-arch1-1 #1 SMP PREEMPT Wed, 04 Nov 2020 21:41:09 +0000 x86_64 GNU/Linux

$ ltrace -i cp /mnt/psf/Home/.zshrc .
[0x5593f6d7b11f] __cxa_atexit(0x5593f6d83ce0, 0, 0x5593f6d97008, 0x736c6974756572) = 0
cp: error reading '/mnt/psf/Home/.zshrc': Cannot allocate memory


ltrace logs:
SYS_brk(0) = 0x560d36bae000
SYS_arch_prctl(0x3001, 0x7ffcfee62950, 0x7fe273829e80, 32) = -22
SYS_access("/etc/ld.so.preload", 04) = -2
SYS_openat(0xffffff9c, 0x7fe273833c02, 0x80000, 0) = 3
SYS_fstat(3, 0x7ffcfee61aa0) = 0
SYS_mmap(0, 0x20a2a, 1, 2) = 0x7fe2737ee000
SYS_close(3) = 0
SYS_openat(0xffffff9c, 0x7fe27383dd10, 0x80000, 0) = 3
SYS_read(3, "\177ELF\002\001\001", 832) = 832
SYS_fstat(3, 0x7ffcfee61af0) = 0
SYS_mmap(0, 8192, 3, 34) = 0x7fe2737ec000
SYS_mmap(0, 0xa0a0, 1, 2050) = 0x7fe2737e1000
SYS_mmap(0x7fe2737e3000, 0x5000, 5, 2066) = 0x7fe2737e3000
SYS_mmap(0x7fe2737e8000, 8192, 1, 2066) = 0x7fe2737e8000
SYS_mmap(0x7fe2737ea000, 8192, 3, 2066) = 0x7fe2737ea000
SYS_close(3) = 0
SYS_openat(0xffffff9c, 0x7fe2737ec4d0, 0x80000, 0) = 3
SYS_read(3, "\177ELF\002\001\001", 832) = 832
SYS_fstat(3, 0x7ffcfee61ad0) = 0
SYS_mmap(0, 0x6018, 1, 2050) = 0x7fe2737da000
SYS_mmap(0x7fe2737dc000, 8192, 5, 2066) = 0x7fe2737dc000
SYS_mmap(0x7fe2737de000, 4096, 1, 2066) = 0x7fe2737de000
SYS_mmap(0x7fe2737df000, 8192, 3, 2066) = 0x7fe2737df000
SYS_close(3) = 0
SYS_openat(0xffffff9c, 0x7fe2737ec9c0, 0x80000, 0) = 3
SYS_read(3, "\177ELF\002\001\001\003", 832) = 832
SYS_pread(3, 0x7ffcfee61810, 784, 64) = 784
SYS_pread(3, 0x7ffcfee617e0, 32, 848) = 32
SYS_pread(3, 0x7ffcfee61790, 68, 880) = 68
SYS_fstat(3, 0x7ffcfee61ab0) = 0
SYS_pread(3, 0x7ffcfee61700, 784, 64) = 784
SYS_mmap(0, 0x1c82a0, 1, 2050) = 0x7fe273611000
SYS_mmap(0x7fe273637000, 0x14d000, 5, 2066) = 0x7fe273637000
SYS_mmap(0x7fe273784000, 0x4c000, 1, 2066) = 0x7fe273784000
SYS_mmap(0x7fe2737d0000, 0x6000, 3, 2066) = 0x7fe2737d0000
SYS_mmap(0x7fe2737d6000, 0x32a0, 3, 50) = 0x7fe2737d6000
SYS_close(3) = 0
SYS_mmap(0, 0x3000, 3, 34) = 0x7fe27360e000
SYS_arch_prctl(4098, 0x7fe27360e740, 0xffff801d8c9f0eb0, 34) = 0
SYS_mprotect(0x7fe2737d0000, 12288, 1) = 0
SYS_mprotect(0x7fe2737df000, 4096, 1) = 0
SYS_mprotect(0x7fe2737ea000, 4096, 1) = 0
SYS_mprotect(0x560d35623000, 4096, 1) = 0
SYS_mprotect(0x7fe27383b000, 4096, 1) = 0
SYS_munmap(0x7fe2737ee000, 133674) = 0
SYS_brk(0) = 0x560d36bae000
SYS_brk(0x560d36bcf000) = 0x560d36bcf000
SYS_openat(0xffffff9c, 0x7fe2737a6a30, 0x80000, 0) = 3
SYS_fstat(3, 0x7fe2737d5600) = 0
SYS_mmap(0, 0x2e68b0, 1, 2) = 0x7fe273327000
SYS_close(3) = 0
__cxa_atexit(0x560d35610ce0, 0, 0x560d35624008, 0x736c6974756572) = 0
SYS_geteuid() = 1000
SYS_stat(".", 0x7ffcfee62700) = 0
SYS_newfstatat(0xffffff9c, 0x7ffcfee64bbb, 0x7ffcfee623f0, 0) = 0
SYS_newfstatat(0xffffff9c, 0x560d36bafce0, 0x7ffcfee62480, 0) = 0
SYS_openat(0xffffff9c, 0x7ffcfee64bbb, 0, 0) = 3
SYS_fstat(3, 0x7ffcfee62510) = 0
SYS_openat(0xffffff9c, 0x560d36bafce0, 513, 0) = 4
SYS_fstat(4, 0x7ffcfee625a0) = 0
SYS_fadvise64(3, 0, 0, 2) = 0
SYS_mmap(0, 0x22000, 3, 34) = 0x7fe273305000
SYS_read(3 <no return ...>
error: maximum array length seems negative
, "", 131072) = -12
SYS_openat(0xffffff9c, 0x7ffcfee61d30, 0x80000, 0) = 5
SYS_fstat(5, 0x7ffcfee61b60) = 0
SYS_read(5, "# Locale name alias data base.\n#"..., 4096) = 2998
SYS_read(5, "", 4096) = 0
SYS_close(5) = 0
SYS_openat(0xffffff9c, 0x560d36bafd00, 0, 0) = -2
SYS_openat(0xffffff9c, 0x560d36bb01d0, 0, 0) = -2
SYS_openat(0xffffff9c, 0x560d36bb0050, 0, 0) = -2
SYS_openat(0xffffff9c, 0x560d36bb0150, 0, 0) = -2
SYS_openat(0xffffff9c, 0x560d36bb0260, 0, 0) = -2
SYS_openat(0xffffff9c, 0x560d36bb00d0, 0, 0) = -2
SYS_write(2, "cp: ", 4cp: ) = 4
SYS_write(2, "error reading '/mnt/psf/Home/.zs"..., 36error reading '/mnt/psf/Home/.zshrc') = 36
SYS_openat(0xffffff9c, 0x560d36bb0430, 0, 0) = -2
SYS_openat(0xffffff9c, 0x560d36bb0640, 0, 0) = -2
SYS_openat(0xffffff9c, 0x560d36bb04c0, 0, 0) = -2
SYS_openat(0xffffff9c, 0x560d36bb05c0, 0, 0) = -2
SYS_openat(0xffffff9c, 0x560d36bb06d0, 0, 0) = -2
SYS_openat(0xffffff9c, 0x560d36bb0540, 0, 0) = -2
SYS_write(2, ": Cannot allocate memory", 24: Cannot allocate memory) = 24
SYS_write(2, "\n", 1
) = 1
SYS_close(4) = 0
SYS_close(3) = 0
SYS_munmap(0x7fe273305000, 139264) = 0
SYS_lseek(0, 0, 1) = -29
SYS_close(0) = 0
SYS_close(1) = 0
SYS_close(2) = 0
SYS_exit_group(1 <no return ...>
+++ exited (status 1) +++

 

Fedora 32 just went from 5.8.x directly to 5.9.8, which naturally broke Tools.
Made the two small changes and rebuilt... good as new.
Guessing this will hold for Fedora 33 as well when I finally jump to it.

Cheers, @(GalaxyMaster)

 

The changes posted here by @(GalaxyMaster) are working for me on Fedora 33. File copy tested in both directions over the shared folder.
Thanks!

 

I'm still on Fedora 32 and I can confirm that Parallel Tools, with the patch by (GalaxyMaster), works great.

 

...until you install 16.1.1, which didn't incorporate this. So now I'm having to do it a second time.

 

True. But we are now used to that, don't we?

 

Yeah, but as I've said in the past, it's getting really annoying that we're all paying for an expensive product that we do our own software maintenance on (and I'm sure they make use of). This was not always the case for Linux and there comes a point when you start to weigh return on investment.

 

I agree. They could easily have published the source code of Parallel Tools online in a git repo and start accepting pull requests. And, of course, release new versions of the Tools whenever someone (among us) patches something important. Anyone from Parallels reading this thread? Would this be possible?

 

I wouldn't expect them to do that from a business sense, mainly because it becomes a problem with version control (matching to the main application). It also opens it up to those not upgrading the latest main application, creating lost revenue.

That said, these could be easily solved by providing a login with certain versioning privileges for owners of specific versions - Something lashed to their online account or this forum perhaps?

 

The patch is working for me with Parallels 16.1 and Kali Linux 2020.4. Thank you!

For those like me who haven't patched Parallels Tools before, there are instructions in this thread https://forum.parallels.com/threads/patch-for-kernel-5-6.349625/

 

Hi,
great work thank you!
The Patch also works for Kali Linux 2020.4 with Kernel 5.9.0-kali2-amd64.
Linux kali 5.9.0-kali2-amd64 #1 SMP Debian 5.9.6-1kali1 (2020-11-11) x86_64 GNU/Linux

 

Did a dnf system-upgrade from F32 to F33 earlier today, then manually reinstalled Tools via install script with modified code.

In case anyone's noticed, the automatic re-install after the cleanup phase when a new kernel is installed never seems to do it quite right. You always end up with weird big cursors and poorly rendered graphics. That nonsense started around kernel 5. Manually running the install script after rebooting into the new kernel always seems to put it right. It's always handy to keep a directory mimicking the tools cd (but with the modified code) to do this part.

Either way, all is well at least until the next major kernel change.

 

I went through that thread but I didn't find any instructions. Could you be more specific as to what should be done with that diff file please? I have abso no experience therewith. QQ

 

Are you asking how to apply a patch because you've never applied one before, or you just don't know how to get to the code to apply it?
If it's the former, I don't recommend you even try. It's not a very straightforward procedure and you can ruin your entire installation.

 

Can you please share your patched prl_mod.tar.gz?

 

You do realize that in doing so it might violate Parallels' licensing... Providing a code patch to perform yourself is one thing. Providing essentially a majority of the code package that only includes two lines of modified code presents both an ethical and potential legal problem... Not to mention that you've made the request on the code owner's own support platform and they've provided no express permission to distribute it by a third party.

Hate to be a bummer, but as someone who used to be in this kind of business it is only right that I point out the problems created by such an action.

 

Sorry, did not know the consequences, I will try to patch myself.