This message is really aimed at the Parallels development team, but I could find no contact information to send an email directly. The instructions are useful to anyone setting up a Debian Wheezy virtual machine in Parallels Desktop (possibly other platforms as well). I have had quite a problem getting Debian Wheezy working with Parallels Tools. I recently figured out the cause of the problem and was hoping you could either patch Parallels Tools (specifically `/etc/init.d/prl-x11`) or at least distribute documentation regarding these steps to other customers. Debian Wheezy has switched to the insserv boot chainloader, and the format of the /etc/init.d files now requires additional comments for it to parse and maintain order. Without these comments it will fail to run all commands. This creates a problem for anyone installing new packages that have nothing to do with parallels. Additionally, the graphics acceleration is broken because the script does not get executed. Fortunately the fix for the prl-x11 script is quite easy. In your install pacakge the file located at ./installer/prl-x`11.sh, add these lines after your copyright: # Add LSB insserv Compatibility ### BEGIN INIT INFO # Provides: prl-x11 # Required-Start: $remote_fs # Required-Stop: $remote_fs # Default-Start: 2 3 4 5 # Default-Stop: 0 1 6 # Short-Description: x11 guest driver extension # Description: prl-x11 is a parallels service that configures X11 # for guest virtual machines. ### END INIT INFO The other factor is the Accelerated graphics. Even with the above patch applied prior to installing or upgrading off the local machine, the script is never started, and therefore the accelerated graphics are never loaded in. I have not looked into specifically where in the installer the script is called and why it fails (or if it is in fact called). For now post reboot I am manually running `sudo service prl-x11 start`, which seems to do the trick for future logins. I hope this information helps and that it will soon be patched.
PRL-X!! is fixed in PD 9, but still needs to be started manually This come a little late, but... The prl-x11 script has been fixed, but the developers did not finish the job. What I discovered is that the installation can be completed without a huge hassle by doing the manual step Casey outlined BEFORE REBOOTING. After the tools are installed, choose to exit instead of rebooting. At this point, I do two things (in a terminal window): sudo /etc/init.d/prl-x11 start<ENTER> Running the script actually creates the driver which /usr/lib/x86_64-gnu-linux/libGL.so.1 will point to (needed for 3D graphics). sudo nano /etc/X11/xorg.conf<ENTER>. The video screen is set to have a maximum resolution of 1024x768. I usually add 1920x1200 as I have a 24" monitor. sudo shutdown -r now This needs to be done every time the tools are installed or updated, but if you know it needs to be done, it's not too bad. I have submitted a bug report, but haven't found anyone who's interested in acknowledging that it's a problem that needs to be fixed. Bug # is 1771477. --skip
Yeah, they fixed it in the Parallels Desktop 9 release, but broke the 3D Drivers, so I can install Parallels Tools, but I get 2D Acceleration only. Perhaps unrelated, but the EFI option still doesn't work in linux either (no efivars). I finally switched to VirtualBox. It's free, it's drivers are not years out of date, installation is easy, and it has EFI support. Parallels never had good support, but it's sad to see them pretty much ignore the linux community and boast such great functionality only in windows.
I switched, too I switched to VMware. 3D support works, the driver is solid, and UEFI works, too. The 1st level support person tried to convince me it wasn't a bug, and after 2 hours on the phone said he would escalate it to the developers. Two weeks later, a developer responded that the same thing happened in Debian on real hardware, so it wasn't a Parallels issue. Why someone would install the tools on a real machine is beyond me. There is also a bug when the tools are removed: the 3D driver is removed, the 2D-only driver is replaced, but the symlink is left pointing to the removed driver. This leaves the machine unbootable in graphics mode. (In case someone reads this, and needs to fix it manually, the symlink /usr/x86_64-gnu-linux/libGL.so.1 needs to point to libGL.so.1.2.0 if I remember correctly.) Their response to this so far has been that the tools MUST be present for the machine to run! My response was that there shouldn't be an option to remove them if that was true. Yeah the 3D driver flakiness is worse, and the reason I switched, but the other two indicate they don't have very thorough regression tests. Still running my Windows in Parallels as I don't want to purchase additional licenses.
