# [Solved]Kernel 4.12.12 to 4.14.52: slow  login: lost entropy

## eccerr0r

When i upgraded my HP Envy laptop from kernel-4.12.12-gentoo to kernel-4.14.52-gentoo, I got the dreaded slow login.  I thought it was network timing but I think I figured it is now lack of entropy.

Note the ~5 second delay on this boot before crng init is done in this dmesg trace:

```
[    5.627205] virbr0: port 1(virbr0-nic) entered blocking state

[    5.627253] virbr0: port 1(virbr0-nic) entered listening state

[    5.664072] virbr0: port 1(virbr0-nic) entered disabled state

[   10.535418] random: crng init done

[   11.059978] iwlwifi 0000:02:00.0: Radio type=0x2-0x0-0x0

[   11.328746] iwlwifi 0000:02:00.0: Radio type=0x2-0x0-0x0
```

Without intervention, it can be a long wait until login completes...  I think wifi as a source of entropy will eventually let it finish starting, which can take several minutes!

I was able to work around this problem as apparently it's the same problem documented in https://forums.gentoo.org/viewtopic-t-1083242-highlight-entropy.html ... but this time it's gdm / systemd / logind that's affected.  gdm takes forever to come up.  I tried disabling gdm and noticed even logind takes a while.

The workaround of moving my mouse is at odds with my other problem: touching my touchpad during boot can cause it to be completely useless until the next reboot!

(My other upgraded machine to 4.14.52 does not exhibit either the touchpad or entropy issue.  Also reverting back to 4.12.12 makes the problem go away...)

As this appears to be a kernel regression, anyone seen something that can be done in kernel to help remedy this?

----------

## ct85711

You may want to check this thread (last 5 messages), as it gives you some places to check to see if entropy is low/out and what you could do to remedy it.

https://forums.gentoo.org/viewtopic-t-1080832-highlight-entropy.html

As far as kernel options, I don't know of anything right off hand; maybe check the diff between the 2 kernel configs?  Maybe one of the config options got renamed and not turned back on, but if we can find the old name we can search in the new kernel for similar keywords.

----------

## krinn

See if this help (i just pickup "random" keyword for obvious reason, but i don't know which option you may lack that does this):

my kernel is one from kernel.org

```
grep -i random /usr/src/linux/.config

# CONFIG_SLAB_FREELIST_RANDOM is not set

CONFIG_ARCH_HAS_ELF_RANDOMIZE=y

CONFIG_ARCH_RANDOM=y

# CONFIG_RANDOMIZE_BASE is not set

CONFIG_HW_RANDOM=m

CONFIG_HW_RANDOM_TIMERIOMEM=m

CONFIG_HW_RANDOM_INTEL=m

CONFIG_HW_RANDOM_AMD=m

CONFIG_HW_RANDOM_VIA=m

CONFIG_HW_RANDOM_TPM=m

# CONFIG_DRM_LIB_RANDOM is not set

# CONFIG_WARN_ALL_UNSEEDED_RANDOM is not set

# Random Number Generation

# CONFIG_RANDOM32_SELFTEST is not set

```

```
dmesg | grep random -i

[    0.426881] random: fast init done

[    0.429907] random: get_random_bytes called from init_oops_id+0x2f/0x40 with crng_init=1

[    1.396988] random: crng init done

```

```
uname -a

Linux beleg 4.14.53 #1 SMP PREEMPT Thu Jul 5 14:07:26 CEST 2018 x86_64 Intel(R) Core(TM) i7-4790K CPU @ 4.00GHz GenuineIntel GNU/Linux

```

----------

## eccerr0r

The kernel /dev/random has been around for years with its entropy sources, I don't know with years of improvements of adding entropy sources why suddenly it went down.  As it's a somewhat minor change from 4.12 to 4.14, why it ended up causing a significant behavior change seems unusual.  Also it's only one machine: again I have another machine using the same kernel version that doesn't have this issue albeit it's 32-bit.

I wanted to avoid using sys-apps/haveged - it seems kind of weird that a kernel random number generator resorts to needing userspace to maintain entropy (security!)

Likewise I didn't see any obvious diff changes between the two .configs, at least searching for RANDOM.   CONFIG_WARN_ALL_UNSEEDED_RANDOM stuck out - but it seemed only like a reporting config that doesn't actually change behavior.

----------

## tholin

You seem to be running into the problems with CVE-2018-1108. Basically Google project zero discovered that the seeding of the random pool was broken. It would feed lots of static data into the pool and increase the entropy count even though that static data is the same every boot. That made is seem like there are more entropy available than there really is.

https://bugs.chromium.org/p/project-zero/issues/detail?id=1559

The fix went into 4.17 and was backported to v4.14.36. Since the entropy accounting now show less entropy, services that requires random data during boot might stall.

https://github.com/torvalds/linux/commit/dc12baacb95f205948f64dc936a47d89ee110117

 *eccerr0r wrote:*   

> As this appears to be a kernel regression, anyone seen something that can be done in kernel to help remedy this?

 

There's simply not enough entropy available. The answer from the kernel developer responsible is:

"Again, I think the right answer is to fix userspace to not require cryptographic grade entropy during early system startup, and for people to *think* about what they are doing."

https://patchwork.kernel.org/patch/10374663/

If you google for the problem there is a lot of distribution maintainers who are scratching their heads trying to figure out what to do about the situation. 

Saving some entropy on shutdown and reloading it at boot is one solution. /etc/init.d/urandom tries to do that but afaik it only seeds the pool without increasing the entropy so it doesn't help with the stalls. Use of sys-apps/haveged might also work but it sounds like you already tried that.

 *eccerr0r wrote:*   

> Also reverting back to 4.12.12 makes the problem go away...)

 

That kernel is long out of support and works because it never got the fix for CVE-2018-1108.

----------

## eccerr0r

Thanks, this explains things.  Sort of goes against Linus' ideal of "Don't Break Userspace" but oh well ... :)

----------

## vespaman

So during my (super warm) vacation, I set out to update my old laptop (Thinkpad X200s), and ended up with the same boot delay. Kernel 4.14.52.

Seeing as the subject is marked as solved, how did  you actually solve this issue in your setup? Change to the older kernel, or just accepting it, or something else?

I'm hoping for "something else"  :Wink: 

----------

## eccerr0r

It seems like the expected kernel solution is wait for new release of desktop environment.

The workarounds:

1. Install sys-apps/haveged and make sure it runs during boot.

This will software-increase entropy which I don't quite see how it really does, but so be it.

or 

2. Shake mouse or mash head in keyboard until it unfreezes.

This will generate entropy which will eventually allow normal boot.  This is preferred for now because this is real entropy.

----------

## vespaman

OK, thanks for the different solutions! 

I'll do the shaking for now. Maybe I'll get used to it. Head mashing sounds too brutal for my delicate head   :Very Happy: 

----------

