Bug 1933455 - takes more than 2 minutes for g-i-s to startup following clean install
Summary: takes more than 2 minutes for g-i-s to startup following clean install
Keywords:
Status: CLOSED DUPLICATE of bug 1924908
Alias: None
Product: Fedora
Classification: Fedora
Component: gnome-initial-setup
Version: 34
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Rui Matos
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks: F34BetaBlocker
TreeView+ depends on / blocked
 
Reported: 2021-02-28 00:49 UTC by Chris Murphy
Modified: 2021-03-11 16:39 UTC (History)
9 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2021-03-11 16:39:54 UTC
Type: Bug


Attachments (Terms of Use)
journal.log (595.57 KB, text/plain)
2021-02-28 00:49 UTC, Chris Murphy
no flags Details
journal2.log hw (670.88 KB, text/plain)
2021-03-10 22:05 UTC, Chris Murphy
no flags Details
journal.log3 (6.20 MB, text/plain)
2021-03-11 07:02 UTC, Chris Murphy
no flags Details


Links
System ID Private Priority Status Summary Last Updated
GNOME Gitlab GNOME mutter merge_requests 1771 0 None None None 2021-03-11 13:27:47 UTC

Description Chris Murphy 2021-02-28 00:49:47 UTC
Created attachment 1759727 [details]
journal.log

Created attachment 1759727 [details]
journal.log

Description of problem:

Reboot following clean install shows the desktop background art, but then nothing for ~2 minutes and then g-i-s appears.

Version-Release number of selected component (if applicable):
Fedora-Workstation-Live-x86_64-34-20210227.n.0.iso
gnome-initial-setup-40~beta-1.fc34.x86_64
gnome-session-3.38.0-3.fc34.x86_64

How reproducible:
Always


Steps to Reproduce:
1. Boot install media, do an installation, reboot
2.
3.

Actual results:

Long delay before inital setup appears

Expected results:

Initial setup should appear sooner than this

Additional info:


[  104.902811] gnome-session-binary[974]: WARNING: Application 'org.gnome.SettingsDaemon.XSettings.desktop' failed to register before timeout
[  104.903939] gnome-session-binary[974]: Unrecoverable failure in required component org.gnome.SettingsDaemon.XSettings.desktop

Still happens with enforcing=0.

Could be we need a newer gnome-session than composes are getting still for some reason.

Comment 1 Chris Murphy 2021-03-10 22:04:00 UTC
Experiencing this on hardware too (hp spectre), with Fedora-Workstation-Live-x86_64-34_Beta-1.1.iso which has:
gnome-desktop3-40~beta-1.fc34.x86_64
gnome-initial-setup-40~beta-1.fc34.x86_64
gnome-session-40~beta-1.fc34.x86_64
gnome-session-wayland-session-40~beta-1.fc34.x86_64
gnome-session-xsession-40~beta-1.fc34.x86_64
gnome-settings-daemon-40~beta-2.fc34.x86_64
gnome-shell-40.0~beta-1.fc34.x86_64

Comment 2 Chris Murphy 2021-03-10 22:05:28 UTC
Created attachment 1762476 [details]
journal2.log hw

Comment 3 Fedora Blocker Bugs Application 2021-03-11 01:30:24 UTC
Proposed as a Blocker for 34-beta by Fedora user chrismurphy using the blocker tracking app because:

 Basic 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.

Beta: Bug hinders execution of required Beta test plans or dramatically reduces test coverage.

These aren't solid arguments, because eventually it does appear. But what percent of users will wonder if it's crashed? CommonBugs might be adequate.

Comment 4 Chris Murphy 2021-03-11 01:35:46 UTC
Might be a dup of or relate to bug 1924908.

Comment 5 Adam Williamson 2021-03-11 01:54:05 UTC
yeah, I suspect they're effectively the same bug. We wait a long time for org.gnome.SettingsDaemon.XSettings.desktop to "register" (which basically means start up and report back, I think), and it never does; eventually we hit a timeout, which triggers the "Unrecoverable failure in required component org.gnome.SettingsDaemon.XSettings.desktop" error and the "Oh no!" screen, but we *do* in fact go ahead and run g-i-s anyway. The fact that g-i-s actually does run anyway is the most surprising thing to me, but it definitely seems to be the case. All the other stuff - the long wait and the "Oh no!" screen, and the logged messages and their timestamps - lines up quite nicely.

Small side note - If you're running on a slow system, then *after* g-i-s is finished, you see the "Oh no!" screen again briefly, before the newly created user's desktop appears.

Comment 6 Chris Murphy 2021-03-11 07:02:39 UTC
Created attachment 1762544 [details]
journal.log3

boot params: enforcing=0 systemd.log_level=debug systemd.debug-shell=1
also, previous to this boot, enabled gdm debug in /etc/gdm/custom.conf

Comment 7 Benjamin Berg 2021-03-11 09:08:39 UTC
The two bugs are definitely the same issue.

It boils down two:
 1. We are hitting the non-systemd startup path, as this is a "login" screen (otherwise multiseat would be completely broken)
 2. The gnome-initial-setup session pulls in Xsettings
 3. gnome-shell messes up and has the wrong impression it'll be able to auto-start Xwayland

This is identical to https://gitlab.gnome.org/GNOME/gnome-session/-/issues/79

My proposed solution was that mutter (or gnome-shell?) detect the non-systemd case by running sd_pid_get_user_unit (logind places these type of sessions into session-X.scope units, which are not part of the "user" manager and as such the function just returns an error).

Comment 8 František Zatloukal 2021-03-11 09:40:50 UTC
Just a related info - this doesn't happen when booted in basic video mode (so X11 session).

Comment 9 Benjamin Berg 2021-03-11 13:37:26 UTC
Note that a different workaround inside gnome-initial-setup would be to remove Xsettings from the session definition (i.e. /usr/share/gnome-session/sessions/gnome-initial-setup.session and for completeness sake /usr/lib/systemd/user/gnome-session@gnome-initial-setup.target.d/session.conf).

Comment 10 Adam Williamson 2021-03-11 16:39:54 UTC
Thanks, Ben. So we don't need two bugs; let's consolidate. I'll mark this as a dupe of that, and combine the blocker metadata appropriately.

*** This bug has been marked as a duplicate of bug 1924908 ***


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