Am 26.07.2018 um 22:38 schrieb Lisandro Damián Nicanor Pérez Meyer:
It should not. The kernel now takes more time to get the necessary
entropy (actually before it was giving random values when it shouldn't).
A workaround is to install haveged, but beware that some people don't
trust it
Hi Holger!
El jue., 26 de jul. de 2018 13:18, Holger Schröder
escribió:
> This is not really fixed in linux-image-4.17.0-1-amd64.
>
> I'm still having a little delay with 4.17.8-1
It should not. The kernel now takes more time to get the necessary entropy
(actually before it was giving random
This is not really fixed in linux-image-4.17.0-1-amd64.
I'm still having a little delay with 4.17.8-1.
Holger...
On Mon, 7 May 2018 06:40:36 +0200 "Sten Heinze" wrote:> I definitely experience a much
shorter delay if I press keys on the keyboard vs. doing nothing; the delay decreases from >5 minutes
to 10-20 seconds before sddm appears.
Yes! I have same problem, thought not with 4.16, but with 4.17. If
Meanwhile my Debian Testing systems have (per default) upgraded to libbsd
0.9.1 (and kernel 4.16.0-2). Unfortunaetly, this does not fix the problem
(long ssdm start) under virtualization by kvm, although according to #898088
libvirt 0.9.0-1 should have alredy fixed this.
On productive bare metal
Am 20.05.2018 um 16:30 schrieb Ben Hutchings:
On Thu, 2018-05-17 at 18:22 +0200, Holger Schröder wrote:
Any news to fix this behavior?
Greetings...
The bug causing (at least some) problems with starting GUIs is #898088;
that's not a kernel bug.
Ben.
Hi.
Any News? For me is this not
Am 20.05.2018 um 16:30 schrieb Ben Hutchings:
On Thu, 2018-05-17 at 18:22 +0200, Holger Schröder wrote:
Any news to fix this behavior?
Greetings...
The bug causing (at least some) problems with starting GUIs is #898088;
that's not a kernel bug.
Ben.
The Patch from #898088 for me not
On Thu, 2018-05-17 at 18:22 +0200, Holger Schröder wrote:
> Any news to fix this behavior?
>
>
> Greetings...
The bug causing (at least some) problems with starting GUIs is #898088;
that's not a kernel bug.
Ben.
--
Ben Hutchings
Horngren's Observation:
Among economists, the
Any news to fix this behavior?
Greetings...
My workarounds for this at the moment are to install tools that increase
the kernel entropy pool.
If not a virtual machine, and `grep -i -o -m 1 rdrand /proc/cpuinfo`
returns 'rdrand', then I install the 'rng-tools5' package which uses the
hardware rng in many cpu's to provide entropy to the
I can reproduce the described delay behavior on a virtualized installation
of testing using kvm after installing kernel 4.16.0-1-amd64. With
4.15.0-3-amd64 no problem.
Chris
Hi Stuart,
I definitely experience a much shorter delay if I press keys on the keyboard
vs. doing nothing; the delay decreases from >5 minutes to 10-20 seconds before
sddm appears.
Sten
Hi Stuart,
I guess it is related, just moving the mouse will indeed bypass the
"freeze", but there is always some delay (4-5 sec) in which the desktop
will wait. And it does happen on SSD-only laptops: a Bay Trail (Celeron)
and a Ivy Bridge (i3), but not on a Pineview (Atom), this last one has a
I'm seeing this on a few laptops with SSD's.
The behaviour is that if the device isn't interacted with in any way, the
machines hang for 2-4 mins at boot.
Seems to be related to the fix for CVE-2018-1108 - random: fix crng_ready()
test
https://security-tracker.debian.org/tracker/CVE-2018-1108
Package: src:linux
Version: 4.16.5-1
Followup-For: Bug #898021
Dear Maintainer,
I also seem to have this issue. After upgrading my kernel to
linux-image-4.16.0-1-amd64,
the graphical login screen (sddm) either is not shown or only shown after a
delay
(>10s after I complete the text mode
Package: src:linux
Version: 4.16.5-1
Severity: important
Dear Maintainer,
kernel 4.16 on debian testing is causing an infinite wait after the FIRST
display manager authentication.
clicking the mouse buttons alternately L-R-L-R sometimes ceases it. subsequent
authentications are good. rebooting
16 matches
Mail list logo
