Bug 1744352 - gnome-initial-setup does not run after install of Fedora-31-20190820.n.4
Summary: gnome-initial-setup does not run after install of Fedora-31-20190820.n.4
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: selinux-policy
Version: rawhide
Hardware: All
OS: Linux
unspecified
urgent
Target Milestone: ---
Assignee: Lukas Vrabec
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard: openqa
Depends On:
Blocks: F31BetaBlocker
TreeView+ depends on / blocked
 
Reported: 2019-08-21 22:02 UTC by Adam Williamson
Modified: 2019-08-26 17:05 UTC (History)
7 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2019-08-26 02:06:18 UTC
Type: Bug
Embargoed:


Attachments (Terms of Use)

Description Adam Williamson 2019-08-21 22:02:46 UTC
After install of Fedora-31-20190820.n.4 - either Workstation live or Silverblue installer - gnome-initial-setup does not run; instead you just get a blinking cursor at top left.

At least with the Workstation live, booting with enforcing=0 seems to help, and the following AVCs are shown in the logs:

Aug 21 14:54:19 localhost-live systemd[997]: selinux: avc:  denied  { start } for auid=n/a uid=979 gid=977 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=1
Aug 21 14:54:22 localhost-live audit[1268]: AVC avc:  denied  { mount } for  pid=1268 comm="fusermount3" name="/" dev="fuse" ino=1 scontext=system_u:system_r:xdm_t:s0-s0:c0.c1023 tcontext=system_u:object_r:fusefs_t:s0 tclass=filesystem permissive=1
Aug 21 14:54:26 localhost-live audit[813]: USER_AVC pid=813 uid=81 auid=4294967295 ses=4294967295 subj=system_u:system_r:system_dbusd_t:s0-s0:c0.c1023 msg='avc:  denied  { send_msg } for  scontext=system_u:system_r:xdm_t:s0-s0:c0.c1023 tcontext=system_u:system_r:avahi_t:s0 tclass=dbus permissive=1
Aug 21 14:54:26 localhost-live audit[813]: USER_AVC pid=813 uid=81 auid=4294967295 ses=4294967295 subj=system_u:system_r:system_dbusd_t:s0-s0:c0.c1023 msg='avc:  denied  { send_msg } for  scontext=system_u:system_r:avahi_t:s0 tcontext=system_u:system_r:xdm_t:s0-s0:c0.c1023 tclass=dbus permissive=1
Aug 21 14:54:35 localhost-live audit[1]: USER_AVC pid=1 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0 msg='avc:  denied  { status } for auid=n/a uid=0 gid=0 cmdline="/usr/sbin/timedatex" scontext=system_u:system_r:timedatex_t:s0 tcontext=system_u:system_r:init_t:s0 tclass=system permissive=1
Aug 21 14:54:35 localhost-live audit[1]: USER_AVC pid=1 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0 msg='avc:  denied  { status } for auid=n/a uid=0 gid=0 path="/usr/lib/systemd/system/systemd-timesyncd.service" cmdline="/usr/sbin/timedatex" scontext=system_u:system_r:timedatex_t:s0 tcontext=system_u:object_r:systemd_timedated_unit_file_t:s0 tclass=service permissive=1
Aug 21 14:54:35 localhost-live audit[1]: USER_AVC pid=1 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0 msg='avc:  denied  { status } for auid=n/a uid=0 gid=0 path="/usr/lib/systemd/system/chronyd.service" cmdline="/usr/sbin/timedatex" scontext=system_u:system_r:timedatex_t:s0 tcontext=system_u:object_r:chronyd_unit_file_t:s0 tclass=service permissive=1
Aug 21 14:54:35 localhost-live audit[813]: USER_AVC pid=813 uid=81 auid=4294967295 ses=4294967295 subj=system_u:system_r:system_dbusd_t:s0-s0:c0.c1023 msg='avc:  denied  { send_msg } for  scontext=system_u:system_r:xdm_t:s0-s0:c0.c1023 tcontext=system_u:system_r:timedatex_t:s0 tclass=dbus permissive=1

there's some more timedatex stuff in there, but also some dbus stuff. This is with selinux-policy-targeted-3.14.4-31.fc31 , so should already have the known timedatex fixes.

For the Silverblue case booting with enforcing=0 didn't actually seem to fix the problem at least the first time I tried it, but not sure why not yet...

Comment 1 Adam Williamson 2019-08-21 22:03:47 UTC
This violates 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."

Comment 2 Adam Williamson 2019-08-26 02:06:18 UTC
This seems to be fixed since Fedora-31-20190823.n.0 . Not sure what fixed it, but...it's working.

Comment 3 Lukas Vrabec 2019-08-26 17:05:10 UTC
Magic! 

Adam, 
I keep selinux-policy bugs for F31 on my radar to fix all possible blocker ASAP.

Thanks,
Lukas.


Note You need to log in before you can comment on or make changes to this bug.