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-setup | Assignee: | Benjamin Berg <bberg> | ||||
| Status: | CLOSED ERRATA | QA Contact: | Fedora Extras Quality Assurance <extras-qa> | ||||
| Severity: | urgent | Docs Contact: | |||||
| Priority: | unspecified | ||||||
| Version: | 31 | CC: | alciregi, bberg, bjarvis, ed.greshko, fzatlouk, gmarr, gnome-sig, jstpierr, kparal, mcatanzaro+wrong-account-do-not-cc, 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: | |||||
| Embargoed: | |||||||
| Bug Depends On: | |||||||
| Bug Blocks: | 1644937 | ||||||
| Attachments: |
|
||||||
|
Description
Adam Williamson
2019-08-28 18:58:41 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. 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. |