Description of problem: Happens on first boot of a fresh installed F23 system (2015-07-16 nightly). Makes system unusable (doesn't reach GDM or a desktop). Version-Release number of selected component: gnome-initial-setup-3.16.3-2.fc23 Additional info: reporter: libreport-2.6.1 backtrace_rating: 4 cmdline: /usr/libexec/gnome-initial-setup crash_function: _g_log_abort executable: /usr/libexec/gnome-initial-setup global_pid: 1553 kernel: 4.2.0-0.rc2.git1.1.fc23.x86_64 runlevel: N 5 type: CCpp uid: 987 Truncated backtrace: Thread no. 1 (10 frames) #0 _g_log_abort at gmessages.c:316 #3 gis_timezone_page_constructed at gis-timezone-page.c:451 #4 g_object_new_internal at gobject.c:1814 #5 g_object_new_valist at gobject.c:2033 #7 gis_prepare_timezone_page at gis-timezone-page.c:528 #8 rebuild_pages_cb at gnome-initial-setup.c:172 #9 _g_closure_invoke_va at gclosure.c:864 #12 rebuild_pages at gis-driver.c:136 #13 gis_driver_startup at gis-driver.c:347 #14 _g_closure_invoke_va at gclosure.c:864
Created attachment 1052863 [details] File: backtrace
Created attachment 1052864 [details] File: cgroup
Created attachment 1052865 [details] File: core_backtrace
Created attachment 1052866 [details] File: dso_list
Created attachment 1052867 [details] File: environ
Created attachment 1052868 [details] File: limits
Created attachment 1052869 [details] File: maps
Created attachment 1052870 [details] File: mountinfo
Created attachment 1052871 [details] File: namespaces
Created attachment 1052872 [details] File: open_fds
Created attachment 1052873 [details] File: proc_pid_status
Journal messages (the first three probably aren't relevant, but just including for context): Jul 16 16:26:23 localhost.localdomain gnome-session[1394]: (gnome-initial-setup:1519): Gtk-CRITICAL **: Error building template class 'GisBubbleWidget' for an instance of type 'GisBubbleWidget': .:2:910 Can't use <style> here Jul 16 16:26:23 localhost.localdomain gnome-session[1394]: (gnome-initial-setup:1519): Gtk-CRITICAL **: gtk_label_set_label: assertion 'GTK_IS_LABEL (label)' failed Jul 16 16:26:23 localhost.localdomain gnome-session[1394]: (gnome-initial-setup:1519): GLib-GObject-CRITICAL **: g_object_set: assertion 'G_IS_OBJECT (object)' failed Jul 16 16:26:23 localhost.localdomain dbus[743]: [system] Activating via systemd: service name='org.freedesktop.timedate1' unit='dbus-org.freedesktop.timedate1.service' Jul 16 16:26:23 localhost.localdomain dbus[743]: [system] Activation via systemd failed for unit 'dbus-org.freedesktop.timedate1.service': Unit timedatex.service failed to load: File exists. See system logs and 'systemctl status timedatex.service' for details. Jul 16 16:26:23 localhost.localdomain gnome-session[1394]: ** (gnome-initial-setup:1519): ERROR **: Failed to create proxy for timedated: Error calling StartServiceByName for org.freedesktop.timedate1: GDBus.Error:org.freedesktop.systemd1.LoadFailed: Unit timedatex.service failed to load: File exists. See system logs and 'systemctl status timedatex.service' for details. Proposing as an Alpha blocker: " A working mechanism to create a user account must be clearly presented during installation and/or first boot of the installed system. A system installed with a release-blocking desktop must boot to a log in screen where it is possible to log in to a working desktop using a user account created during installation or a 'first boot' utility." - https://fedoraproject.org/wiki/Fedora_23_Alpha_Release_Criteria#Expected_installed_system_boot_behavior timedatex-0.3-2.fc23 Running /usr/sbin/timedatex directly appears to succeed, but running 'systemctl start timedatex.service' fails with the same error as seen in the journal ("Unit timedatex.service failed to load: File exists.")
This seems to be caused in some way by a conflict with systemd-timedated.service . This works: mv /lib/systemd/system/systemd-timedated.service /tmp systemctl daemon-reload systemctl restart timedatex.service systemd-timedated.service and timedatex.service have identical BusName and CapabilityBoundingSet lines: BusName=org.freedesktop.timedate1 CapabilityBoundingSet=CAP_SYS_TIME Note that systemd-timedated.service doesn't have to be *running* for the bug to happen - it only has to be *there* ('loaded' in systemd parlance). this is clearly screwing up systemd. I'm not sure if it's because units aren't allowed to do that, or because they should be allowed to but systemd has a bug in this scenario. I'm also not sure whether it's considered a bug in g-i-s if it crashes when timedatex.service fails to start, or not. If that in itself is a bug in g-i-s, I can file a separate bug for the timedatex/systemd-timedated problem. If the crash itself isn't considered a bug, we can re-assign this to timedatex or systemd.
The 'timedatex.service fails' part of this seems to be a regression of some sort in systemd. In Fedora 22 (systemd 219) the setup is the same - both timedatex.service and systemd-timedated.service exist, and both specify the same BusName and CapabilityBoundingSet - but you can start either one up fine. In fact you can even start both at once (Pete knows which one gets to respond to dbus requests when you do that...)
I submitted an upstream bug for the systemd portion of this: https://github.com/systemd/systemd/issues/609
Discussed at today's blocker review meeting [1]. This bug was accepted as Alpha blocker - This bug is a clear violation of the following Alpha criterion: "A system installed with a release-blocking desktop must boot to a log in screen where it is possible to log in to a working desktop using a user account created during installation or a 'first boot' utility." [1] http://meetbot.fedoraproject.org/fedora-blocker-review/2015-07-20/
So, the plot thickens: Lennart says systemd isn't going to fix this, which means I guess it's up to timedatex to do something about it. I filed https://github.com/mlichvar/timedatex/issues/2 and I guess I'll re-assign this to timedatex.
Ok, it looks like we need to mask systemd-timedated in timedatex, at least for now. There might be a cleaner approach. If systemd-timedated had its own subpackage, timedatex could conflict with it at rpm level, so there would be always only one timedated implementation installed. The last attempt to split the systemd package didn't went too well, however.
timedatex-0.3-3.fc23 now includes a symlink that masks the systemd-timedated service. Thanks for the investigation, Adam.