10:27 a.m.
Is it GDM or systemd that is causing gdm to fail? Or, X? I can boot
with single on kernel cmd line, start NM and then exit the emergency
shell and GDM then comes up?
Anyone else seeing this? What component to bz?
--
Regards,
OldFart
10:45 a.m.
On Sun, Feb 12, 2012 at 11:27 AM, Clyde E. Kunkel
<clydekunkel7734(a)verizon.net> wrote:
Is it GDM or systemd that is causing gdm to fail? Or, X? I can boot
with
single on kernel cmd line, start NM and then exit the emergency shell and
GDM then comes up?
Anyone else seeing this? What component to bz?
Dan Walsh diagnosed this as a bug in systemd where it isn't
transitioning to the init_t
context. I think if you downgrade to systemd before systemd-40 it goes away.
josh
10:50 a.m.
On 02/12/2012 11:45 AM, Josh Boyer wrote:
<snip>
Dan Walsh diagnosed this as a bug in systemd where it isn't
transitioning to the init_t
context. I think if you downgrade to systemd before systemd-40 it goes away.
josh
I'll try, but I have selinux disabled. Thx for the quick response.
--
Regards,
OldFart
1:04 p.m.
On 02/12/2012 11:50 AM, Clyde E. Kunkel wrote:
On 02/12/2012 11:45 AM, Josh Boyer wrote:
> <snip>
>
> Dan Walsh diagnosed this as a bug in systemd where it isn't
> transitioning to the init_t
> context. I think if you downgrade to systemd before systemd-40 it goes
> away.
>
> josh
I'll try, but I have selinux disabled. Thx for the quick response.
No joy. Downgraded both systemd and gdm and downgraded even more, but
gdm continues to fail. Can get to gnome 3 desktop via single boot
bypassing gdm, tho.
Stumped.
--
Regards,
OldFart
1:09 p.m.
On 02/12/2012 02:04 PM, Clyde E. Kunkel wrote:
On 02/12/2012 11:50 AM, Clyde E. Kunkel wrote:
<snip>
No joy. Downgraded both systemd and gdm and downgraded even more,
but
gdm continues to fail. Can get to gnome 3 desktop via single boot
bypassing gdm, tho.
Stumped.
Duh!!....did NOT bypass gdm. Bypassed systemd starting gdm. So, looks
like problem is connected with systemd or some process controled by systemd.
--
Regards,
OldFart
1:51 p.m.
On Sun, Feb 12, 2012 at 8:09 PM, Clyde E. Kunkel
<clydekunkel7734(a)verizon.net> wrote:
On 02/12/2012 02:04 PM, Clyde E. Kunkel wrote:
>
> On 02/12/2012 11:50 AM, Clyde E. Kunkel wrote:
<snip>
> No joy. Downgraded both systemd and gdm and downgraded even more, but
> gdm continues to fail. Can get to gnome 3 desktop via single boot
> bypassing gdm, tho.
>
> Stumped.
Duh!!....did NOT bypass gdm. Bypassed systemd starting gdm. So, looks like
problem is connected with systemd or some process controled by systemd.
You are probably being hit by
https://bugzilla.redhat.com/show_bug.cgi?id=789731
4:19 p.m.
On 02/12/2012 02:51 PM, drago01 wrote:
<snip>
You are probably being hit by
https://bugzilla.redhat.com/show_bug.cgi?id=789731
Yes, thank you. All is well now.
--
Regards,
OldFart
4:32 p.m.
New subject: Getting harder and harder to debug startup probs (was: GDM failing in current rawhide)
Is it just me, or is it getting harder and harder to debug Fedora
startup problems?
We'll see if an old dog can learn new tricks...
--
Regards,
OldFart
2:54 a.m.
New subject: Getting harder and harder to debug startup probs
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 12/02/12 23:32, Clyde E. Kunkel wrote:
Is it just me, or is it getting harder and harder to debug Fedora
startup problems?
We'll see if an old dog can learn new tricks...
More general:
If you're hit by some bug, you get lost; nowadays sooner than later. I
can't count, how many times I had some error getting X up (or even
system up) since the move to systemd.
Next sad thing is, it isn't reproducible every time. Since we're
testing moving targets, it's pretty unclear, how to reproduce the
situtation _now_ on _my_ special system? Since I can't login, I can't
get a package list.
- --
Matthias Runge <mrunge(a)matthias-runge.de>
<mrunge(a)fedoraproject.org>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iQEcBAEBAgAGBQJPOM+tAAoJEOnz8qQwcaIWIowH/3vQIPTOAHFFJ4OSnk9j+bKG
E7jzomzCJcTemSSveWhdIGmxnxN+KBjEBNlsICV1t29oD/1ueFCwh5RPCJzjsS48
h1QKOz8/xrVGN1IHnPTkMTV3HEVz0amZH9FiaZnpksg0GsKkidrJ5u4oiD2ypf0/
ajQMWYFQLUougZEYrJlLCb14yfWe60UybgwjpWl9XFIVzm1+XKPqSVTxtApKTzqr
5viQ0rIyD8pmZlEernNtGw2db2cF7X74AtVl2tdb9EMRkra6mrruSSu+3KbVTBiJ
PRB+rTUZDJvQOk3TsN5bHxhJFkAdNA7P0uTb5YvnThrw2sV8hbKdf1dcrCpnmrc=
=ezdf
-----END PGP SIGNATURE-----
4:59 a.m.
New subject: Getting harder and harder to debug startup probs
On Mon, 13 Feb 2012, Matthias Runge wrote:
More general:
If you're hit by some bug, you get lost; nowadays sooner than later. I
can't count, how many times I had some error getting X up (or even
system up) since the move to systemd.
Next sad thing is, it isn't reproducible every time. Since we're
testing moving targets, it's pretty unclear, how to reproduce the
situtation _now_ on _my_ special system? Since I can't login, I can't
get a package list.
It isn't just systemd. I don't think gnome-shell helps either, because you
tend to get an unhelpful "blue screen of death" type message if something
goes wrong making it difficult to work out what the problem is. Previously
the system continued as best it could, meaning you might see what the
problem was in what did and didn't appear on the desktop, and might get
enough functionality on the desktop to debug the problem more easily.
Michael Young
8:30 p.m.
New subject: Getting harder and harder to debug startup probs
On Mon, 2012-02-13 at 10:59 +0000, M A Young wrote:
On Mon, 13 Feb 2012, Matthias Runge wrote:
> More general:
>
> If you're hit by some bug, you get lost; nowadays sooner than later. I
> can't count, how many times I had some error getting X up (or even
> system up) since the move to systemd.
>
> Next sad thing is, it isn't reproducible every time. Since we're
> testing moving targets, it's pretty unclear, how to reproduce the
> situtation _now_ on _my_ special system? Since I can't login, I can't
> get a package list.
It isn't just systemd. I don't think gnome-shell helps either, because you
tend to get an unhelpful "blue screen of death" type message if something
goes wrong making it difficult to work out what the problem is. Previously
the system continued as best it could, meaning you might see what the
problem was in what did and didn't appear on the desktop, and might get
enough functionality on the desktop to debug the problem more easily.
I'd say the answer to the question is 'no, it's just different'.
systemd actually makes it *easier* to debug startup issues, really,
because it has good and sophisticated tools for investigating the status
of all services and the dependencies between them. But it's _different_
from sysv/upstart, and you have to learn how to use the tools and logs.
Once you do that, it's actually much better. You can see from the bug
report how Kay diagnosed this particular dbus/dracut issue: you can do
that too. Also learn how to use systemctl - the man page is great.
For Shell, whatever causes the fail whale will almost invariably be
pointed up by ~/.xsession-errors; you just have to read it carefully.
The fail whale comes up if any one of a certain set of core GNOME
components spawns (runs) more than twice within a 60 second period -
this is intended to catch crash/respawn loops. So you're looking for a
component - usually shell itself, or gdm, or gnome-settings-daemon -
crashing more than once.
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora
http://www.happyassassin.net
8:38 p.m.
New subject: Getting harder and harder to debug startup probs
On Mon, 2012-02-13 at 18:30 -0800, Adam Williamson wrote:
On Mon, 2012-02-13 at 10:59 +0000, M A Young wrote:
> On Mon, 13 Feb 2012, Matthias Runge wrote:
>
> > More general:
> >
> > If you're hit by some bug, you get lost; nowadays sooner than later. I
> > can't count, how many times I had some error getting X up (or even
> > system up) since the move to systemd.
> >
> > Next sad thing is, it isn't reproducible every time. Since we're
> > testing moving targets, it's pretty unclear, how to reproduce the
> > situtation _now_ on _my_ special system? Since I can't login, I can't
> > get a package list.
>
> It isn't just systemd. I don't think gnome-shell helps either, because you
> tend to get an unhelpful "blue screen of death" type message if something
> goes wrong making it difficult to work out what the problem is. Previously
> the system continued as best it could, meaning you might see what the
> problem was in what did and didn't appear on the desktop, and might get
> enough functionality on the desktop to debug the problem more easily.
I'd say the answer to the question is 'no, it's just different'.
systemd actually makes it *easier* to debug startup issues, really,
because it has good and sophisticated tools for investigating the status
of all services and the dependencies between them. But it's _different_
from sysv/upstart, and you have to learn how to use the tools and logs.
Once you do that, it's actually much better. You can see from the bug
report how Kay diagnosed this particular dbus/dracut issue: you can do
that too. Also learn how to use systemctl - the man page is great.
For Shell, whatever causes the fail whale will almost invariably be
pointed up by ~/.xsession-errors; you just have to read it carefully.
The fail whale comes up if any one of a certain set of core GNOME
components spawns (runs) more than twice within a 60 second period -
this is intended to catch crash/respawn loops. So you're looking for a
component - usually shell itself, or gdm, or gnome-settings-daemon -
crashing more than once.
Oh, extending that: how I usually confirm and get more info on 'fail
whale' scenarios is to leave the broken GNOME session running and switch
to a VT, log in as myself, and look at .xsession-errors. When I think
I've spotted what process is failing, I do this:
DISPLAY=:0 (command)
So if it's gnome-settings-daemon that's failing, I do:
DISPLAY=:0 /usr/libexec/gnome-settings-daemon
that tries to run the process in question *in the X session*, not in the
terminal you're actually typing the command from. That way you can
confirm that it really is that process that's failing, and get any error
output it spits out to the console but doesn't put in logs.
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora
http://www.happyassassin.net
4454
days inactive
4456
days old
11 comments
6 participants
participants (6)
-
Adam Williamson -
Clyde E. Kunkel -
drago01 -
Josh Boyer -
M A Young -
Matthias Runge