Bug 1434154 - Pre-GDM gnome-initial-setup fails to run (when no user created during install), with multiple "Unrecoverable failure in required component" errors
Summary: Pre-GDM gnome-initial-setup fails to run (when no user created during install...
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: gnome-initial-setup
Version: 26
Hardware: x86_64
OS: Linux
unspecified
high
Target Milestone: ---
Assignee: Rui Matos
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard: AcceptedBlocker
Depends On:
Blocks: F26AlphaBlocker
TreeView+ depends on / blocked
 
Reported: 2017-03-20 20:12 UTC by Adam Williamson
Modified: 2017-03-24 21:53 UTC (History)
6 users (show)

Fixed In Version: gnome-initial-setup-3.24.0-1.fc26
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2017-03-24 21:53:20 UTC
Type: Bug


Attachments (Terms of Use)
journal from a VM test where g-i-s start failed five times then succeeded (772.36 KB, text/plain)
2017-03-20 20:18 UTC, Adam Williamson
no flags Details


Links
System ID Priority Status Summary Last Updated
GNOME Bugzilla 780362 Normal RESOLVED Initial Setup's New User mode no longer works in GNOME 3.24 2019-12-30 21:28:16 UTC
Red Hat Bugzilla 1431879 None None None Never

Internal Links: 1431879

Description Adam Williamson 2017-03-20 20:12:49 UTC
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.

Comment 1 Adam Williamson 2017-03-20 20:13:54 UTC
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.

Comment 2 Adam Williamson 2017-03-20 20:18:57 UTC
Created attachment 1264850 [details]
journal from a VM test where g-i-s start failed five times then succeeded

Comment 3 Jeremy Bicha 2017-03-20 20:22:18 UTC
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.

Comment 4 Adam Williamson 2017-03-20 20:25:23 UTC
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.

Comment 5 Tim Flink 2017-03-21 18:18:17 UTC
+1 blocker from me, for the criterion mentioned in c#1 and the reasoning

Comment 6 Dennis Gilmore 2017-03-21 18:20:32 UTC
+1 blocker

Comment 7 Mohan Boddu 2017-03-21 18:35:48 UTC
+1 Blocker

Comment 8 Adam Williamson 2017-03-21 18:54:12 UTC
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.

Comment 9 Fedora Update System 2017-03-21 19:04:10 UTC
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

Comment 10 Fedora Update System 2017-03-22 15:28:12 UTC
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

Comment 11 Adam Williamson 2017-03-22 21:13:02 UTC
Confirmed fixed in Alpha RC2.

Comment 12 Fedora Update System 2017-03-24 21:53:20 UTC
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.


Note You need to log in before you can comment on or make changes to this bug.