This service will be undergoing maintenance at 00:00 UTC, 2016-08-01. It is expected to last about 1 hours
Bug 880761 - GDM extremely slow to load
GDM extremely slow to load
Status: CLOSED CURRENTRELEASE
Product: Fedora
Classification: Fedora
Component: selinux-policy (Show other bugs)
18
Unspecified Unspecified
unspecified Severity high
: ---
: ---
Assigned To: Miroslav Grepl
Fedora Extras Quality Assurance
:
Depends On:
Blocks: F18Blocker/F18FinalBlocker
  Show dependency treegraph
 
Reported: 2012-11-27 13:43 EST by Brandon
Modified: 2012-12-06 23:32 EST (History)
10 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2012-12-06 23:32:50 EST
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)
/var/log/audit/audit.log (329.44 KB, text/plain)
2012-11-27 13:43 EST, Brandon
no flags Details
New denied message (4.27 KB, text/plain)
2012-11-28 06:57 EST, leigh scott
no flags Details

  None (edit)
Description Brandon 2012-11-27 13:43:03 EST
Created attachment 653015 [details]
/var/log/audit/audit.log

Description of problem: Fresh install of fedora 18, with all updates.


Version- 3.6


How reproducible:100%


Steps to Reproduce:
boot the computer, takes about 30 seconds or more just to load gdm.

There's a thread on it here and it appears others have the same issue, appears to be something to do with SElinux: http://forums.fedoraforum.org/showthread.php?t=286100

I've attatched my /var/log/audit/audit.log as suggested by adamw
Comment 1 Brandon 2012-11-27 17:26:41 EST
Setting SElinux to permissive or disabled appears to remove the delay on my system
Comment 2 Adam Williamson 2012-11-27 21:26:58 EST
There's a few people reporting this in a forum thread:

http://forums.fedoraforum.org/showthread.php?t=286100

The initial reporter, mdfed, attached various logs but not audit.log to this post:

http://forums.fedoraforum.org/showpost.php?p=1615711&postcount=3

he was advised to turn off selinux and reported "setting selinux to permissive solved my problem. no more gdm errors in the logfiles."

nonamedotc said "I have also been seeing this for a while. Thanks yellowman!", implying he also resolved the issue by setting selinux to permissive.

yellowman, who advised the others to set selinux permissive, posted an extract from his audit.log at http://forums.fedoraforum.org/showpost.php?p=1615977&postcount=9 .

screamin_jesus is the reporter of this bug.

So we have four people who see slow GDM loading resolved by setting selinux to permissive in 18. Dan, Miroslav, Ray, can you look at this? Thanks! Proposing as Final blocker in case this turns out to be a widespread issue, it arguably hits "Following on from the previous criterion, after firstboot is completed and on subsequent boots, a system installed according to any of the above criteria (or the appropriate Beta or Final criteria, when applying this criterion to those releases) must boot to a working graphical environment without unintended user intervention. This includes correctly accessing any encrypted partitions when the correct passphrase is supplied" (Alpha) in the context of a Final release.
Comment 3 leigh scott 2012-11-28 04:37:24 EST
(In reply to comment #2)

> nonamedotc said "I have also been seeing this for a while. Thanks
> yellowman!", implying he also resolved the issue by setting selinux to
> permissive.
> 
> yellowman, who advised the others to set selinux permissive, posted an
> extract from his audit.log at
> http://forums.fedoraforum.org/showpost.php?p=1615977&postcount=9 .

Hi Adam, sorry I couldn't generate the log report  before

https://bugzilla.redhat.com/show_bug.cgi?id=880953


Leigh (aka yellowman)
Comment 4 Miroslav Grepl 2012-11-28 04:40:16 EST
Could you execute after login in permissive mode

# ausearch -m user_avc


I am just installing a new F18 virtual machine to see where the problem is.
Comment 5 Adam Williamson 2012-11-28 04:46:58 EST
leigh: oh that's you? I never catch nick changes!
Comment 6 leigh scott 2012-11-28 05:03:11 EST
(In reply to comment #4)
> Could you execute after login in permissive mode
> 
> # ausearch -m user_avc
> 
> 
> I am just installing a new F18 virtual machine to see where the problem is.

I've only seen the issue on bare metal and haven't managed to reproduce in vbox.
Comment 7 Adam Williamson 2012-11-28 05:42:29 EST
I haven't seen this myself in any of my F18 testing (lots of VM testing, some metal testing on my desktop). So it's clearly hardware/config dependent in _some_ way. But equally, it's affecting several people.
Comment 8 leigh scott 2012-11-28 06:03:48 EST
(In reply to comment #7)
> I haven't seen this myself in any of my F18 testing (lots of VM testing,
> some metal testing on my desktop). So it's clearly hardware/config dependent
> in _some_ way. But equally, it's affecting several people.

I'm using a nvidia GT450 with 304.64 driver and gigabyte mobo with 1055t proc
Comment 9 Miroslav Grepl 2012-11-28 06:34:56 EST
You are right. I don't see it in on my virtual machine.
Comment 10 Miroslav Grepl 2012-11-28 06:44:17 EST
Leigh,
if you add a local policy module

# grep execmem /var/log/audit/audit.log |audit2allow -M mypol
# semodule -i mypol.pp

Does it fix the issue?
Comment 11 leigh scott 2012-11-28 06:57:09 EST
Created attachment 653460 [details]
New denied message

(In reply to comment #10)
> Leigh,
> if you add a local policy module
> 
> # grep execmem /var/log/audit/audit.log |audit2allow -M mypol
> # semodule -i mypol.pp
> 
> Does it fix the issue?

It fixes the first error but has exposed this.
Comment 12 Miroslav Grepl 2012-11-28 07:14:47 EST
Ok, so you see the same behaviour with the local policy in enforcing mode and you get this user_avc?
Comment 13 leigh scott 2012-11-28 07:59:19 EST
(In reply to comment #12)
> Ok, so you see the same behaviour with the local policy in enforcing mode
> and you get this user_avc?

Yes I get a similar 20-30 second delay.
Comment 14 Miroslav Grepl 2012-11-28 08:16:16 EST
ok, just curious about

# grep init_t /var/log/audit/audit.log |audit2allow -M mynewpol
# semodule -i mynewpol.pp
Comment 15 leigh scott 2012-11-28 08:27:08 EST
(In reply to comment #14)
> ok, just curious about
> 
> # grep init_t /var/log/audit/audit.log |audit2allow -M mynewpol
> # semodule -i mynewpol.pp

Running the above command fixes the delay.
Comment 16 Miroslav Grepl 2012-11-28 08:34:46 EST
Great. Thank you for your testing.
Comment 17 Miroslav Grepl 2012-11-28 08:53:40 EST
Fixed in selinux-policy-3.11.1-57.fc18
Comment 18 Fedora Update System 2012-11-28 15:59:10 EST
selinux-policy-3.11.1-57.fc18 has been submitted as an update for Fedora 18.
https://admin.fedoraproject.org/updates/selinux-policy-3.11.1-57.fc18
Comment 19 leigh scott 2012-11-28 16:34:22 EST
(In reply to comment #16)
> Great. Thank you for your testing.

Thank you for fixing the second issue, the plymouth one is still present.

https://bugzilla.redhat.com/show_bug.cgi?id=880953
Comment 20 Fedora Update System 2012-11-30 01:37:44 EST
Package selinux-policy-3.11.1-57.fc18:
* should fix your issue,
* was pushed to the Fedora 18 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing selinux-policy-3.11.1-57.fc18'
as soon as you are able to.
Please go to the following url:
https://admin.fedoraproject.org/updates/FEDORA-2012-19374/selinux-policy-3.11.1-57.fc18
then log in and leave karma (feedback).
Comment 21 Tim Flink 2012-11-30 15:16:27 EST
It sounds like this has been fixed, could someone affected by this bug test the fix from c#20 and comment on the results of testing?
Comment 22 leigh scott 2012-11-30 15:30:47 EST
(In reply to comment #21)
> It sounds like this has been fixed, could someone affected by this bug test
> the fix from c#20 and comment on the results of testing?

It fixes the original issue here.
Comment 23 Fedora Update System 2012-12-02 14:31:44 EST
Package selinux-policy-3.11.1-59.fc18:
* should fix your issue,
* was pushed to the Fedora 18 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing selinux-policy-3.11.1-59.fc18'
as soon as you are able to.
Please go to the following url:
https://admin.fedoraproject.org/updates/FEDORA-2012-19374/selinux-policy-3.11.1-59.fc18
then log in and leave karma (feedback).
Comment 24 Tim Flink 2012-12-04 16:56:12 EST
It sounds like the issue has been fixed with the update from c#23 based on the report in c#22 and no new reports for a while.

Moving to VERIFIED
Comment 25 Fedora Update System 2012-12-06 23:32:52 EST
selinux-policy-3.11.1-60.fc18 has been pushed to the Fedora 18 stable repository.  If problems still persist, please make note of it in this bug report.

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