Note: This is a public test instance of Red Hat Bugzilla. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback at bugzilla.redhat.com.
Bug 1746563 - g-i-s fails to run after Workstation and Silverblue installs, even with SELinux permissive or disabled
Summary: g-i-s fails to run after Workstation and Silverblue installs, even with SELin...
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: gnome-initial-setup
Version: 31
Hardware: x86_64
OS: Linux
unspecified
urgent
Target Milestone: ---
Assignee: Benjamin Berg
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard: openqa AcceptedBlocker
Depends On:
Blocks: F31BetaBlocker
TreeView+ depends on / blocked
 
Reported: 2019-08-28 18:58 UTC by Adam Williamson
Modified: 2019-09-05 13:12 UTC (History)
16 users (show)

Fixed In Version: gnome-initial-setup-3.33.92-2.fc31
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2019-09-05 13:12:07 UTC
Type: Bug
Embargoed:

Attachments (Terms of Use)
tarball of /var/log from tested install with three boots, first enforcing, second permissive, third selinux disabled (1.89 MB, application/gzip)
2019-08-28 19:11 UTC, Adam Williamson 		no flags Details
View All

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.
Note You need to log in before you can comment on or make changes to this bug.