You are not logged in.
Host: Windows 7 Hypervisor: Virtualbox 4.2.30 Guest additions: virtualbox-guest-modules 4.2.28-4 as provided through the repository.
I have managed to get the hardware acceleration work in the past but after upgrading both virtualbox and the guest operating system it is now broken. I found the following thread, after perusing it I still cannot get it to work:
https://bbs.archlinux.org/viewtopic.php?id=180451
I cannot downgrade to mesa 10.1 because the package is nowhere to be found and I cannot get to install glxinfo either to see logs.
Does anyone have a solution?
There is a temporary solution in post #5; this issue turns out to be related to GDM that breaks the VirtualBox drivers from version 3.16 and upwards.
Last edited by g00ey (2015-07-23 10:04:02)
Offline
If you are using GDM as your desktop manager, GDM 3.16+ breaks hardware acceleration in virtualbox, which will force cinnamon into software rendering mode. If you're currently using GDM, try switching to LightDM on the virtualmachine as a diagnostic, and you should see working hardware accel.
Last edited by mwillems (2015-07-21 00:31:18)
Offline
LightDM doesn't work on my system when I try to switch to it.
Installation procedure:
-----
# pacman -S lightdm
# pacman -S lightdm-gtk-greeter
# vim /etc/lightdm/lightdm.conf
(changed '#greeter-session = Insert session here' to 'greeter-session = lightdm-gtk-greeter')
# vim /etc/lightdm/lightdm-gtk-greeter.conf
(changed '#background=' to 'background=/*path*/*filename*.png')
# systemctl enable lightdm.service
Failed to execute operation: File exists
-----
The installation doesn't switch to LightDM. A test run with xephyr yields the error:
...
DEBUG: Could not run plymouth --ping: Failed to execute child process "plymouth" (No such file or directory)
...
...
DEBUG: Stopping Light Display Manager
Last edited by g00ey (2015-07-21 12:59:54)
Offline
If LlightDM doesnt work, try any desktop manager other than GDM, or GDM prior to 3.16, or starting x manually for that matter. LightDM was just a suggested alternative that works well for most people. The point is that GDM 3.16+ reliably breaks hardware acceleration in virtualbox. Use any other solution that works for you if that's what is causing your issue.
Also in order to change display managers, you have to disable the existing one before enabling a new one. That's what the "file exists" error from systemctl is telling you (you didn't disable GDM before trying to enable LightDM).
Last edited by mwillems (2015-07-21 17:39:38)
Offline
Perhaps it was a good thing that I didn't try to install LightDM. I would probably get more problems than in the outset. I mean the Xephyr instance failed to run so one could take a guess as to what would happen if one rolled it out on the system. But I guess what you meant was that one should run 'libctl disable gdm' before running 'libctl enable lightdm', it doesn't make sense though. I mean, they are separate services after all, unless the enabling also means modifying a common/shared system file (modifying the 'run me as desktop manager at boot' line).
I found an older version of the gdm package in the cache so the command
# pacman -U /var/cache/pacman/pkg/gdm-3.12.2-1-x86_64.pkg.tar.xz
did it. It seems that also this package keeps themes in .gresource files. At first I didn't like it but it actually makes it easier to reapply customized login screens. Its easier to copy a whole package to the system than to have to keep track of which lines that were modified. I just have to put an estoppel on the updater so that pacman keeps its hands off of the gdm package from now on.
It also turns out that the 'opacify windows' extension isn't compatible with Cinnamon 2.6.13 so I guess that I have to remove it for now, unless someone has had success with modifying the version compatibility line in the manifest file of the extension. A reinstall with a confirmation to run it in spite of incompatibilty will make it run again. But it is still buggy; sometimes windows turn semi transparent even though they are active and not in resize mode.
Last edited by g00ey (2015-07-23 10:06:59)
Offline
Perhaps it was a good thing that I didn't try to install LightDM. I would probably get more problems than in the outset. I mean the Xephyr instance failed to run so one could take a guess as to what would happen if one rolled it out on the system. But I guess what you meant was that one should run 'libctl disable gdm' before running 'libctl enable lightdm', it doesn't make sense though. I mean, they are separate services after all, unless the enabling also means modifying a common/shared system file (modifying the 'run me as desktop manager at boot' line).
You can only have one display manager enabled at a time because only one can start at boot. systemd intelligently checks for this by symlinking display-manager.service to your enabled display manager. See: https://wiki.archlinux.org/index.php/Di … ay_manager. Attempting to enable a new display manager when one is already enabled will fail because the symlink at display-manager.service already exists, so systemd fails with "file already exists". Put another way, how would the system know what to do at boot if more than one DM were enabled? It's a feature not a bug.
So in order to enable a new display manager using systemctl, you must first disable your existing one.
Last edited by mwillems (2015-07-22 01:23:05)
Offline
Yes, this is very understandable. It's just that the error message from systemctl is very confusing; it's as if it complained that lightdm has already been enabled before and not that the default system symlink to said display manager is occupied by gdm. A more verbose error message showing the details would have been more helpful. But then again, it shouldn't fail in Xephyr...
Offline