Kernel 5.5.5 breaks Parallels Tools 15.1.2.47123

am investigating what code changes are needed...

 

While building prl_fs.ko in Stage 2:
ERROR: "call_tg_sync" [/usr/lib/parallels-tools/kmods/prl_fs/SharedFolders/Guest/Linux/prl_fs/prl_fs.ko] undefined!
<sigh>

 

For anyone looking to go back to 5.4.18-20, there's a repo that still has the headers:
http://mirrors.syringanetworks.net/...s/k/kernel-headers-5.4.18-200.fc31.x86_64.rpm

 

I can see nothing directly in code that would preclude building prltg_call. Guessing there must be an error in either one of the build scripts or the makefile.

 

Looking deeper through the installer logs it looks like
1. prl_eth.ko builds fine
2. prl_tg.ko builds fine
3. appears to copy the toolgate link symbols to prl_fs and prl_fs code appears to compile with no errors, BUT can't find the symbol define for call_tg_sync during prl_fs.ko build.

Weird.

 

I have exactly the same issue and this is driving me nuts.

I run Fedora 31 with the latest Linux kernel 5.5.7 and, as all of you, I'm getting "ERROR: "call_tg_sync" [/usr/lib/parallels-tools/kmods/prl_fs/SharedFolders/Guest/Linux/prl_fs/prl_fs.ko] undefined!".

As far as I know, I have been having such compilation issues since kernel 5.4.x. Linux kernel 5.3.x is fine though.

Any idea?

 

Hi AvinashM. Fedora 31 is not supported as a guest OS with Parallels Desktop 15 for Mac. Please refer this article to know the list of supported guest OS and the kernel version.

 

Thanks for the info. I was already aware of that.

But I would suggest that your engineers find a way to get Parallel Tools to compile because, well, one reason for using Linux is to have the latest security patches and it makes little sense to run a Linux kernel released on 21 October 2019 (5.3.7) when the latest available one was released on 28 Feb 2020 (5.5.7) in my case on Fedora Linux 31. One thing which is rather obvious also is that we, Linux users, would love to be able to help (as we are obviously geeks )

 

@AvinashM As of now, Fedora 31 is not supported as a guest OS with Parallels Desktop 15 for Mac and also supports Linux Kernel version 2.6.29-5.1. We will let you know if there is any updates.

 

5.4.20 should build fine with the last update of Parallels (15.1.2.47123). I had no install problems until 5.5.

 

I have fixed this issue, you can add

Code:

KBUILD_EXTRA_SYMBOLS := /usr/lib/parallels-tools/kmods/prl_tg/Toolgate/Guest/Linux/prl_tg/Module.symvers

to the Makefile of prl_fs and prl_vid kmods.

 

Cheers.
This makes a lot of sense, but it's so bizarre that it would be missing for 5.5 (or in the case of @AvinashM, 5.4)... unless there was a kernel-specific directive that ended at 5.4 (or 5.3) when building the Makefile. I even looked for things like that. Weird.

 

You can refer to this commit: https://github.com/torvalds/linux/commit/39808e451fdf30d20099a92e5185a0acb028d826

 

Parallels Tools 15.1.3 still has this problem, but the above KBUILD_EXTRA_SYMBOLS fix worked for me.

 

Geez... what a cluster.

 

FYI Fedora 30 will break as well. F31 worked perfectly up until the latest kernel.

Had massive drama with F31 (sorry, I tried updating the makefiles, but it didn't work for me but think that's my problem); so I did a fresh install of F30 from the Parallels menu. Everything was fine until you run a dnf update - the update for F30 is deploying a 5.5.x kernel along with your other standard updates.

So, if you're running F30 or F31, do not run an update.

@Devries if you could post a little more info (eg. file path locations within the directories - I got a bit lost with the linking inside the tar.gz file, and some basic instructions - should the line in both makefiles go at the top or bottom etc., this might help others to muddle through).

 

Seems like yo may have done a lot of unnecessary work, @DanielT16.

You can run an update, just add the following to /etc/dnf/dnf.conf:
exclude=kernel*
Which will skip all kernel updates in dnf.

And if you accidentally run into a problem with any kernel, the previous kernel is still installed, you only need to:
1. Retro the headers back to the appropriate version (see my similar post above for this case)
2. Boot back into the old 5.4 kernel and when it hangs, do the Ctrl-F2 (or is it Opt-F2, whatever) trick to get to non-graphic login screen.
3. Login to that, mount the virtual tools cd, and run the command line .install for Tools.
4. When that's done, reboot back into the old kernel again, but tell grub to set that as the default using grub2-set-default.

 

Thanks Mark - Much appreciated!

 

no problem

 

So, updated to kernel 5.5.8 in 15.1.3.47255 and the tools built automatically, although it did some funky things like a larger than normal cursor and other video-related abnormalities.

Made the changes to the two Makefiles for prl_fs and prl_vid per above and everything is copacetic again... Cheers, again @Devries!