Bug 1746563

Summary: g-i-s fails to run after Workstation and Silverblue installs, even with SELinux permissive or disabled
Product: [Fedora] Fedora Reporter: Adam Williamson <awilliam>
Component: gnome-initial-setupAssignee: Benjamin Berg <bberg>
Status: CLOSED ERRATA QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: urgent Docs Contact:
Priority: unspecified    
Version: 31CC: alciregi, bberg, bjarvis, ed.greshko, fzatlouk, gmarr, gnome-sig, jstpierr, kparal, mcatanzaro, mclasen, robatino, rstrode, satellitgo, tiagomatos, tpopela
Target Milestone: ---Keywords: Reopened
Target Release: ---   
Hardware: x86_64   
OS: Linux   
Whiteboard: openqa AcceptedBlocker
Fixed In Version: gnome-initial-setup-3.33.92-2.fc31 Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2019-09-05 13:12:07 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Bug Depends On:    
Bug Blocks: 1644937    
Attachments:
Description Flags
tarball of /var/log from tested install with three boots, first enforcing, second permissive, third selinux disabled none

Description Adam Williamson 2019-08-28 18:58:41 UTC
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

Comment 1 Adam Williamson 2019-08-28 19:06:39 UTC
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.

Comment 2 Adam Williamson 2019-08-28 19:11:59 UTC
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.

Comment 3 Adam Williamson 2019-08-28 20:53:48 UTC
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.

Comment 4 Michael Catanzaro 2019-08-30 19:40:01 UTC
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

Comment 5 Matthias Clasen 2019-09-03 16:52:16 UTC
What version of g-i-s is this with ?

Comment 6 Adam Williamson 2019-09-03 17:09:31 UTC
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.

Comment 7 Benjamin Berg 2019-09-03 17:49:52 UTC
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).

Comment 8 Benjamin Berg 2019-09-03 17:56:29 UTC
This should work completely fine even with the SELinux denials. So fixing those is not necessarily a priority.

Comment 9 Geoffrey Marr 2019-09-03 21:07:17 UTC
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

Comment 10 Benjamin Berg 2019-09-04 14:32:13 UTC
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.

Comment 11 Fedora Update System 2019-09-04 15:19:29 UTC
FEDORA-2019-422f1b7c22 has been submitted as an update to Fedora 31. https://bodhi.fedoraproject.org/updates/FEDORA-2019-422f1b7c22

Comment 12 Fedora Update System 2019-09-04 20:54:47 UTC
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.

Comment 13 Kamil Páral 2019-09-05 13:12:07 UTC
Tested with Fedora-Workstation-Live-x86_64-31-20190905.n.0.iso and g-i-s now works. Thanks everyone.