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

Created attachment 1762476 [details]
journal2.log hw

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.

Might be a dup of or relate to bug 1924908.

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.

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

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

Just a related info - this doesn't happen when booted in basic video mode (so X11 session).

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.d/session.conf).

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 ***