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.
]]>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.
]]>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).
]]>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
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.
]]>