Your message dated Sat, 13 Oct 2018 15:25:02 +0200
with message-id <572d023bc8397dba620fac8c01309289fd895cb8.ca...@debian.org>
and subject line Re: Bug#910631: lightdm: first login hangs waiting for 
user-generated entropy
has caused the Debian Bug report #910631,
regarding lightdm: first login hangs waiting for user-generated entropy
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact ow...@bugs.debian.org
immediately.)


-- 
910631: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=910631
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---
Package: lightdm
Version: 1.26.0-3
Severity: grave
Justification: renders package unusable

Dear Maintainer,

On my buster/sid system, LightDM hangs indefinitely on first login until
entropy is generated via mouse or keyboard input.
The login process seems to be delayed by the kernel itself, until the following
lines appear in journalctl:

kernel: random: crng init done
kernel: random: 7 urandom warning(s) missed due to ratelimiting

Installing the haveged package fixes the issue, as mentioned in the following
thread:
https://unix.stackexchange.com/questions/442698/when-i-log-in-it-hangs-until-
crng-init-done

This issue also seems related to bug #897572



-- System Information:
Debian Release: buster/sid
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: amd64 (x86_64)

Kernel: Linux 4.18.0-2-amd64 (SMP w/2 CPU cores)
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), 
LANGUAGE=fr_FR.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages lightdm depends on:
ii  adduser                                3.118
ii  dbus                                   1.12.10-1
ii  debconf [debconf-2.0]                  1.5.69
ii  libaudit1                              1:2.8.4-2
ii  libc6                                  2.27-6
ii  libgcrypt20                            1.8.3-1
ii  libglib2.0-0                           2.58.1-2
ii  libpam-systemd                         239-10
ii  libpam0g                               1.1.8-3.8
ii  libxcb1                                1.13-3
ii  libxdmcp6                              1:1.1.2-3
ii  lightdm-gtk-greeter [lightdm-greeter]  2.0.5-1
ii  lsb-base                               9.20170808

Versions of packages lightdm recommends:
ii  xserver-xorg  1:7.7+19

Versions of packages lightdm suggests:
pn  accountsservice  <none>
ii  upower           0.99.8-2
pn  xserver-xephyr   <none>

-- Configuration Files:
/etc/lightdm/lightdm.conf changed [not included]

-- debconf information:
* shared/default-x-display-manager: lightdm
  lightdm/daemon_name: /usr/sbin/lightdm

--- End Message ---
--- Begin Message ---
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On Fri, 2018-10-12 at 19:32 +0200, Dr. Julius wrote:
> Manually downgrading a few hundred packages one-by-one and rebooting each
> time was not an option so here's what I did:

Sorry, I missed that this was a dist-upgrade from stretch to buster/sid.
> 
> 1. Replaced the ExecStart line in lightdm.service by:
> ExecStart=/usr/bin/strace -fty -P /dev/random -P /dev/urandom -o
> /var/log/lightdm/strace.log /usr/sbin/lightdm
> 
> 2. Using a combination of the strace log and atop, found a suspicious (long
> running) access to /dev/random by a child process of gnome-keyring-deamon
> 
> 3. Uninstalled the gnome-keyring package
> 
> 4. The issue disappeared...
> 
> So AFAICT, it seems that this issue is caused by gnome-keyring making
> blocking calls to the RNG.
> Possibly here
> <
> https://salsa.debian.org/gnome-team/gnome-keyring/blob/debian/master/pkcs11/gnome2-store/gkm-gnome2-file.c#L416

That looks completely unrelated, what you're looking for is a call to
getrandom() without the O_NONBLOCK flag.
> >
> ?
> 
> What's weird is that the gnome-keyring package was not affected by the
> dist-upgrade, so the behavior may have been triggered by a change in
> another package...

The behavior actually changed in the kernel but there have been some fallouts
in various applications.

In your case gnome-keyring is likely to have good reason to want getrandom()
to block before RNG is not correctly seeded, so if you want/need it you might
want to have something seeding it (like a TPM or haveged).

In any case, it's not something in lightdm, so I'm closing this issue.

Regards,
- -- 
Yves-Alexis
-----BEGIN PGP SIGNATURE-----

iQEzBAEBCAAdFiEE8vi34Qgfo83x35gF3rYcyPpXRFsFAlvB8i4ACgkQ3rYcyPpX
RFvqyAgAzDSEL7f1nExM+PGO7C3nAZlYdPe/7rtfgpx0sm5Yo7aAgrAbKrDuq+JW
j66gxvWM5HH5/JGWIK51buV7PSy9kZazK8XULH244vO+bvlI7j0Q+T1Qmuk/+UFX
USzLa3KWpDUvihUAuiwwyA81KlkXjW4IaNRvThwZ0xgMWYtZHuWwxNF5OkB9krnx
Xl6QHjEYr+waET7LEDvyGIYJvKTARoppEebq4npIjnJKf3IJjVrU7x6fgSHO0KQW
s432jjtmpmgTo4jq9TroIZFNlUkStSHu2FmjoPFyUO6f/LejAcE48Vbf2le5YU2Z
rG2usWYXdRlNraunxj6zIDU9u0Je3Q==
=fRJp
-----END PGP SIGNATURE-----

--- End Message ---

Reply via email to