Never update Parallels and a kernel on the same day...

M

Mark Fine

Pro
Updated Fedora 30 to kernel 5.3.5-200 this morning. Tools rebuilt all the usual stuff: drm, eth, fs, fs_freeze, and tg.

Then I saw Parallels 15.1.0 was ready, so I updated to that and rebuilt Tools again, which also seemed to go as normal...

Until you notice that there's no /usr/src/parallels-tools-15.1.0.47107 folder and a yellow triangle on the VM window (when you exit convergence mode) saying Tools needs to be reinstalled. And yet, there are ko.xz's (and ko's?) are in /usr/lib/modules/5.3.5-200.fc30.x86_64/extra/, but I have no idea which.

So, what's actually going on here? Is it updating or not?
 
Partially answering my own question, it never built and installed properly, although the gui installer thought it did. Running a manual install/upgrade failed.
First run through there are issues with prldrm.c on lines 1974 and 2065: Incompatible pointer types prl_drm_ss_vm_ops.fault and prl_drm_gem_vm_ops.fault.

more to come, I'm sure...
 
Can't go backwards because there's no header file available for 5.2.18-200.fc30.x86_64. Only for 5.0.9, so am now dead in the water until I can fix prl_vid to play nice.
 
The solution is that because it treats warnings as errors, declarations need to be specific. In this case, forcing an unsigned int into an int will cause a build-stopping Werror on lines 1974 and 2065. Instead of finding where Werrors were stipulated in the makefiles, I decided to just go the simple route:

I ended up changing "int" to "unsigned int" on lines 1922, 1925, 1981, and 1984 in prldrm.c (I may have only need to do one of the first two, and one of the second two, but got tired of experimenting). After saving/re-tarring/re-zipping the kmods then running install, it actually ran all the way through. Rebooted and we're off to the races.

Not sure if this will work for every case. Maybe I got lucky. But if anyone else runs into trouble at least it's documented here and it can be solved.
[I should subtitle this thread "A play in four acts"]
 
There's a script that's supposed to detect different kernel header versions and set PRL_DRM_VM_OPERATIONS_FAULT_X appropriately in order to make the preprocessor use the "unsigned int" code, but it's not working right on Fedora 30 with 5.2.x/5.3.x kernels. I haven't tried to install Parallels Tools 15.1 on any other kernel or Fedora version, so those might be broken too. I modified prl_vid/Video/Guest/Linux/kmod/test/test_drm_core.sh to always set PRL_DRM_VM_OPERATIONS_FAULT=0

I also noticed dkms doing a lot of extra work recompiling for kernel versions I don't have installed anymore. It helps to clean up old directories in /lib/modules and old symlinks in /var/lib/dkms/parallels-tools
 
Your are right, test_drm_core.sh doesn't work properly on Fedora30.
PRL_DRM_VM_OPERATIONS_FAULT_X must be 0 for kernels starting from v5.1
 
Heh... so I guess I went around it the hard way.
Correct on the old kernels. I do really need to clean that up. Eventually I remember to do it.
 
Mark Fine said:
The solution is that because it treats warnings as errors, declarations need to be specific. In this case, forcing an unsigned int into an int will cause a build-stopping Werror on lines 1974 and 2065. Instead of finding where Werrors were stipulated in the makefiles, I decided to just go the simple route:

I ended up changing "int" to "unsigned int" on lines 1922, 1925, 1981, and 1984 in prldrm.c (I may have only need to do one of the first two, and one of the second two, but got tired of experimenting). After saving/re-tarring/re-zipping the kmods then running install, it actually ran all the way through. Rebooted and we're off to the races.

Not sure if this will work for every case. Maybe I got lucky. But if anyone else runs into trouble at least it's documented here and it can be solved.
[I should subtitle this thread "A play in four acts"]
Click to expand...

Thanks! Worked perfectly on Ubuntu 19.10. Glad someone is fixing Parallels' software for them.... I was starting to regret forking out £39.99 for an upgrade...
 
Thanks. The fixed work for me too, for both Fedora 31 and Ubuntu 19.10 VMs.

(I am getting tired of having to copy, unpack, edit, and repack parallels tools scripts myself, though. These are major Linux distros with long, well-publicized release cycles and publicly-available betas. Paid users should not have to debug Parallels software for them.)
 
Official support response:
Hello Jediah,

Thank you for contacting Parallels Support. We would like to inform you that Fedora 30 has a star. Also, Linux Kernel version 2.6.29-5.1 only be supported. If the you have a different kernel version, it will not work. For future reference please refer the KB article https://kb.parallels.com/124223

Please reply to this email if you have any issues.

Thanks,
--
Sundhara Bharathi
Customer Support
||Parallels
Knowledge base: http://kb.parallels.com
Follow us on Twitter: @ParallelsCares

My response, which has gone unanswered: You're kidding, right? As a customer that is expected to pay a yearly licensing fee, this is the answer I get: "We don't ever intend to support new kernels"?
 
I meant.. what happened to the, "sorry paying customer, I recognize this is a problem. We are working to fix it, and we expect the fix to be available NLT (date). In the mean time, here are some details about verified workarounds"...

Perhaps that is too much to ask, for a company that sells me support? ;-)
 
Got a much more customer friendly answer today.. so there's that... :-) No ETA, but looks like they will (eventually) fix it for 15... Although I have no idea how they got the idea I'm using fedora.

We have escalated the issue about using the Fedora 30 with the latest built kernel version has been reported to the Engineering Team and they are working to address it in one of the future builds of Parallels Desktop for Mac.

To enable automatic updates, from the Parallels Desktop Menu, select Preferences > General > Download Updates Automatically.

While we do not have ETA for the fix, it has been prioritized appropriately and you can track the changes in the product at the corresponding knowledge base article page:

- Parallels Desktop 15 for Mac updates summary: https://kb.parallels.com/124724
- Parallels Desktop 14 for Mac updates summary: https://kb.parallels.com/124521
 
Absolutely unbelievable that we have to do this ourselves via a forum... Nice work to all involved. Parallels please get this fixed or hire these people.
 
JediahL said:
Works for Kali too, FYI. Would agree though, as a paying customer... it really bites that every upgrade brings new problems and required manual work-arounds. :|
Click to expand...
I've confirmed this worked great on Kali as well. Fantastic work to all involved.
 
Mark Fine said:
The solution is that because it treats warnings as errors, declarations need to be specific. In this case, forcing an unsigned int into an int will cause a build-stopping Werror on lines 1974 and 2065. Instead of finding where Werrors were stipulated in the makefiles, I decided to just go the simple route:

I ended up changing "int" to "unsigned int" on lines 1922, 1925, 1981, and 1984 in prldrm.c (I may have only need to do one of the first two, and one of the second two, but got tired of experimenting). After saving/re-tarring/re-zipping the kmods then running install, it actually ran all the way through. Rebooted and we're off to the races.

Not sure if this will work for every case. Maybe I got lucky. But if anyone else runs into trouble at least it's documented here and it can be solved.
[I should subtitle this thread "A play in four acts"]
Click to expand...
Does anyone have a link to a quick, "how-to" for unpacking and changing the files? I assume that I need to copy everything contained in the iso file to a temp location. I tried a quick find for prldm.c and could not find it, so I assume that it is packaged in a different file. Could somebody point me in the right direction?

A very frustrated Kali user here with a lot to do, and a VM that is rebooting every time I turn my back.
 
Hi Edward - I'm not at my mac right now; but IIRC you need to:

1. Mount the ISO and copy the contents to a temp location
2. In the kmods directory there was a tar.gz file that you need to unpack (tar -xvzf)
3. Navigate to the unpacked file prl_vid/Video/Guest/Linux/kmod/test/test_drm_core.sh and change the PRL_DRM_VM_OPERATIONS_FAULT assignment to "=0"
4. Repack the directory using the tar command (tar -czvf name-of-archive.tar.gz /path/to/directory-or-file) replacing the old file.
5. Run installer again.

You might need to uninstall the old version too.. I know there is a KB article around somewhere that talks about manual removal.

I'll be on a mac a little later this morning if this doesn't work, post again, and I'll check to see what above needs to be updated.
 
You must log in or register to reply here.
Back
Top