I have a laptop with a very fast SSD - on this machine sometimes (I'd say 1 out of 5 boot attempts) it happens that the system starts up using the LLVM driver instead of the Intel driver. I asked Ray if he had any idea how this could happen, and he has a possible explaination: - logind is the component being responsible to set the right ACLs on the drm device, by reading the uaccess tag, and it seems to check for it at startup and on VT change - it might happen that logind is pulled in very early in the boot process, possibly before the drm device has been tagged at all - under these circumstances, the ACLs won't be set (as there's no tag yet) and as there's no VT switch, the drm device won't have the right permissions once X starts, causing the fallback to LLVM - this also seems to be consistent with the fact that it doesn't happen at every boot, as the timings between different runs might differ I have only seen the bug on my laptop with an SSD. Other machines I have with rotating drives have never been affected.
<poettering> halfline: hmm <poettering> halfline: i think this can be solved by making gdm watch CanGraphical <poettering> halfline: i.e. so that gdm doesn't take possession of the seat before it has been declared graphical <poettering> halfline: other than that logind guarantees that the ACLs are gdm's if the PAM hooks are complete <poettering> halfline: is it possible that gdm invokes them in the bg or so? <halfline> poettering: ah okay <halfline> poettering: you're saying if we wait until CanGraphical before starting gdm's pam_systemd then the drm device will be guaranteed to be around <halfline> so when the ACLs get assigned, /dev/dri/card0 will be one of the devices that gets affected <halfline> makes sense Closing NOTOURBUG. See https://bugzilla.gnome.org/show_bug.cgi?id=678535 for the GDM bug report.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.