We upgraded a test system to Fedora 20 using the fedup process. There were 60 packages that were left from Fedora 19 after the upgrade that were subsequently fixed by doing a yum distro-sync. Since the upgrade we are not able to login into a Gnome session. We select the user in the greater and it prompts for the pass word. After that it goes to the grayed background and hangs leaving the user session in a hung state where you have cursor control but the session setup does not get to the point where you can select anything.
We have checked the logs and see nothing in the logs that indicate an issue. The other change noticed is the monitor never goes to sleep when the greater screen is active.
On 21.12.2013 20:40, David Highley wrote:
We upgraded a test system to Fedora 20 using the fedup process. There were 60 packages that were left from Fedora 19 after the upgrade that were subsequently fixed by doing a yum distro-sync. Since the upgrade we are not able to login into a Gnome session. We select the user in the greater and it prompts for the pass word. After that it goes to the grayed background and hangs leaving the user session in a hung state where you have cursor control but the session setup does not get to the point where you can select anything.
We have checked the logs and see nothing in the logs that indicate an issue. The other change noticed is the monitor never goes to sleep when the greater screen is active.
Does systemctl restart gdm.service from text shell help you restore system responsiveness? It might be some problem with gnome-shell or Xorg, I'm facing similar behavior from time to time on fresh installation.
Mateusz Marzantowicz
"Mateusz Marzantowicz wrote:"
On 21.12.2013 20:40, David Highley wrote:
We upgraded a test system to Fedora 20 using the fedup process. There were 60 packages that were left from Fedora 19 after the upgrade that were subsequently fixed by doing a yum distro-sync. Since the upgrade we are not able to login into a Gnome session. We select the user in the greater and it prompts for the pass word. After that it goes to the grayed background and hangs leaving the user session in a hung state where you have cursor control but the session setup does not get to the point where you can select anything.
We have checked the logs and see nothing in the logs that indicate an issue. The other change noticed is the monitor never goes to sleep when the greater screen is active.
Does systemctl restart gdm.service from text shell help you restore system responsiveness? It might be some problem with gnome-shell or Xorg, I'm facing similar behavior from time to time on fresh installation.
Same recovery as doing init 3 init 5 you get back to the Gnome greater screen with the session ended. We have looked at the Xorg log files and see nothing wrong in them. Our case is not intermittent. We have tried both VGA and HDMI connections and get the same results. We have also reviewed dmesg and the /var/log/message log files. Nothing seems to get logged. We have checked for selinux avc issues and tried login in selinux Permissive mode. Second check just now indicates that a systemctl restart gdm.service gets us back to the Gnome greater screen but then we were not able to select a user for login.
Mateusz Marzantowicz
users mailing list users@lists.fedoraproject.org To unsubscribe or change subscription options: https://admin.fedoraproject.org/mailman/listinfo/users Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines Have a question? Ask away: http://ask.fedoraproject.org
On 21.12.2013 22:50, David Highley wrote:
"Mateusz Marzantowicz wrote:"
On 21.12.2013 20:40, David Highley wrote:
We upgraded a test system to Fedora 20 using the fedup process. There were 60 packages that were left from Fedora 19 after the upgrade that were subsequently fixed by doing a yum distro-sync. Since the upgrade we are not able to login into a Gnome session. We select the user in the greater and it prompts for the pass word. After that it goes to the grayed background and hangs leaving the user session in a hung state where you have cursor control but the session setup does not get to the point where you can select anything.
We have checked the logs and see nothing in the logs that indicate an issue. The other change noticed is the monitor never goes to sleep when the greater screen is active.
Does systemctl restart gdm.service from text shell help you restore system responsiveness? It might be some problem with gnome-shell or Xorg, I'm facing similar behavior from time to time on fresh installation.
Same recovery as doing init 3 init 5 you get back to the Gnome greater screen with the session ended. We have looked at the Xorg log files and see nothing wrong in them. Our case is not intermittent. We have tried both VGA and HDMI connections and get the same results. We have also reviewed dmesg and the /var/log/message log files. Nothing seems to get logged. We have checked for selinux avc issues and tried login in selinux Permissive mode. Second check just now indicates that a systemctl restart gdm.service gets us back to the Gnome greater screen but then we were not able to select a user for login.
Don't bother searching in logs. It's very likely that you won't find anything there because failing piece of code is part of gnome-shell and is written in Java Script. I don't see any references to logging facilities in that code. If you have enough time and spare resources you can take a look at https://git.gnome.org/browse/gnome-shell/ . This issue might be hard to resolve.
Mateusz Marzantowicz
"David Highley wrote:"
"Mateusz Marzantowicz wrote:"
On 21.12.2013 20:40, David Highley wrote:
We upgraded a test system to Fedora 20 using the fedup process. There were 60 packages that were left from Fedora 19 after the upgrade that were subsequently fixed by doing a yum distro-sync. Since the upgrade we are not able to login into a Gnome session. We select the user in the greater and it prompts for the pass word. After that it goes to the grayed background and hangs leaving the user session in a hung state where you have cursor control but the session setup does not get to the point where you can select anything.
We have checked the logs and see nothing in the logs that indicate an issue. The other change noticed is the monitor never goes to sleep when the greater screen is active.
Does systemctl restart gdm.service from text shell help you restore system responsiveness? It might be some problem with gnome-shell or Xorg, I'm facing similar behavior from time to time on fresh installation.
Same recovery as doing init 3 init 5 you get back to the Gnome greater screen with the session ended. We have looked at the Xorg log files and see nothing wrong in them. Our case is not intermittent. We have tried both VGA and HDMI connections and get the same results. We have also reviewed dmesg and the /var/log/message log files. Nothing seems to get logged. We have checked for selinux avc issues and tried login in selinux Permissive mode. Second check just now indicates that a systemctl restart gdm.service gets us back to the Gnome greater screen but then we were not able to select a user for login.
We see by using journalctl -f | less That the shell fails to register before a timeout occurs and that there is a kernal pool segfault and a core dump. We have not been able to determine if they are all related. Except they happen close together.
Mateusz Marzantowicz
users mailing list users@lists.fedoraproject.org To unsubscribe or change subscription options: https://admin.fedoraproject.org/mailman/listinfo/users Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines Have a question? Ask away: http://ask.fedoraproject.org
-- users mailing list users@lists.fedoraproject.org To unsubscribe or change subscription options: https://admin.fedoraproject.org/mailman/listinfo/users Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines Have a question? Ask away: http://ask.fedoraproject.org
On 22.12.2013 22:49, David Highley wrote:
"David Highley wrote:"
"Mateusz Marzantowicz wrote:"
On 21.12.2013 20:40, David Highley wrote:
We upgraded a test system to Fedora 20 using the fedup process. There were 60 packages that were left from Fedora 19 after the upgrade that were subsequently fixed by doing a yum distro-sync. Since the upgrade we are not able to login into a Gnome session. We select the user in the greater and it prompts for the pass word. After that it goes to the grayed background and hangs leaving the user session in a hung state where you have cursor control but the session setup does not get to the point where you can select anything.
We have checked the logs and see nothing in the logs that indicate an issue. The other change noticed is the monitor never goes to sleep when the greater screen is active.
Does systemctl restart gdm.service from text shell help you restore system responsiveness? It might be some problem with gnome-shell or Xorg, I'm facing similar behavior from time to time on fresh installation.
Same recovery as doing init 3 init 5 you get back to the Gnome greater screen with the session ended. We have looked at the Xorg log files and see nothing wrong in them. Our case is not intermittent. We have tried both VGA and HDMI connections and get the same results. We have also reviewed dmesg and the /var/log/message log files. Nothing seems to get logged. We have checked for selinux avc issues and tried login in selinux Permissive mode. Second check just now indicates that a systemctl restart gdm.service gets us back to the Gnome greater screen but then we were not able to select a user for login.
We see by using journalctl -f | less That the shell fails to register before a timeout occurs and that there is a kernal pool segfault and a core dump. We have not been able to determine if they are all related. Except they happen close together.
It might be coincidence but it's worth investigating it. I don't experience any core dumps when having issues with gnome-shell but who knows how it's in your case.
Mateusz Marzantowicz
"Mateusz Marzantowicz wrote:"
On 22.12.2013 22:49, David Highley wrote:
"David Highley wrote:"
"Mateusz Marzantowicz wrote:"
On 21.12.2013 20:40, David Highley wrote:
We upgraded a test system to Fedora 20 using the fedup process. There were 60 packages that were left from Fedora 19 after the upgrade that were subsequently fixed by doing a yum distro-sync. Since the upgrade we are not able to login into a Gnome session. We select the user in the greater and it prompts for the pass word. After that it goes to the grayed background and hangs leaving the user session in a hung state where you have cursor control but the session setup does not get to the point where you can select anything.
We have checked the logs and see nothing in the logs that indicate an issue. The other change noticed is the monitor never goes to sleep when the greater screen is active.
Does systemctl restart gdm.service from text shell help you restore system responsiveness? It might be some problem with gnome-shell or Xorg, I'm facing similar behavior from time to time on fresh installation.
Same recovery as doing init 3 init 5 you get back to the Gnome greater screen with the session ended. We have looked at the Xorg log files and see nothing wrong in them. Our case is not intermittent. We have tried both VGA and HDMI connections and get the same results. We have also reviewed dmesg and the /var/log/message log files. Nothing seems to get logged. We have checked for selinux avc issues and tried login in selinux Permissive mode. Second check just now indicates that a systemctl restart gdm.service gets us back to the Gnome greater screen but then we were not able to select a user for login.
We see by using journalctl -f | less That the shell fails to register before a timeout occurs and that there is a kernal pool segfault and a core dump. We have not been able to determine if they are all related. Except they happen close together.
It might be coincidence but it's worth investigating it. I don't experience any core dumps when having issues with gnome-shell but who knows how it's in your case.
Since we saw the complaint about a timeout we changed the nsswitch.conf file to look at files before dns and stopped autofs and hardmounted the home directories. We have now upgraded a second system which has the same issue. Yet no fix found.
Mateusz Marzantowicz
users mailing list users@lists.fedoraproject.org To unsubscribe or change subscription options: https://admin.fedoraproject.org/mailman/listinfo/users Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines Have a question? Ask away: http://ask.fedoraproject.org
On Dec 22, 2013 2:49 PM, "David Highley" dhighley@highley-recommended.com wrote: user for login.
We see by using journalctl -f | less That the shell fails to register before a timeout occurs and that there is a kernal pool segfault and a core dump. We have not been able to determine if they are all related. Except they happen close together.
`journalctl _UID=<user's uid>` might be a helpful filter here - similar to the now obsolete ~/.xsession-errors.
--Pete
"Pete Travis wrote:"
--===============6465155735344206330== Content-Type: multipart/alternative; boundary=001a11c38892b4deff04ee38beb6
--001a11c38892b4deff04ee38beb6 Content-Type: text/plain; charset=ISO-8859-1
On Dec 22, 2013 2:49 PM, "David Highley" dhighley@highley-recommended.com wrote: user for login.
We see by using journalctl -f | less That the shell fails to register before a timeout occurs and that there is a kernal pool segfault and a core dump. We have not been able to determine if they are all related. Except they happen close together.
`journalctl _UID=<user's uid>` might be a helpful filter here - similar to the now obsolete ~/.xsession-errors.
OK, we have done this and included the output for a login attempt. The abrt tracker is indicating that this has been previously reported so maybe with some luck it will get corrected. In the mean time Cinnamon seems to work for an alternative. Dec 23 12:08:25 redwood gnome-session[3721]: OK Dec 23 12:09:03 redwood systemd[4669]: Failed to open private bus connection: Failed to connect to socket /run/user/1000/dbus/user_bus_socket: No such file or directory Dec 23 12:09:03 redwood systemd[4669]: Starting Default. Dec 23 12:09:03 redwood systemd[4669]: Reached target Default. Dec 23 12:09:03 redwood systemd[4669]: Startup finished in 6ms. Dec 23 12:09:05 redwood gnome-session[4676]: gnome-session[4676]: WARNING: Could not parse desktop file gnome-do.desktop or it references a not found TryExec binary Dec 23 12:09:05 redwood gnome-session[4676]: WARNING: Could not parse desktop file gnome-do.desktop or it references a not found TryExec binary Dec 23 12:09:05 redwood gnome-session[4676]: gnome-session[4676]: WARNING: Could not parse desktop file remmina-applet.desktop or it references a not found TryExec binary Dec 23 12:09:05 redwood gnome-session[4676]: WARNING: Could not parse desktop file remmina-applet.desktop or it references a not found TryExec binary Dec 23 12:09:05 redwood gnome-keyring-daemon[4674]: Gkm: using old keyring directory: /home/dhighley/.gnome2/keyrings Dec 23 12:09:05 redwood gnome-keyring-daemon[4674]: Gkm: using old keyring directory: /home/dhighley/.gnome2/keyrings Dec 23 12:09:05 redwood goa[4910]: goa-daemon version 3.10.2 starting [main.c:117, main()] Dec 23 12:09:05 redwood goa[4910]: GoaKerberosIdentityManager: Using polling for change notification for credential cache type 'KEYRING' [goakerberosidentitymanager.c:1393, monitor_credentials_cache()] Dec 23 12:09:05 redwood gnome-session[4676]: GNOME_KEYRING_CONTROL=/run/user/1000/keyring-0YW89L Dec 23 12:09:05 redwood gnome-session[4676]: GPG_AGENT_INFO=/run/user/1000/keyring-0YW89L/gpg:0:1 Dec 23 12:09:05 redwood gnome-session[4676]: GNOME_KEYRING_CONTROL=/run/user/1000/keyring-0YW89L Dec 23 12:09:05 redwood gnome-session[4676]: GPG_AGENT_INFO=/run/user/1000/keyring-0YW89L/gpg:0:1 Dec 23 12:09:05 redwood gnome-session[4676]: SSH_AUTH_SOCK=/run/user/1000/keyring-0YW89L/ssh Dec 23 12:09:05 redwood gnome-session[4676]: GNOME_KEYRING_CONTROL=/run/user/1000/keyring-0YW89L Dec 23 12:09:05 redwood gnome-session[4676]: GPG_AGENT_INFO=/run/user/1000/keyring-0YW89L/gpg:0:1 Dec 23 12:09:05 redwood gnome-session[4676]: SSH_AUTH_SOCK=/run/user/1000/keyring-0YW89L/ssh Dec 23 12:09:05 redwood gnome-session[4676]: GNOME_KEYRING_CONTROL=/run/user/1000/keyring-0YW89L Dec 23 12:09:05 redwood gnome-session[4676]: GPG_AGENT_INFO=/run/user/1000/keyring-0YW89L/gpg:0:1 Dec 23 12:09:05 redwood gnome-session[4676]: SSH_AUTH_SOCK=/run/user/1000/keyring-0YW89L/ssh Dec 23 12:09:05 redwood pulseaudio[4884]: [pulseaudio] bluez5-util.c: Found duplicated D-Bus path for device /org/bluez/hci0 Dec 23 12:09:05 redwood pulseaudio[4980]: [pulseaudio] pid.c: Daemon already running. Dec 23 12:09:05 redwood gnome-session[4676]: (gnome-settings-daemon:4865): smartcard-plugin-WARNING **: smartcard event function failed. Dec 23 12:09:05 redwood gnome-session[4676]: (gnome-settings-daemon:4865): GLib-GObject-CRITICAL **: g_object_unref: assertion 'G_IS_OBJECT (object)' failed Dec 23 12:09:06 redwood gnome-session[4676]: (gnome-shell:4986): Gjs-WARNING **: JS ERROR: Exception in callback for signal: sessions-loaded: Error: Argument 'text' (type utf8) may not be null Dec 23 12:09:06 redwood gnome-session[4676]: DateMenuButton<._updateClockAndDate@/usr/share/gnome-shell/js/ui/dateMenu.js:198 Dec 23 12:09:06 redwood gnome-session[4676]: wrapper@/usr/share/gjs-1.0/lang.js:213 Dec 23 12:09:06 redwood gnome-session[4676]: DateMenuButton<._init@/usr/share/gnome-shell/js/ui/dateMenu.js:139 Dec 23 12:09:06 redwood gnome-session[4676]: wrapper@/usr/share/gjs-1.0/lang.js:213 Dec 23 12:09:06 redwood gnome-session[4676]: _Base._construct@/usr/share/gjs-1.0/lang.js:154 Dec 23 12:09:06 redwood gnome-session[4676]: Class._construct/newClass@/usr/share/gjs-1.0/lang.js:248 Dec 23 12:09:06 redwood gnome-session[4676]: Panel<._ensureIndicator@/usr/share/gnome-shell/js/ui/panel.js:1097 Dec 23 12:09:06 redwood gnome-session[4676]: wrapper@/usr/share/gjs-1.0/lang.js:213 Dec 23 12:09:06 redwood gnome-session[4676]: Panel<._updateBox@/usr/share/gnome-shell/js/ui/panel.js:1108 Dec 23 12:09:06 redwood gnome-session[4676]: wrapper@/usr/share/gjs-1.0/lang.js:213 Dec 23 12:09:06 redwood gnome-session[4676]: Panel<._updatePanel@/usr/share/gnome-shell/js/ui/panel.js:1059 Dec 23 12:09:06 redwood gnome-session[4676]: wrapper@/usr/share/gjs-1.0/lang.js:213 Dec 23 12:09:06 redwood gnome-session[4676]: Panel<._init@/usr/share/gnome-shell/js/ui/panel.js:904 Dec 23 12:09:06 redwood gnome-session[4676]: wrapper@/usr/share/gjs-1.0/lang.js:213 Dec 23 12:09:06 redwood gnome-session[4676]: _Base._construct@/usr/share/gjs-1.0/lang.js:154 Dec 23 12:09:06 redwood gnome-session[4676]: Class._construct/newClass@/usr/share/gjs-1.0/lang.js:248 Dec 23 12:09:06 redwood gnome-session[4676]: _initializeUI@/usr/share/gnome-shell/js/ui/main.js:173 Dec 23 12:09:06 redwood gnome-session[4676]: _sessionsLoaded@/usr/share/gnome-shell/js/ui/main.js:122 Dec 23 12:09:06 redwood gnome-session[4676]: _emit@/usr/share/gjs-1.0/signals.js:124 Dec 23 12:09:06 redwood gnome-session[4676]: SessionMode<.init/<@/usr/share/gnome-shell/js/ui/sessionMode.js:161 Dec 23 12:09:06 redwood gnome-session[4676]: done@/usr/share/gnome-shell/js/misc/fileUtils.js:33 Dec 23 12:09:06 redwood gnome-session[4676]: @/usr/share/gnome-shell/js/misc/fileUtils.js:51 Dec 23 12:09:06 redwood gnome-session[4676]: onNextFileComplete@/usr/share/gnome-shell/js/misc/fileUtils.js:21 Dec 23 12:10:00 redwood gnome-session[4676]: (gnome-shell:4986): Gjs-WARNING **: JS ERROR: Error: Argument 'text' (type utf8) may not be null Dec 23 12:10:00 redwood gnome-session[4676]: DateMenuButton<._updateClockAndDate@/usr/share/gnome-shell/js/ui/dateMenu.js:198 Dec 23 12:10:00 redwood gnome-session[4676]: wrapper@/usr/share/gjs-1.0/lang.js:213 Dec 23 12:10:36 redwood gnome-session[4676]: gnome-session[4676]: WARNING: Application 'gnome-shell.desktop' failed to register before timeout Dec 23 12:10:36 redwood gnome-session[4676]: WARNING: Application 'gnome-shell.desktop' failed to register before timeout Dec 23 12:10:36 redwood gnome-session[4676]: Unrecoverable failure in required component gnome-shell.desktop Dec 23 12:10:36 redwood gnome-session[4676]: vmware-user: could not open /proc/fs/vmblock/dev Dec 23 12:10:36 redwood vmusr[5082]: [ warning] [GLib-GObject] Attempt to add property ToolsCoreService::tcs-app-ctx after class was initialised Dec 23 12:10:36 redwood vmusr[5082]: [ warning] [GLib-GObject] Attempt to add property ToolsCoreService::tcs-prop-thread-pool after class was initialised Dec 23 12:10:36 redwood vmusr[5082]: [ warning] [vmtoolsd] The vmusr service needs to run inside a virtual machine. Dec 23 12:10:36 redwood gnome-session[4676]: Entering running state Dec 23 12:10:36 redwood gnome-session[4676]: Window manager warning: Log level 16: STACK_OP_ADD: window 0x1e00001 already in stack Dec 23 12:10:36 redwood gnome-session[4676]: Window manager warning: Log level 16: STACK_OP_ADD: window 0x1e00001 already in stack Dec 23 12:10:36 redwood gnome-session[4676]: Failed to play sound: File or data not found Dec 23 12:10:36 redwood gnome-session[4676]: GDBus.Error:org.gtk.GDBus.UnmappedGError.Quark._imsettings_2derror_2dquark.Code5: Current desktop isn't targeted by IMSettings. Dec 23 12:10:37 redwood gnome-session[4676]: (tracker-store:5085): Tracker-WARNING **: Could not create FTS update statement: no such module: trackerfts Dec 23 12:10:37 redwood gnome-session[4676]: (tracker-store:5085): Tracker-WARNING **: Could not create FTS update statement: no such module: trackerfts Dec 23 12:10:37 redwood gnome-session[4676]: (tracker-store:5085): Tracker-WARNING **: Could not create FTS insert statement: no such module: trackerfts Dec 23 12:10:37 redwood gnome-session[4676]: (tracker-store:5085): Tracker-CRITICAL **: tracker_db_statement_bind_int: assertion 'TRACKER_IS_DB_STATEMENT (stmt)' failed Dec 23 12:10:38 redwood gnome-session[4676]: (tracker-miner-fs:5079): Tracker-CRITICAL **: (Sparql buffer) Error in array-update: GDBus.Error:org.freedesktop.DBus.Error.NoReply: Message did not receive a reply (timeout by message bus) Dec 23 12:10:38 redwood gnome-session[4676]: (tracker-miner-fs:5079): Tracker-CRITICAL **: Could not execute sparql: GDBus.Error:org.freedesktop.DBus.Error.NoReply: Message did not receive a reply (timeout by message bus) Dec 23 12:10:38 redwood gnome-session[4676]: (tracker-miner-fs:5079): Tracker-CRITICAL **: Could not execute sparql: GDBus.Error:org.freedesktop.DBus.Error.NoReply: Message did not receive a reply (timeout by message bus) Dec 23 12:10:38 redwood gnome-session[4676]: (tracker-miner-fs:5079): Tracker-CRITICAL **: Could not execute sparql: GDBus.Error:org.freedesktop.DBus.Error.NoReply: Message did not receive a reply (timeout by message bus) Dec 23 12:10:38 redwood gnome-session[4676]: (tracker-miner-fs:5079): Tracker-CRITICAL **: Could not execute sparql: GDBus.Error:org.freedesktop.DBus.Error.NoReply: Message did not receive a reply (timeout by message bus) Dec 23 12:10:38 redwood gnome-session[4676]: (abrt:5080): libnotify-WARNING **: Failed to connect to proxy Dec 23 12:10:38 redwood gnome-session[4676]: abrt-applet: Failed to receive server caps Dec 23 12:10:38 redwood gnome-session[4676]: abrt-applet: Can't show notification: GDBus.Error:org.freedesktop.DBus.Error.UnknownMethod: No such interface 'org.freedesktop.Notifications' on object at path /org/freedesktop/Notifications Dec 23 12:10:46 redwood gnome-session[4676]: (nm-applet:5083): nm-applet-WARNING **: Could not find ShellVersion property on org.gnome.Shell after 5 tries Dec 23 12:11:00 redwood gnome-session[4676]: (gnome-shell:4986): Gjs-WARNING **: JS ERROR: Error: Argument 'text' (type utf8) may not be null Dec 23 12:11:00 redwood gnome-session[4676]: DateMenuButton<._updateClockAndDate@/usr/share/gnome-shell/js/ui/dateMenu.js:198 Dec 23 12:11:00 redwood gnome-session[4676]: wrapper@/usr/share/gjs-1.0/lang.js:213
--Pete
--001a11c38892b4deff04ee38beb6 Content-Type: text/html; charset=ISO-8859-1
<p dir="ltr"><br> On Dec 22, 2013 2:49 PM, "David Highley" <<a href="mailto:dhighley@highley-recommended.com">dhighley@highley-recommended.com</a>> wrote:<br> user for login.<br> > ><br> ><br> > We see by using journalctl -f | less<br> > That the shell fails to register before a timeout occurs and that there<br> > is a kernal pool segfault and a core dump. We have not been able to<br> > determine if they are all related. Except they happen close together.<br> ></p> <p dir="ltr">`journalctl _UID=<user's uid>` might be a helpful filter here - similar to the now obsolete ~/.xsession-errors.</p> <p dir="ltr">--Pete</p>
--001a11c38892b4deff04ee38beb6--
--===============6465155735344206330== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Disposition: inline
LS0gCnVzZXJzIG1haWxpbmcgbGlzdAp1c2Vyc0BsaXN0cy5mZWRvcmFwcm9qZWN0Lm9yZwpUbyB1 bnN1YnNjcmliZSBvciBjaGFuZ2Ugc3Vic2NyaXB0aW9uIG9wdGlvbnM6Cmh0dHBzOi8vYWRtaW4u ZmVkb3JhcHJvamVjdC5vcmcvbWFpbG1hbi9saXN0aW5mby91c2VycwpGZWRvcmEgQ29kZSBvZiBD b25kdWN0OiBodHRwOi8vZmVkb3JhcHJvamVjdC5vcmcvY29kZS1vZi1jb25kdWN0Ckd1aWRlbGlu ZXM6IGh0dHA6Ly9mZWRvcmFwcm9qZWN0Lm9yZy93aWtpL01haWxpbmdfbGlzdF9ndWlkZWxpbmVz CkhhdmUgYSBxdWVzdGlvbj8gQXNrIGF3YXk6IGh0dHA6Ly9hc2suZmVkb3JhcHJvamVjdC5vcmcK
--===============6465155735344206330==--
On Dec 23, 2013 1:22 PM, "David Highley" dhighley@highley-recommended.com wrote:
"Pete Travis wrote:"
...
`journalctl _UID=<user's uid>` might be a helpful filter here - similar
to
the now obsolete ~/.xsession-errors.
OK, we have done this and included the output for a login attempt. The abrt tracker is indicating that this has been previously reported so maybe with some luck it will get corrected. In the mean time Cinnamon seems to work for an alternative. Dec 23 12:08:25 redwood gnome-session[3721]: OK Dec 23 12:09:03 redwood systemd[4669]: Failed to open private bus
connection: Failed to connect to socket /run/user/1000/dbus/user_bus_socket: No such file or directory
Dec 23 12:09:03 redwood systemd[4669]: Starting Default. Dec 23 12:09:03 redwood systemd[4669]: Reached target Default. Dec 23 12:09:03 redwood systemd[4669]: Startup finished in 6ms. Dec 23 12:09:05 redwood gnome-session[4676]: gnome-session[4676]:
WARNING: Could not parse desktop file gnome-do.desktop or it references a not found TryExec binary
Dec 23 12:09:05 redwood gnome-session[4676]: WARNING: Could not parse
desktop file gnome-do.desktop or it references a not found TryExec binary
Dec 23 12:09:05 redwood gnome-session[4676]: gnome-session[4676]:
WARNING: Could not parse desktop file remmina-applet.desktop or it references a not found TryExec binary
Dec 23 12:09:05 redwood gnome-session[4676]: WARNING: Could not parse
desktop file remmina-applet.desktop or it references a not found TryExec binary
This bit looks ripe for investigation. Do you have these .desktop files, and do they contain correct references to present and functional binaries?
Dec 23 12:09:06 redwood gnome-session[4676]: (gnome-shell:4986):
Gjs-WARNING **: JS ERROR: Exception in callback for signal: sessions-loaded: Error: Argument 'text' (type utf8) may not be null
...snip apparent traceback
This is suspicious as well. Incompatible extension, perhaps?
snip remainder, gnome-shell didn't open so dependents fail too.
Have you tried with a new user? If that works, move around your .files to isolate the culprit.
--Pete
"Pete Travis wrote:"
--===============3837768215548578561== Content-Type: multipart/alternative; boundary=001a1135e9d6f7fc3604ee3ba4d1
--001a1135e9d6f7fc3604ee3ba4d1 Content-Type: text/plain; charset=ISO-8859-1
On Dec 23, 2013 1:22 PM, "David Highley" dhighley@highley-recommended.com wrote:
"Pete Travis wrote:"
...
`journalctl _UID=<user's uid>` might be a helpful filter here - similar
to
the now obsolete ~/.xsession-errors.
OK, we have done this and included the output for a login attempt. The abrt tracker is indicating that this has been previously reported so maybe with some luck it will get corrected. In the mean time Cinnamon seems to work for an alternative. Dec 23 12:08:25 redwood gnome-session[3721]: OK Dec 23 12:09:03 redwood systemd[4669]: Failed to open private bus
connection: Failed to connect to socket /run/user/1000/dbus/user_bus_socket: No such file or directory
Dec 23 12:09:03 redwood systemd[4669]: Starting Default. Dec 23 12:09:03 redwood systemd[4669]: Reached target Default. Dec 23 12:09:03 redwood systemd[4669]: Startup finished in 6ms. Dec 23 12:09:05 redwood gnome-session[4676]: gnome-session[4676]:
WARNING: Could not parse desktop file gnome-do.desktop or it references a not found TryExec binary
Dec 23 12:09:05 redwood gnome-session[4676]: WARNING: Could not parse
desktop file gnome-do.desktop or it references a not found TryExec binary
Dec 23 12:09:05 redwood gnome-session[4676]: gnome-session[4676]:
WARNING: Could not parse desktop file remmina-applet.desktop or it references a not found TryExec binary
Dec 23 12:09:05 redwood gnome-session[4676]: WARNING: Could not parse
desktop file remmina-applet.desktop or it references a not found TryExec binary
This bit looks ripe for investigation. Do you have these .desktop files, and do they contain correct references to present and functional binaries?
Dec 23 12:09:06 redwood gnome-session[4676]: (gnome-shell:4986):
Gjs-WARNING **: JS ERROR: Exception in callback for signal: sessions-loaded: Error: Argument 'text' (type utf8) may not be null
...snip apparent traceback
This is suspicious as well. Incompatible extension, perhaps?
snip remainder, gnome-shell didn't open so dependents fail too.
Have you tried with a new user? If that works, move around your .files to isolate the culprit.
OK, I did find those and some old gnome2 stuff. So I went the drastic route and wiped out all files and directories with gnome in the name. Still get the same results.
--Pete
--001a1135e9d6f7fc3604ee3ba4d1 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
<p dir=3D"ltr"><br> On Dec 23, 2013 1:22 PM, "David Highley" <<a href=3D"mailto:dh= ighley@highley-recommended.com">dhighley@highley-recommended.com</a>> wr= ote:<br> ><br> > "Pete Travis wrote:"<br> ...<br> > > `journalctl _UID=3D<user's uid>` might be a helpful fil= ter here - similar to<br> > > the now obsolete ~/.xsession-errors.<br> ><br> > OK, we have done this and included the output for a login attempt. The= <br> > abrt tracker is indicating that this has been previously reported so<b= r> > maybe with some luck it will get corrected. In the mean time Cinnamon<= br> > seems to work for an alternative.<br> > Dec 23 12:08:25 redwood gnome-session[3721]: OK<br> > Dec 23 12:09:03 redwood systemd[4669]: Failed to open private bus conn= ection: Failed to connect to socket /run/user/1000/dbus/user_bus_socket: No= such file or directory<br> > Dec 23 12:09:03 redwood systemd[4669]: Starting Default.<br> > Dec 23 12:09:03 redwood systemd[4669]: Reached target Default.<br> > Dec 23 12:09:03 redwood systemd[4669]: Startup finished in 6ms.<br> > Dec 23 12:09:05 redwood gnome-session[4676]: gnome-session[4676]: WARN= ING: Could not parse desktop file gnome-do.desktop or it references a not f= ound TryExec binary<br> > Dec 23 12:09:05 redwood gnome-session[4676]: WARNING: Could not parse = desktop file gnome-do.desktop or it references a not found TryExec binary<b= r> > Dec 23 12:09:05 redwood gnome-session[4676]: gnome-session[4676]: WARN= ING: Could not parse desktop file remmina-applet.desktop or it references a= not found TryExec binary<br> > Dec 23 12:09:05 redwood gnome-session[4676]: WARNING: Could not parse = desktop file remmina-applet.desktop or it references a not found TryExec bi= nary</p> <p dir=3D"ltr">This bit looks ripe for investigation.=A0 Do you have these = .desktop files, and do they contain correct references to present and funct= ional binaries?</p> <p dir=3D"ltr">> <br> > Dec 23 12:09:06 redwood gnome-session[4676]: (gnome-shell:4986): Gjs-W= ARNING **: JS ERROR: Exception in callback for signal: sessions-loaded: Err= or: Argument 'text' (type utf8) may not be null<br> > ...snip apparent traceback</p> <p dir=3D"ltr">This is suspicious as well. Incompatible extension, perhaps?= </p> <p dir=3D"ltr">> snip remainder, gnome-shell didn't open so dependen= ts fail too.<br></p> <p dir=3D"ltr">Have you tried with a new user? If that works, move around y= our .files to isolate the culprit.</p> <p dir=3D"ltr">--Pete</p>
--001a1135e9d6f7fc3604ee3ba4d1--
--===============3837768215548578561== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Disposition: inline
LS0gCnVzZXJzIG1haWxpbmcgbGlzdAp1c2Vyc0BsaXN0cy5mZWRvcmFwcm9qZWN0Lm9yZwpUbyB1 bnN1YnNjcmliZSBvciBjaGFuZ2Ugc3Vic2NyaXB0aW9uIG9wdGlvbnM6Cmh0dHBzOi8vYWRtaW4u ZmVkb3JhcHJvamVjdC5vcmcvbWFpbG1hbi9saXN0aW5mby91c2VycwpGZWRvcmEgQ29kZSBvZiBD b25kdWN0OiBodHRwOi8vZmVkb3JhcHJvamVjdC5vcmcvY29kZS1vZi1jb25kdWN0Ckd1aWRlbGlu ZXM6IGh0dHA6Ly9mZWRvcmFwcm9qZWN0Lm9yZy93aWtpL01haWxpbmdfbGlzdF9ndWlkZWxpbmVz CkhhdmUgYSBxdWVzdGlvbj8gQXNrIGF3YXk6IGh0dHA6Ly9hc2suZmVkb3JhcHJvamVjdC5vcmcK
--===============3837768215548578561==--
On Dec 23, 2013 4:47 PM, "David Highley" dhighley@highley-recommended.com wrote:
"
OK, I did find those and some old gnome2 stuff. So I went the drastic route and wiped out all files and directories with gnome in the name. Still get the same results.
And with the new user account? This is a crucial test, because tweaking your config files and troubleshooting the display stack are very different.
--Pete
"Pete Travis wrote:"
--===============8084609375064345886== Content-Type: multipart/alternative; boundary=001a11c36c50d0f15c04ee3edcaa
--001a11c36c50d0f15c04ee3edcaa Content-Type: text/plain; charset=ISO-8859-1
On Dec 23, 2013 4:47 PM, "David Highley" dhighley@highley-recommended.com wrote:
"
OK, I did find those and some old gnome2 stuff. So I went the drastic route and wiped out all files and directories with gnome in the name. Still get the same results.
And with the new user account? This is a crucial test, because tweaking your config files and troubleshooting the display stack are very different.
Bingo, seems to be old scruff somewhere in the accounts that is preventing the logins from working. Did two tests. One with a local new account and another with the account on the remote user server using autofs and NFS to server the home directories. Both tests worked.
Now do we take a meat axe and remove all the dot directories or in great pain discover what is blocking the logins from working. Note we have already removed every directory and file that had gnome in the name.
--Pete
--001a11c36c50d0f15c04ee3edcaa Content-Type: text/html; charset=ISO-8859-1
<p dir="ltr"><br> On Dec 23, 2013 4:47 PM, "David Highley" <<a href="mailto:dhighley@highley-recommended.com">dhighley@highley-recommended.com</a>> wrote:<br> ><br> > "<br> ><br> > OK, I did find those and some old gnome2 stuff. So I went the drastic<br> > route and wiped out all files and directories with gnome in the name.<br> > Still get the same results.<br> ></p> <p dir="ltr">And with the new user account? This is a crucial test, because tweaking your config files and troubleshooting the display stack are very different. </p> <p dir="ltr">--Pete<br> </p>
--001a11c36c50d0f15c04ee3edcaa--
--===============8084609375064345886== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Disposition: inline
LS0gCnVzZXJzIG1haWxpbmcgbGlzdAp1c2Vyc0BsaXN0cy5mZWRvcmFwcm9qZWN0Lm9yZwpUbyB1 bnN1YnNjcmliZSBvciBjaGFuZ2Ugc3Vic2NyaXB0aW9uIG9wdGlvbnM6Cmh0dHBzOi8vYWRtaW4u ZmVkb3JhcHJvamVjdC5vcmcvbWFpbG1hbi9saXN0aW5mby91c2VycwpGZWRvcmEgQ29kZSBvZiBD b25kdWN0OiBodHRwOi8vZmVkb3JhcHJvamVjdC5vcmcvY29kZS1vZi1jb25kdWN0Ckd1aWRlbGlu ZXM6IGh0dHA6Ly9mZWRvcmFwcm9qZWN0Lm9yZy93aWtpL01haWxpbmdfbGlzdF9ndWlkZWxpbmVz CkhhdmUgYSBxdWVzdGlvbj8gQXNrIGF3YXk6IGh0dHA6Ly9hc2suZmVkb3JhcHJvamVjdC5vcmcK
--===============8084609375064345886==--
On Dec 24, 2013 1:34 PM, "David Highley" dhighley@highley-recommended.com wrote:
( I wrote )
And with the new user account? This is a crucial test, because tweaking your config files and troubleshooting the display stack are very
different.
(Reply)
Bingo, seems to be old scruff somewhere in the accounts that is preventing the logins from working. Did two tests. One with a local new account and another with the account on the remote user server using autofs and NFS to server the home directories. Both tests worked.
Now do we take a meat axe and remove all the dot directories or in great pain discover what is blocking the logins from working. Note we have already removed every directory and file that had gnome in the name.
Only you can answer this question. If you only have a hammer in your toolbox, use the hammer. If you have some patience and a scalpel, you can be more selective.
BTW, there's nothing that says that any file created by GNOME must have "gnome" in the file name, and nothing that restricts GNOME from using files that don't have "gnome" in the file name. It's a good start, but the process continues.
--Pete
-
David Highley -
Mateusz Marzantowicz -
Pete Travis