15 seconds to unlock screen?

[Mads Villadsen]

I'm running Fedora 27 and sometime during the last 3 days or so a problem has started
occurring that causes it to take 15 seconds to unlock the screen and turn on the display.
While it is unlocking the keyboard becomes unresponsive (hitting the caps lock key for
instance doesn't turn on the LED).

It also takes a significant amount of time to transition from the Fedora logo boot screen
to the login screen - and while this goes on the keyboard is also unresponsive.

I have tried various things such as using Xorg or Wayland as well as booting older kernels
but I haven't been able to figure out what is causing this.

It is happening on a Dell XPS 13.

Is anyone else seeing something similar? What can I provide to help debug the issue?

Kind regards,
Mads

[Robert-André Mauchin]

On samedi 16 septembre 2017 13:56:19 CEST Mads Villadsen wrote:
>  I'm running Fedora 27 and sometime during the last 3 days or so a
> problem
>  has started occurring that causes it to take 15 seconds to unlock the
>  screen and turn on the display. While it is unlocking the keyboard becomes
>  unresponsive (hitting the caps lock key for instance doesn't turn on the
>  LED). 
 
>  It also takes a significant amount of time to transition from the
> Fedora
>  logo boot screen to the login screen - and while this goes on the keyboard
>  is also unresponsive. 
 
>  I have tried various things such as using Xorg or Wayland as well as
> booting
>  older kernels but I haven't been able to figure out what is causing this. 
 
>  It is happening on a Dell XPS 13.
>  
>  Is anyone else seeing something similar? What can I provide to help debug
>  the issue? 
 
There is a message on Reddit regarding logging:

> I'm using Fedora 27 Alpha and for two days now I experience
> extreme "lag" 
> when I need to input my password. The "lag" happens when:
>
>     I need to log to the system first time,
>
>     I need to unlock the system,
>
>     I try sudo su (I have to wait for like 20 seconds for the password prompt 
>     to appear).
>  
https://www.reddit.com/r/Fedora/comments/70daej/
password_related_tasks_very_slow/

Are you experiencing the same issue with sudo as well?

[Adam Williamson]

On Sat, 2017-09-16 at 14:16 +0200, Robert-André Mauchin wrote:
>  On samedi 16 septembre 2017 13:56:19 CEST Mads Villadsen wrote:
>  > I'm running Fedora 27 and sometime during the last 3 days or so a problem
>  > has started occurring that causes it to take 15 seconds to unlock the
>  > screen and turn on the display. While it is unlocking the keyboard becomes
>  > unresponsive (hitting the caps lock key for instance doesn't turn on the
>  > LED).
>  
>   
>  > It also takes a significant amount of time to transition from the Fedora
>  > logo boot screen to the login screen - and while this goes on the keyboard
>  > is also unresponsive.
>  
>   
>  > I have tried various things such as using Xorg or Wayland as well as booting
>  > older kernels but I haven't been able to figure out what is causing this.
>  
>   
>  > It is happening on a Dell XPS 13.
>  > 
>  > Is anyone else seeing something similar? What can I provide to help debug
>  > the issue?
>  
>   
>  There is a message on Reddit regarding logging:
>  
>  > I'm using Fedora 27 Alpha and for two days now I experience extreme
> "lag" 
>  > when I need to input my password. The "lag" happens when:
>  > 
>  >    I need to log to the system first time,
>  > 
>  >    I need to unlock the system,
>  > 
>  >    I try sudo su (I have to wait for like 20 seconds for the password prompt 
>  >    to appear).
>  > 
>  
>  https://www.reddit.com/r/Fedora/comments/70daej/
>  password_related_tasks_very_slow/
>  
>  Are you experiencing the same issue with sudo as well? 
Seen a few similar reports of slowness related to authentication around
the place, but haven't been able to pin it down to anything yet :/

Do check if you're running a debug-enabled kernel; debugging was turned
back on again for several F27 kernel builds by accident.
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net

[Tomasz Torcz]

On Sat, Sep 16, 2017 at 07:06:38AM -0700, Adam Williamson wrote:
>  > On samedi 16 septembre 2017 13:56:19 CEST Mads Villadsen wrote:
>  > > I'm running Fedora 27 and sometime during the last 3 days or so a problem
>  > > has started occurring that causes it to take 15 seconds to unlock the
>  > > screen and turn on the display. While it is unlocking the keyboard becomes
>  > > unresponsive (hitting the caps lock key for instance doesn't turn on the
>  > > LED).
>  > 
>  >  
>  > > It also takes a significant amount of time to transition from the Fedora
>  > > logo boot screen to the login screen - and while this goes on the keyboard
>  > > is also unresponsive.
>  
>  Seen a few similar reports of slowness related to authentication around
>  the place, but haven't been able to pin it down to anything yet :/
>  
>  Do check if you're running a debug-enabled kernel; debugging was turned
>  back on again for several F27 kernel builds by accident. 
  I see the same slowness (before GDM screen appears on boot and before
password unlock dialog slides in) with 4.13.2-300.fc27.x86_64, which
is not debug.

-- 
Tomasz Torcz       ,,(...) today's high-end is tomorrow's embedded
processor.''
xmpp: zdzichubg(a)chrome.pl                      -- Mitchell Blank on LKML

[Charles-Antoine Couret]

I have the same issue.
No problem to connect with GDM, but when it's locked the bug happened.

Any Bugzilla report about this?

Charles-Antoine Couret — Renault

[Vít Ondruch]

I'd say you should try to downgrade to fprintd-0.7.0-4.fc27 as a
workaround and wait for fixed selinux-policy ...


Vít



Dne 16.9.2017 v 13:56 Mads Villadsen napsal(a):
>  I'm running Fedora 27 and sometime during the last 3 days or so a
> problem has started occurring that causes it to take 15 seconds to unlock the screen and
> turn on the display. While it is unlocking the keyboard becomes unresponsive (hitting the
> caps lock key for instance doesn't turn on the LED).
>
>  It also takes a significant amount of time to transition from the Fedora logo boot screen
> to the login screen - and while this goes on the keyboard is also unresponsive.
>
>  I have tried various things such as using Xorg or Wayland as well as booting older
> kernels but I haven't been able to figure out what is causing this.
>
>  It is happening on a Dell XPS 13.
>
>  Is anyone else seeing something similar? What can I provide to help debug the issue?
>
>  Kind regards,
>  Mads
>  _______________________________________________
>  devel mailing list -- devel(a)lists.fedoraproject.org
>  To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org

[Michael Schwendt]

On Mon, 18 Sep 2017 12:36:11 +0200, Vít Ondruch wrote:

>  I'd say you should try to downgrade to fprintd-0.7.0-4.fc27 as a
>  workaround and wait for fixed selinux-policy ... 
Right. The fprintd test update has been published before the strictly
needed selinux-policy update. Meanwhile, the latter is available, too,
so the issue should be gone.

It's all in the Fedora Updates System where more people warning about
such breakage would be helpful.

[Robert-André Mauchin]

On samedi 16 septembre 2017 13:56:19 CEST Mads Villadsen wrote:
>  I'm running Fedora 27 and sometime during the last 3 days or so a
> problem
>  has started occurring that causes it to take 15 seconds to unlock the
>  screen and turn on the display. While it is unlocking the keyboard becomes
>  unresponsive (hitting the caps lock key for instance doesn't turn on the
>  LED). 
 
>  It also takes a significant amount of time to transition from the
> Fedora
>  logo boot screen to the login screen - and while this goes on the keyboard
>  is also unresponsive. 
 
>  I have tried various things such as using Xorg or Wayland as well as
> booting
>  older kernels but I haven't been able to figure out what is causing this. 
 
>  It is happening on a Dell XPS 13.
>  
>  Is anyone else seeing something similar? What can I provide to help debug
>  the issue? 
 
>  Kind regards,
>  Mads
>  
Pinpointed the issue to this SELinux denial:

> SELinux is preventing fprintd from map access on the file
> /usr/libexec/
> fprintd.
>
> *****  Plugin catchall (100. confidence) suggests    
**************************
> If you believe that fprintd should be allowed map access on the fprintd file
> >by default.
> Then you should report this as a bug.
> You can generate a local policy module to allow this access.
> Do
> allow this access for now by executing:
> # ausearch -c 'fprintd' --raw | audit2allow -M my-fprintd
> # semodule -X 300 -i my-fprintd.pp
>
> Additional Information:
> Source Context                system_u:system_r:init_t:s0
> Target Context                system_u:object_r:fprintd_exec_t:s0
> Target Objects                /usr/libexec/fprintd [ file ]
> Source                        fprintd
> Source Path                   fprintd
> Port                          <Unknown>
> Host                          Themisto
> Source RPM Packages           
> Target RPM Packages           fprintd-0.8.0-1.fc27.x86_64
> Policy RPM                    selinux-policy-3.13.1-283.fc27.noarch
> Selinux Enabled               True
> Policy Type                   targeted
> Enforcing Mode                Enforcing
> Host Name                     Themisto
> Platform                      Linux Themisto 4.13.0-0.rc7.git0.1.fc27.x86_64
> #1
>                               SMP Mon Aug 28 02:33:21 UTC 2017 x86_64 x86_64
> Alert Count                   1
> First Seen                    2017-09-18 14:02:11 CEST
> Last Seen                     2017-09-18 14:02:11 CEST
> Local ID                      690fe676-308e-4442-a372-c279001c7ac8
>
> Raw Audit Messages
> type=AVC msg=audit(1505736131.821:219): avc:  denied  { map } for  pid=3371
> comm="fprintd" path="/usr/libexec/fprintd" dev="sda7"
> ino=1248976
> scontext=system_u:system_r:init_t:s0
> tcontext=system_u:object_r:fprintd_exec_t:s0 tclass=file permissive=0
>
>
> Hash: fprintd,init_t,fprintd_exec_t,file,map
>  
Allowing it by running the provided commands:

> # ausearch -c 'fprintd' --raw | audit2allow -M my-fprintd
> # semodule -X 300 -i my-fprintd.pp
>  
made sudo fast again

[Jared K. Smith]

On Sat, Sep 16, 2017 at 7:56 AM, Mads Villadsen <maxx(a)fedoraproject.org&gt;
wrote:

>  Is anyone else seeing something similar?
>  
I"m seeing the same thing on Rawhide.

-Jared