Login screen not showing till you hold any key

plymouth
update
deepin
lightdm

#23

Hi guys, it seems we have similar if not same problem (manmio linked topic I started about stuck boot).

I found this in Arch wiki https://wiki.archlinux.org/index.php/Random_number_generation
There is mentioned about thing I noticed ( random: crng init takes a while) and it says this happens when system entropy pool is exhausted so kernel waits to gather enough entropy.
Thats why it unstuck itself when key is pressed, because it adds some entropy, so random init and boot can finish.
If that is the issue, than something in boot process is exhausting entropy pool.
I see a lot of

[    2.024934] random: systemd: uninitialized urandom read (16 bytes read)
[    2.025203] random: systemd: uninitialized urandom read (16 bytes read)
[    2.025454] random: systemd: uninitialized urandom read (16 bytes read)
[    2.028034] random: systemd: uninitialized urandom read (16 bytes read)
[    2.028717] random: systemd: uninitialized urandom read (16 bytes read)
[    2.031700] random: systemd: uninitialized urandom read (16 bytes read)
[    2.032543] random: systemd: uninitialized urandom read (16 bytes read)
[    2.032596] random: systemd: uninitialized urandom read (16 bytes read)
[    2.032689] random: systemd: uninitialized urandom read (16 bytes read)
[    2.032772] random: systemd: uninitialized urandom read (16 bytes read)

in boot process, so it seems systemd or some service is repeatedly requesting urandom and thus exhausting entropy pool.
But I haven’t found what exactly is causing problem :frowning:


#24

Boot is stuck in blank screen until some key is pressed or touchpad is touched.
Looking into dmesg or journal I see big pause and than

random: crng init done

dmesg:

[    7.360173] IPv6: ADDRCONF(NETDEV_UP): wlo1: link is not ready
[   10.628736] wlo1: authenticate with 20:25:64:75:f8:2e
[   10.688881] wlo1: send auth to 20:25:64:75:f8:2e (try 1/3)
[   10.700284] wlo1: authenticated
[   10.701091] wlo1: associate with 20:25:64:75:f8:2e (try 1/3)
[   10.704890] wlo1: RX AssocResp from 20:25:64:75:f8:2e (capab=0x1411 status=0 aid=1)
[   10.711128] wlo1: associated
[   10.756684] IPv6: ADDRCONF(NETDEV_CHANGE): wlo1: link becomes ready
[   32.573399] random: crng init done
[   33.045738] fuse init (API version 7.26)

journalctl:

Apr 29 13:24:24 vuk-pc systemd[1]: Starting Network Manager Script Dispatcher Service...                                                                                                                                            
Apr 29 13:24:24 vuk-pc dbus-daemon[348]: [system] Successfully activated service 'org.freedesktop.nm_dispatcher'                                                                                                                    
Apr 29 13:24:24 vuk-pc systemd[1]: Started Network Manager Script Dispatcher Service.                                                                                                                                               
Apr 29 13:24:24 vuk-pc nm-dispatcher[649]: req:1 'up' [wlo1]: new request (0 scripts)                                                                                                                                               
Apr 29 13:24:24 vuk-pc nm-dispatcher[649]: req:1 'up' [wlo1]: completed: no scripts                                                                                                                                                 
Apr 29 13:24:25 vuk-pc NetworkManager[350]: <info>  [1525001065.5361] manager: NetworkManager state is now CONNECTED_GLOBAL                                                                                                         
Apr 29 13:24:25 vuk-pc nm-dispatcher[649]: req:2 'connectivity-change': new request (0 scripts)                                                                                                                                     
Apr 29 13:24:25 vuk-pc nm-dispatcher[649]: req:2 'connectivity-change': completed: no scripts                                                                                                                                       
Apr 29 13:24:42 vuk-pc kernel: random: crng init done                                                                                                                                                                               
Apr 29 13:24:42 vuk-pc systemd[621]: Started D-Bus User Message Bus.                                                                                                                                                                
Apr 29 13:24:42 vuk-pc systemd-timesyncd[331]: Synchronized to time server 195.178.58.245:123 (2.manjaro.pool.ntp.org).                                                                                                             
Apr 29 13:24:42 vuk-pc dbus-daemon[663]: [session uid=1000 pid=663] Activating service name='org.xfce.Xfconf' requested by ':1.3' (uid=1000 pid=671 comm="xfce4-session ")                                                          
Apr 29 13:24:42 vuk-pc dbus-daemon[663]: [session uid=1000 pid=663] Successfully activated service 'org.xfce.Xfconf'  

Seems random init is waiting some input.
I’m on Manjaro stable, linux 4.16.


#25

Hello wooque,
I assume in this post we are discussing the same problem.
But until now, we did not have a solution:


#26

@jonathon

  • Not a kernel issue
  • Duplicate

#27

On my Haswell laptop those kernels work normally (not need moving mouse to reach login dialog):
4.15.18
4.4.130

But those not (need move mouse to reach login dialog):
4.17
4.16.5
4.14.37

Laptop is Lenovo Yoga 2 Pro with Intel i7-4510u and it running currrently Manjaro Deepin (unstable)


#28

Try installing haveged:

sudo pacman -S haveged
sudo systemctl enable haveged
sudo systemctl start haveged

[SOLVED] Where can I find the iso file to download for Manjaro 17.1.6?
4.16 kernel booting to black screen
After latest upgrade can not reboot 2 Manjaro systems
[Testing Update x32] 2018-05-01 to 09 - Kernels, Keyring, Samba, Plasma
Lightdm manjaro cinnamon 17.1.9
Boot Time slow / laggy & FAILED notif in the boot text messages
KDE Startup problems
#29

@jonathon
Thanks man.
This solved my issue!


#30

Ensure this is reported to the upstream bug. If something in Deepin LightDM is exhausting the entropy pool that’s a pretty major issue.


#31

I have a similar problem in Manjaro Gnome 17.1.9 using the 4.14 LTS kernel. In kernel 4.15 or 4.16 I do not have this problem

Thanks


#33

Same problem here. Manjaro KDE + XFCE, kernel 4.16.

There is another thing: If I wait long enough (about 2 min) the login screen comes up even without pressing any key.


#34

Does the workaround I suggested not work?

This is to be expected if the entropy pool is low. Moving the mouse, typing on the keyboard, disk activity, all contribute to generating entropy.


#35

@jonathon
I’m not using Deepin, I’m using official Manjaro XFCE edition, the only difference is I upgraded kernel to 4.16


#36

Switched to kernel 4.15.18. That solved my problem. Thanks for the hint. :smiley::hugs:


#37

This kernel is EOL and not a solution.

Why didn’t you just try the workaround I posted above?


@philm Have there been any kernel config changes that could affect available entropy?


#38

Kernel 4.15 seems LTS kernel on Ubuntu 18.04 and also Manjaro devs can use this kernel as base.


#39

Solved in Manjaro Gnome 17.1.9. The start is no longer blocked until you press a key as before in kernel 4.14 LTS

Thanks


#40

I have tested workaround which @jonathon suggested, and it seems that I haven’t this problem with any kernel, when I use this workaround. But without this workaround only certain kernels work correctly as I have written earlier.


#41

That’s an installer version, not a Manjaro version. All installed and up-to-date Manjaro versions are the same.

If you’re saying that the issue is solved by a full package update, then fine.

Nope. We’re not going to track Ubuntu patches when we have perfectly good upstream LTS and mainline releases.


#42

In the last stable update, with Manjaro Gnome, I had that problem. When I enter in the terminal the orders that you listed before, the problem is solved

sudo pacman -S haveged
sudo systemctl enable haveged
sudo systemctl start haveged

thank you very much for this solution and sorry for my english of Google :wink:


#43

I don’t think it is a solution. This is how I understand the problem: Somewhere there is a bug hungry for random numbers. By using the haveged workaround you just feed it to let you pass but it’s still sitting there… Or am I missing something?