Bug#770130: Bug#775235: gnome-shell not starting with gdm3/mesa/llvm-3.4 but does start from startx & lightdm regardless
On Sun, 15 Mar 2015 at 19:48:07 +0000, Philip Hands wrote:
> I only posted to the bug because I saw no mention of the fact that one
> can get things working by avoiding gdm3 in any of these bugs, which
> seemed like it might be relevant. The fact that llvm-3.4 didn't help me
> is just an extra detail really.
Anything that crashes GNOME Shell (via an assertion failure or any
other reason) has the same superficial symptom: the "fail whale"
(oops, something has gone wrong) from gnome-session.
As a result, #775235, #770130/#776911, and #780413 all have the same
superficial symptom, but I suspect their root causes differ (particularly
#775235 and the others), and they can only be distinguished easily
by log messages in syslog / the systemd Journal.
Reasons I think this is the same thing as #770130/#776911 and perhaps #780413:
* all involve approximately decade-old Intel graphics (Eric on #770130: 830M;
Rafal on #776911: 852GM/855GM; Philip: 855GM; me on #780413: 865G)
* Eric, Rafal and Philip all report "*ERROR* pipe A underrun"
whereas I get a different symptom for #780413 ("GPU HANG"),
which is why I haven't merged #780413 with the others
> Hints about where gdm3 might be logging what happened would be useful.
You seem to be running systemd as pid 1, so the catch-all answer is
"in the journal" (available via either journalctl or the traditional
syslog interface).
Could you please look in the journal and see whether you are getting
an assertion failure something like this?
May 17 01:20:15 debian gnome-session[952]: (gnome-shell:1092):
Cogl-ERROR **: Failed to create texture 2d due to size/format
constraints
(systemd blames it on gnome-session because it comes out of gnome-session's
stderr, which is inherited by gnome-shell - but the message is really
from gnome-shell)
My prediction is that you will. You'd typically see several iterations
of that, before gnome-session gives up hope of successfully starting
gnome-shell and displays the fail-whale instead.
> However, I note that even with the standard packages it was possible to
> get Gnome running via startx from the text console. I also note that
> installing lightdm and running from there solves the problem
That's interesting. I could only reproduce something similar on #780413
by starting the "real login" version of GNOME Shell; I only tried going
via gdm, but gdm's login screen *is* (a special configuration of)
GNOME Shell (in particular, it is the same from a graphics/compositing/3D
point of view AIUI); so if GNOME Shell is going to crash like this, it's
rather surprising that gdm's login screen does not already do the same before
we could even log in.
I'll try with startx or lightdm on my 865M hardware at some point.
It's possible that the way to reproduce this bug is something like "run
an accelerated compositing environment (GNOME Shell) on one VT, and then
try to run *another* accelerated compositing environment on another VT"?
If that was the case, then something like gdm -> xfce would work because
gdm's Shell was the first composited environment running and xfce isn't
composited; and lightdm -> GNOME Shell would also work because GNOME Shell
was the first composited environment running; but gdm -> GNOME Shell
would not.
Suggesting lightdm provides a workaround for this older hardware,
if nothing else.
> If you're pointing at the other bugs because you think they might
> contain a fix for my problem, well the simplest fix for me is to avoid
> gdm3.
We're pointing at the unsolved bugs because they sound more like what you're
experiencing than the solved #775235 does, and we hope that your additional
information might give someone enough clues to solve them.
>From a purely practical point of view, if your hardware is this old,
you might well be better off with lightdm or another non-compositing *DM
instead of gdm, and/or GNOME Flashback or a non-GNOME environment instead
of GNOME Shell. On the i865M where I could reproduce #780413,
I was previously using wheezy's GNOME fallback environment (for
which GNOME Flashback is the closest equivalent in jessie), until I
retired it in favour of a second-hand Thinkpad running wheezy's
GNOME Shell.
Perhaps the jessie release notes should recommend GNOME Flashback
as the upgrade path for GNOME on hardware older than some arbitrary cutoff?
Anything with x86-64, and even the more recent 32-bit chipsets (e.g. whatever
is in the Thinkpad X60s), should be fine for GNOME; but older than that is,
realistically, not going to be tested by most developers any more.
S
Reply to: