I installed gnome 3.2 from the gnome overlay last week-end.
Then I upgraded to nvidia-drivers-285.05.09 today to solve an nvidia bug (Bug #375615).
But then gdm wouldn't start anymore, I looked at /var/log/gdm/:0-greeter.log and found this line multiple times:
> NVIDIA: could not open the device file /dev/nvidiactl (Permission denied).
/dev/nvidiactl is 660 root:video, so I added the "gdm" user to the "video" group.
Then gdm worked again.
I mentionned this problem and it looks like the ebuild in the sabayon overlay has a fix for that, adding the "gdm" user to both the "gdm" and the "video" groups.
Fixed in gdm-3.2.0-r1, thanks for reporting.
> commit fba0b3686a8ffa5207ca88b0b9f282c884f76c05
> Author: Alexandre Rostovtsev <firstname.lastname@example.org>
> Date: Tue Oct 4 14:38:36 2011 -0400
> gnome-base/gdm: ensure that gdm user is in video group (#385663)
> This is required for compatibility with new nvidia-drivers versions, and
> is good policy in general. If the gdm user is not in the video group,
> with nvidia-drivers-285.05.09 gdm will simply crash at startup with a
> generic fail whale dialog.
> Fixes bug #385663.
> XXX: check for portability.
I'm pretty sure gdm-3.0 would be affected as well. I think I'd prefer we keep this bug open until the necessary fixes trickle down to portage tree as well. Also considering the XXX FIXME comments in the fixes applied to overlay only.
Also, not at all sure this is the right approach to take to all this
(In reply to comment #2)
> I'm pretty sure gdm-3.0 would be affected as well.
No, only login managers that use opengl are affected. That means gdm-3.2.0 and higher.
> Also considering the XXX FIXME comments in the fixes applied to overlay only.
Ideally, someone who knows something about unix portability needs to write a function for eutils.eclass that modifies the set of groups a user belongs to. Then the gdm ebuild can be modified to use that function.
Adding a user to the video group can have security implications.
The fix has been in portage for a long time, and appears to have resolved the issue. Although, as comment #3 says, if someone can and wants to write a portable function for adding a user to a group and package it in an eclass, I would certainly love to switch gdm to use that.