This bug is a follow-up to https://bugzilla.redhat.com/show_bug.cgi?id=1431879 . Like that bug, this one concerns the case where you install Workstation without creating a user during the install process. When you do that, gnome-initial-setup should run on first boot before GDM, and allow (or rather, require) you to create a user account. After one bug which caused this to always fail was fixed (that's #1431879), it still appears to fail almost every time in Fedora 26 Alpha 1.1 and current Rawhide (both of which have the 'fixed' g-i-s). Now, instead of g-i-s failing immediately with the message "Unable to find required component 'gnome-settings-daemon'", it fails after two minutes with multiple errors like this: Mar 20 11:50:36 localhost-live.happyassassin.net audit[1]: SERVICE_STOP pid=1 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0 msg='unit=systemd-hostnamed comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success' Mar 20 11:50:36 localhost-live.happyassassin.net audit[1]: SERVICE_STOP pid=1 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0 msg='unit=systemd-localed comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success' Mar 20 11:51:35 localhost-live.happyassassin.net gnome-session[3022]: gnome-session-binary[3022]: WARNING: Application 'org.gnome.SettingsDaemon.Sound.desktop' failed to register before timeout Mar 20 11:51:35 localhost-live.happyassassin.net gnome-session-binary[3022]: Unrecoverable failure in required component org.gnome.SettingsDaemon.Sound.desktop Mar 20 11:51:35 localhost-live.happyassassin.net gnome-session-binary[3022]: WARNING: Application 'org.gnome.SettingsDaemon.Sound.desktop' failed to register before timeout Mar 20 11:51:35 localhost-live.happyassassin.net gnome-session[3022]: gnome-session-binary[3022]: WARNING: Application 'org.gnome.SettingsDaemon.Smartcard.desktop' failed to register before timeout Mar 20 11:51:35 localhost-live.happyassassin.net gnome-session-binary[3022]: Unrecoverable failure in required component org.gnome.SettingsDaemon.Smartcard.desktop Mar 20 11:51:35 localhost-live.happyassassin.net gnome-session-binary[3022]: WARNING: Application 'org.gnome.SettingsDaemon.Smartcard.desktop' failed to register before timeout Mar 20 11:51:35 localhost-live.happyassassin.net gnome-session[3022]: Unable to init server: Could not connect: Connection refused Mar 20 11:51:35 localhost-live.happyassassin.net gnome-session[3022]: Unable to init server: Could not connect: Connection refused at which point gnome-session-failed crashes, as usual. The g-i-s session then tries to start up again; it seems like it'll try every two minutes pretty much forever. In a VM test, I actually saw it fail five times and then succeed on the sixth try; in a test on a bare metal laptop, it's now tried 40 times without starting successfully once. roshi has tested this on bare metal also, and he left his for over 20 minutes without it managing to start up successfully. So it clearly fails an awful lot. This looks quite a lot like upstream GNOME bug https://bugzilla.gnome.org/show_bug.cgi?id=674885 , which has been reported to affect Fedora 26+ systems. In fact, it affects my own 'regular use' desktop. But at least on that system, I've found that I get a successful session start about 50% of the time, much better odds than this bug seems to have so far. I'm going to do a test install on my bare metal system *with* a user created during install, and see if it's affected by the 'regular user session start up' variant of the issue, and if so, how often it happens... It'd be good to get testing from more folks to get more data to determine how often this fails.
Proposing as an Alpha blocker on the same rationale as https://bugzilla.redhat.com/show_bug.cgi?id=1431879 , which was accepted as a blocker: violates "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" in the case of an install without creating a user.
Created attachment 1264850 [details] journal from a VM test where g-i-s start failed five times then succeeded
Adam, I'm using Ubuntu GNOME 17.04 with GNOME 3.23.92/3.24 and Initial Setup's New User mode fails for me every time (even with the patches proposed so far to GNOME #674885). I mentioned an ugly workaround at https://bugzilla.redhat.com/1431879#c11 I haven't noticed Initial Setup being broken for existing users. It's easy to test; just remove ~/.config/gnome-initial-setup-done Initial Setup will then pop up every time you log in until you click through to complete Initial Setup.
Yes, I already know the version of g-i-s that runs on first log in to a user account isn't broken, and I wouldn't expect it to be, because running i-s in an existing user's session doesn't involve session startup. This mode is failing during session startup. It does seem interesting that, so far, the g-i-s session startup seems much more prone to failure than a regular user session, but I want to do a bit more testing to be totally sure of that.
+1 blocker from me, for the criterion mentioned in c#1 and the reasoning
+1 blocker
+1 Blocker
That's +4 blocker (including me), setting accepted. We think we have a fix for this (rtcm found it, I tried it and it works for me), build coming soon.
gnome-initial-setup-3.24.0-1.fc26 has been submitted as an update to Fedora 26. https://bodhi.fedoraproject.org/updates/FEDORA-2017-559925b8d4
gnome-initial-setup-3.24.0-1.fc26 has been pushed to the Fedora 26 testing repository. If problems still persist, please make note of it in this bug report. See https://fedoraproject.org/wiki/QA:Updates_Testing for instructions on how to install test updates. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2017-559925b8d4
Confirmed fixed in Alpha RC2.
gnome-initial-setup-3.24.0-1.fc26 has been pushed to the Fedora 26 stable repository. If problems still persist, please make note of it in this bug report.