In current composes of both Rawhide and Fedora 31, g-i-s is failing to run on first boot after install. This makes the system inoperable because it is not possible to create a user account and the root account is inaccessible after install. This is not the same as https://bugzilla.redhat.com/show_bug.cgi?id=1744352 , I don't think, as we had some successful builds between then and when it started failing again. When booted normally (with SELinux in enforcing mode), you see an "Oh no!" error screen, like this: https://openqa.fedoraproject.org/tests/437622#step/_graphical_wait_login/5 if you boot with SELinux in permissive mode or disabled, you don't get that 'Oh no!' screen, but g-i-s does not run. The system just gets stuck showing desktop background and nothing else. When booting with SELinux in enforcing mode, three AVCs appear in the logs: Aug 28 14:42:14 localhost-live systemd[991]: selinux: avc: denied { start } for auid=n/a uid=978 gid=976 path="/usr/lib/systemd/user/gnome-session-wayland@.target" cmdline="/usr/libexec/gnome-session-binary --autostart /usr/share/gdm/greeter/autostart --session gnome-initial-setup" scontext=system_u:system_r:xdm_t:s0-s0:c0.c1023 tcontext=system_u:object_r:systemd_unit_file_t:s0 tclass=service permissive=0 Aug 28 14:42:16 localhost-live systemd[991]: selinux: avc: denied { start } for auid=n/a uid=978 gid=976 path="/usr/lib/systemd/user/dbus-broker.service" cmdline="/usr/libexec/gnome-session-binary --autostart /usr/share/gdm/greeter/autostart --session gnome-initial-setup" scontext=system_u:system_r:xdm_t:s0-s0:c0.c1023 tcontext=system_u:object_r:systemd_unit_file_t:s0 tclass=service permissive=0 Aug 28 14:42:18 localhost-live systemd[991]: selinux: avc: denied { start } for auid=n/a uid=978 gid=976 path="/usr/lib/systemd/user/gnome-session-wayland@.target" cmdline="/usr/libexec/gnome-session-binary --autostart /usr/share/gdm/greeter/autostart --session gnome-initial-setup" scontext=system_u:system_r:xdm_t:s0-s0:c0.c1023 tcontext=system_u:object_r:systemd_unit_file_t:s0 tclass=service permissive=0 When booting in permissive mode, only the first of those appears (I think the other two are related to some kind of fallback path triggered by the first denial). Proposing as a Beta blocker as this 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" - https://fedoraproject.org/wiki/Basic_Release_Criteria#Expected_installed_system_boot_behavior
So it seems that in enforcing mode we get this fallback from gnome-session: Aug 28 05:27:31 localhost.localdomain gnome-session-binary[879]: WARNING: Falling back to non-systemd startup procedure due to error: GDBus.Error:org.freedesktop.DBus.Error.AccessDenied: SELinux policy denies access. right after the AVC. So the 'oh no!' crash might be associated with that fallback path failing, I guess. It does not explain g-i-s also failing when booting with SELinux disabled, though.
Created attachment 1609108 [details] tarball of /var/log from tested install with three boots, first enforcing, second permissive, third selinux disabled This is a tarball of /var/log from my test install, which I booted three times: first with SELinux enforcing, second with it permissive, third with it disabled.
I filed https://bugzilla.redhat.com/show_bug.cgi?id=1746584 specifically for the SELinux denials here, as we'll need to fix those regardless.
More likely to be a gnome-session regression than anything wrong with g-i-s. (In reply to Adam Williamson from comment #0) > Proposing as a Beta blocker as this 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" - > https://fedoraproject.org/wiki/ > Basic_Release_Criteria#Expected_installed_system_boot_behavior Regardless, +1 blocker
What version of g-i-s is this with ?
Should be gnome-initial-setup-3.33.91-1.fc31 . I see 3.33.92 got built for Rawhide today, but I don't think it's been in a compose yet. It does occur to me to wonder if this may be more fallout from the systemd session bugs? I guess I'll do some tests of a scratch build of systemd today and see if it helps with this.
OK, some observations: So, with the AVC warning, the gnome-initial-setup desktop file is not found. This means that the autostart directory information that GDM should be passing is missing. Likely due to https://gitlab.gnome.org/GNOME/gnome-session/commit/e6a94c3153d1bcac7aefa9f7398c5c9290f8f8c2 Also, without SELinux the gnome-initial-setup services are not started, simply because I messed up the installation of those. In g-s-d I later updated it so that they would install .wants symlinks, but I forgot to update the gnome-initial-setup merge request for that. The effect is that the services need to be enabled manually currently (i.e. "systemctl --user enable gnome-initial-setup.service gnome-initial-setup-first-login.service gnome-initial-setup-copy-worker.service gnome-welcome-tour.service" should fix this). And, it seems I also forgot to add the "X-GNOME-HiddenUnderSystemd=" into gnome-initial-setup.desktop, meaning with systemd we should theoretically be starting the service twice. But, it is never started because of the combination of errors. What I can't explain is the difference with regard to the fail-whale (the "oh no!" screen).
This should work completely fine even with the SELinux denials. So fixing those is not necessarily a priority.
Discussed during the 2019-09-03 blocker review meeting: [1] The decision to classify this bug as an "AcceptedBlocker" was made as it violates the following criteria: "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] https://meetbot.fedoraproject.org/fedora-blocker-review/2019-09-03/f31-blocker-review.2019-09-03-16.01.txt
There are two upstream patches to fix this issue: * gnome-initial-setup: https://gitlab.gnome.org/GNOME/gnome-initial-setup/merge_requests/58 * gdm: https://gitlab.gnome.org/GNOME/gdm/merge_requests/82 I have verified this and everything seems to be functional once these patches are applied.
FEDORA-2019-422f1b7c22 has been submitted as an update to Fedora 31. https://bodhi.fedoraproject.org/updates/FEDORA-2019-422f1b7c22
gdm-3.33.90-4.fc31, gnome-initial-setup-3.33.92-2.fc31 has been pushed to the Fedora 31 stable repository. If problems still persist, please make note of it in this bug report.
Tested with Fedora-Workstation-Live-x86_64-31-20190905.n.0.iso and g-i-s now works. Thanks everyone.