FS#40056 - [gdm] fails to start after upgrade to 3.12.1-2
Attached to Project:
Arch Linux
Opened by smikims (smikims) - Wednesday, 23 April 2014, 16:39 GMT
Last edited by Jan de Groot (JGC) - Wednesday, 08 April 2015, 14:06 GMT
Opened by smikims (smikims) - Wednesday, 23 April 2014, 16:39 GMT
Last edited by Jan de Groot (JGC) - Wednesday, 08 April 2015, 14:06 GMT
|
Details
Description: I already reported this upstream and they told
me to report here as well; here is that report:
https://bugzilla.gnome.org/show_bug.cgi?id=728658
And here it is copy/pasted: This started happening yesterday, when Arch upgraded gdm from 3.12.1-1 to 3.12.1-2. Several services started taking way longer than normal to start (NetworkManager was over 90 seconds, gdm was about 30, etc.) and then I would fail to get to my login screen and would be forced to switch to a VT and reboot. This didn't happen every boot but would seemingly come in "spurts" where several boots in a row would fail and then several would succeed (well, it techically booted, I just couldn't reach gdm, but you get the point). There were some error messages in the journal I'll paste below that seemed to come from elsewhere, but the problem is seemingly with gdm since it was upgraded the boot before this started happening and downgrading it seemed to fix it. My whole dmesg output from a failed boot is at http://pastebin.com/0EESybyP, but the lines I think are relevant (or at least seemed abnormal) are 859-864, which read [ 36.633579] systemd[1]: Failed to register name: Connection timed out [ 36.646908] systemd[1]: Failed to set up API bus: Connection timed out [ 46.632649] systemd-logind[408]: Failed to enable subscription: Connection timed out [ 56.644949] systemd-logind[408]: Failed to fully start up daemon: Connection timed out [ 56.685097] systemd[1]: Unit systemd-logind.service entered failed state. [ 56.698424] systemd[1]: systemd-logind.service has no holdoff time, scheduling restart. Also, the gdm, avahi, systemd-journald, org.freedesktop.Accounts, and bluez systemd units all failed to start. The only Google results I got for the dmesg errors were from dbus.c in systemd, but unless gdm somehow exposed an earlier bug in systemd, I don't see how that could be the root cause since that wasn't upgraded before this started happening. Sorry for waiting so long to report after going over there first; this is my first time actually using these bugtrackers. Additional info: * package version(s) * config and/or log files etc. Steps to reproduce: Nothing specifically that I'm doing (that I can tell); using networkmanager 0.9.8.9-1, gdm 3.12.1-2, 0.6.31-11, systemd 212-3; the first three of those all have their systemd units enabled and are the main ones that started taking way too long to start. |
This task depends upon
Closed by Jan de Groot (JGC)
Wednesday, 08 April 2015, 14:06 GMT
Reason for closing: Works for me
Additional comments about closing: Old bug, no response for a long time. Not a gdm bug, probably a broken dbus version/installation.
Wednesday, 08 April 2015, 14:06 GMT
Reason for closing: Works for me
Additional comments about closing: Old bug, no response for a long time. Not a gdm bug, probably a broken dbus version/installation.
Just found out that systemd keeps core dumps in the journal--here's one from
the most recent time gdm crashed (too big for an attachment):
http://b.armory.com/~smikims/gdm.dump. I've got about a dozen more like it if
you want to see another.