Well that was one hell of a circuitous problem solving tale of woe. So here’s the rundown:
After some upgrades, I ran into the following slew of errors on reboot (in reverse chronological order):
Jan 31 23:31:48 gdm: GLib: g_hash_table_find: assertion ‘version == hash_table->version’ failed
Jan 31 23:31:48 login: pam_systemd(login:session): Failed to release session: Interrupted system call
Jan 31 23:31:48 gnome-session-binary: GLib-GObject-CRITICAL: g_object_unref: assertion ‘G_IS_OBJECT (object)’ failed
Jan 31 23:31:48 gdm-x-session: GLib-GObject: g_object_unref: assertion ‘G_IS_OBJECT (object)’ failed
Jan 31 23:31:48 gdm-x-session: GLib-GIO: g_task_return_boolean: assertion ‘task->result_set == FALSE’ failed
Jan 31 22:22:16 gnome-settings-daemon.desktop: lock: No locks available
Jan 31 22:10:29 pulseaudio: Daemon already running.
Jan 31 22:08:37 abrt-hook-ccpp: Process 1888 (gnome-session-failed) of user 1000 killed by SIGSEGV – dumping core
Jan 31 22:08:37 gnome-session-binary: Unrecoverable failure in required component org.gnome.Shell.desktop
Jan 31 22:08:23 pulseaudio: [pulseaudio] bluez5-util.c: GetManagedObjects() failed: org.freedesktop.DBus.Error.NoReply: Did not receive a reply. Possible causes include: the remote appl
Jan 31 22:08:23 pulseaudio: [pulseaudio] core-util.c: lock: No locks available
Jan 31 22:07:33 pulseaudio: [pulseaudio] core-util.c: lock: No locks available
Looking a little closer, I found:
Jan 31 22:20:07 gnome-shell: cogl-sampler-cache.c:200: GL error (1280): Invalid enumeration value
Jan 31 22:20:06 gnome-shell: clutter_input_device_get_device_id: assertion ‘CLUTTER_IS_INPUT_DEVICE (device)’ failed
Jan 31 22:20:06 gnome-shell: STACK_OP_ADD: window 0x1200001 already in stack
Jan 31 22:08:37 kernel: gnome-session-f: segfault at 0 ip 00007fe59d2e1899 sp 00007ffc1269b3f0 error 4 in libgtk-3.so.0.2200.7[7fe59d003000+6f6000]
Though I fixated on that segmentation fault like a narrow-minded fool, I also noted what I should have considered immediately as abnormal and important:
Jan 31 22:15:39 kernel: lockd: server 172.16.1.102 OK
Jan 31 22:15:39 kernel: lockd: server 172.16.1.102 not responding, still trying
And the reason that’s so abnormal and important, in particular, is not only that my lockd service is having trouble contacting my NFS server, but that I use NFSv4…which doesn’t use lockd.
After banging my head against these errors by reinstalling my NVidia drivers, attempting the use of KDE Plasma rather than GNOME, and the like, all to no avail. Finding the issue to be common to GNOME and KDE Plasma (which doesn’t make use of the segfaulting libgtk, obviously), and running down a bug report on bugzilla that shows the error is actually a failure of GDM which likely occurs long after the real culprit, I actually took note of the fact that a number of services (gnome-settings-daemon, pulseaudio above) were citing the absence of locks as problems.
And that, my friends, was the issue. I had been messing around with my NFS server, trying to get the Windows NFS client to make proper use of file locking, and in the course of doing so, I had inadvertently caused the NFSv4 service to stop, leaving only NFSv3 and a busted-up lockd arrangement for my poor Fedora system. It automatically downgraded to NFSv3 when it found NFSv4 to fail, and being stuck without file locking, this actually caused the entire problem.
So, the moral of the story is: When using NFS-mounted home directories, sometimes NFS problems can even look like graphics driver problems.
Now, I firmly believe the benefits of NFS-mounted home directories outweigh the added potential for issues such as the above, so I’ll be keeping mine, thanks, but just know you should check on that stuff at the first sign of trouble and make sure all is well. The issues that can be caused by a file system problem with your home directory can look like just about anything.