Bug#897572: [PATCH] Copy fontconfig .uuid files to avoid getrandom hang in early boot

On 14/05/18 20:24, Laurent Bigonville wrote: I was more thinking about regenerating the cache with fc-cache in the initramfs (or using uuidgen to generate the .uuid files) instead of copying them from the live system, I'll try to figure that out. Thanks very much, Laurent. Confirmed fixed in 0

Bug#897572: [PATCH] Copy fontconfig .uuid files to avoid getrandom hang in early boot

On Thu, 10 May 2018 11:53:37 +1200 Ben Caradoc-Davies wrote: > Fixes: > Bug#897572: getrandom hang in early boot prevents plymouth passphrase entry > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=897572 > > Signed-off-by: Ben Caradoc-Davies > --- > debian/local/plymo

Bug#897572: getrandom hang in early boot prevents plymouth passphrase entry

Thanks Theo and Ben for the investigation. I can confirm that with kernel 4.16.0-1-amd64 4.16.5-1 adding the .uuid files fixes the boot hang issue, but I guess not the underlying problem: [0.00] random: get_random_bytes called from start_kernel+0x94/0x478 with crng_init=0 [1.598566] r

Bug#897572: getrandom hang in early boot prevents plymouth passphrase entry

clone 897572 -1 reassign -1 src:utils-linux 2.31.1-0.5 thanks On Thu, 10 May 2018 14:36:56 +1200 Ben Caradoc-Davies wrote: > On 10/05/18 13:47, Theodore Y. Ts'o wrote: > > One other way to address this problem is to upgrade to util-linux 2.32 > > (released on March 21, 2018), interstingly, *be

Bug#897572: getrandom hang in early boot prevents plymouth passphrase entry

On 10/05/18 13:47, Theodore Y. Ts'o wrote: One other way to address this problem is to upgrade to util-linux 2.32 (released on March 21, 2018), interstingly, *before* the CVE-2018-1108 patches, whiich landed month later. The relevant commits from util-linux 2.32: a9cf659e0508: lib/randutils: Do n

Bug#897572: getrandom hang in early boot prevents plymouth passphrase entry

On Thu, May 10, 2018 at 12:41:41PM +1200, Ben Caradoc-Davies wrote: > tl;dr: fontconfig tries to regenerate .uuid files with getrandom (via > libuuid) in early boot, which hangs because of low pool entropy; the > plymouth fix is to copy the .uuid files into the initramfs with the DejaVu > fonts. O

Bug#897572: getrandom hang in early boot prevents plymouth passphrase entry

2001 From: Ben Caradoc-Davies Date: Thu, 10 May 2018 11:32:03 +1200 Subject: [PATCH] Copy fontconfig .uuid files to avoid getrandom hang in early boot Fixes: Bug#897572: getrandom hang in early boot prevents plymouth passphrase entry https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=897572 Sig

Bug#897572: [PATCH] Copy fontconfig .uuid files to avoid getrandom hang in early boot

Fixes: Bug#897572: getrandom hang in early boot prevents plymouth passphrase entry https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=897572 Signed-off-by: Ben Caradoc-Davies --- debian/local/plymouth.hook | 4 1 file changed, 4 insertions(+) diff --git a/debian/local/plymouth.hook b

Bug#897572: urandom hang in early boot

On Tue, 2018-05-08 at 13:23 +0200, Bjørn Mork wrote: > And sd_id128_randomize() is called from all over the place. I haven't > bothered looking at all the call sites, but would be surprised if not at > least one of them is unconditionally called at boot. > > If I am correct, then I guess this is

Bug#897572: getrandom hang in early boot prevents plymouth passphrase entry

I confirm this issue. It affects plymouth in general, not related to any passphrase entry. Booting in recovery mode helps to get around the plymouth problem, but if there is not enough entropy gdm3 will simply not start. Pressing keys/switching VTs leads to the crng_init finished message to be p

Bug#897572: urandom hang in early boot

Ben Hutchings writes: > On Tue, 2018-05-08 at 11:12 +1200, Ben Caradoc-Davies wrote: >> On 08/05/18 05:34, Laurent Bigonville wrote: >> > Apparently it's also happening for other applications that are starting >> > later during the boot like GDM. >> > Somebody has reported an issue on IRC where G

Bug#897572: urandom hang in early boot

On 08/05/18 15:55, Ben Caradoc-Davies wrote: If something calls getrandom without GRND_NONBLOCK while crng_init==1 (during early boot) I now have conclusive evidence that this is the cause of the hang. If I add a printk: diff --git a/drivers/char/random.c b/drivers/char/random.c index cd888d4e

Bug#897572: urandom hang in early boot

On 08/05/18 14:00, Ben Hutchings wrote: You keep saying this, but based on my reading of the code I don't see how reads from /dev/urandom can end up blocking. Ben, I think you are right. I have picked through the code in detail and none of the changes affect any substantive logic (except loggi

Bug#897572: urandom hang in early boot

On Tue, 2018-05-08 at 11:12 +1200, Ben Caradoc-Davies wrote: > On 08/05/18 05:34, Laurent Bigonville wrote: > > Apparently it's also happening for other applications that are starting > > later during the boot like GDM. > > Somebody has reported an issue on IRC where GDM was taking upto 8 > > min

Bug#897572: urandom hang in early boot

On 08/05/18 05:34, Laurent Bigonville wrote: Apparently it's also happening for other applications that are starting later during the boot like GDM. Somebody has reported an issue on IRC where GDM was taking upto 8 minutes to start (dmesg was showing several "random: systemd: uninitialized uran

Bug#897572: urandom hang in early boot

Hello, Apparently it's also happening for other applications that are starting later during the boot like GDM. Somebody has reported an issue on IRC where GDM was taking upto 8 minutes to start (dmesg was showing several "random: systemd: uninitialized urandom read (16 bytes read)" during bo

Bug#898098: It may be related to bug 897572

Hi, It may be related to bug 897572 Julien.

Bug#897572: [PATCH] Revert "random: fix crng_ready() test"

On Mon, May 07, 2018 at 02:58:03PM +1200, Ben Caradoc-Davies wrote: > This reverts commit 43838a23a05f ("random: fix crng_ready() test"), > which causes urandom to hang in early boot even when crng_init==1. > > One impact of this hang is that it prevents display of the plymouth > graphical passphr

Bug#897572: [PATCH] Revert "random: fix crng_ready() test"

By the way, if anyone is interested in working on this related problem: https://news.ycombinator.com/item?id=16976421 The reason why this is hard is because Linux is supported on a great number of architectures, and some architectures have more than one boot loader that is used. The a

Bug#897572: [PATCH] Revert "random: fix crng_ready() test"

On 07/05/18 15:29, Theodore Y. Ts'o wrote: Unfortunately, commit 43838a23a05f is needed to address CVE-2018-1108, which was reported by Jann Horn of Google's Project Zero. There are real problems with allowing programs to assume that they have a fully initialized cryptographic random number gene

Bug#897572: [PATCH] Revert "random: fix crng_ready() test"

ot prevents plymouth passphrase entry https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=897572 Signed-off-by: Ben Caradoc-Davies --- drivers/char/random.c | 10 +- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/drivers/char/random.c b/drivers/char/random.c index cd888d4ee605.

Bug#897572: plymouth: long delay before splashscreen with kernel 4.16

lized urandom read" warning in my screen photo: https://bugs.debian.org/cgi-bin/bugreport.cgi?att=1;bug=897572;filename=img_20180504_120059.jpg;msg=37 This bug is introduced by the "crng_init > 0" to "crng_init > 1" change in this commit: https://git.kernel.o

Bug#897572: linux-image-4.16.0-1-amd64 breaks plymouth LUKS prompt

On Sun, 2018-05-06 at 17:22 +0200, Laurent Bigonville wrote: > On Sat, 05 May 2018 20:01:45 +0100 Ben Hutchings > wrote: > > On Fri, 2018-05-04 at 12:20 +1200, Ben Caradoc-Davies wrote: > > > On 04/05/18 11:52, Ben Caradoc-Davies wrote: > > > > - Pressing *any* key repeatedly is enough to even

Bug#897572:

FWIW, I have the exact same problem (and can resolve it the exact same way, by moving my finger over my trackpad for a few seconds), and am on a different graphics card -- Intel Iris Graphics 540 (Skylake GT3e). I'm not an expert in kernel/firmware stuff at all, and can't compile a kernel from scr

Bug#897572: linux-image-4.16.0-1-amd64 breaks plymouth LUKS prompt

On Sat, 05 May 2018 20:01:45 +0100 Ben Hutchings wrote: > On Fri, 2018-05-04 at 12:20 +1200, Ben Caradoc-Davies wrote: > > On 04/05/18 11:52, Ben Caradoc-Davies wrote: > > > - Pressing *any* key repeatedly is enough to eventually wake up the > > > plymouth LUKS screen. For example, pressing Back

Bug#897572: plymouth: long delay before splashscreen with kernel 4.16

eport? Am 06.05.2018 um 03:01 schrieb Ben Caradoc-Davies: Looks like the same bug. We should probably merge, but into what package (linux, plymouth, or xorg)?: Bug#897958: plymouth: long delay before splashscreen with kernel 4.16 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=897958 Bug#897572:

Bug#897572: linux-image-4.16.0-1-amd64 breaks plymouth LUKS prompt

On Sun, 2018-05-06 at 12:33 +1200, Ben Caradoc-Davies wrote: > On 06/05/18 07:01, Ben Hutchings wrote: > > I wonder if this is related to the recent RNG changes. It seems that > > many programs have started using blocking RNG functions like > > getentropy(), and now that the kernel is more conserv

Bug#897572: plymouth: long delay before splashscreen with kernel 4.16

Looks like the same bug. We should probably merge, but into what package (linux, plymouth, or xorg)?: Bug#897958: plymouth: long delay before splashscreen with kernel 4.16 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=897958 Bug#897572: linux-image-4.16.0-1-amd64 breaks plymouth LUKS

Bug#897572: linux-image-4.16.0-1-amd64 breaks plymouth LUKS prompt

On 06/05/18 07:01, Ben Hutchings wrote: I wonder if this is related to the recent RNG changes. It seems that many programs have started using blocking RNG functions like getentropy(), and now that the kernel is more conservative in its initial entropy estimation they can block for a long time.

Bug#897572: linux-image-4.16.0-1-amd64 breaks plymouth LUKS prompt

On Fri, 2018-05-04 at 12:20 +1200, Ben Caradoc-Davies wrote: > On 04/05/18 11:52, Ben Caradoc-Davies wrote: > > - Pressing *any* key repeatedly is enough to eventually wake up the > > plymouth LUKS screen. For example, pressing Backspace many times. > > Even a modifier key is sufficient. Without

Bug#897572: linux-image-4.16.0-1-amd64 breaks plymouth LUKS prompt

More findings: - Adding i915 to /etc/initramfs-tools/modules as described in #803658 ("boot hangs before cryptsetup passphrase prompt if i915 drm driver is not in initramfs") has no effect. - Pressing *any* key repeatedly is enough to eventually wake up the plymouth LUKS screen. For example,

Bug#897572: linux-image-4.16.0-1-amd64 breaks plymouth LUKS prompt

On 03/05/18 17:37, Ben Caradoc-Davies wrote: And I should mention that my plymouth LUKS screen was working fine with kernels up to and including linux-image-4.15.0-3-amd64 4.15.17-1. And to eliminate any other change on the system as a cause, I rebuilt initrd.img for both packages and the plym

Bug#897572: linux-image-4.16.0-1-amd64 breaks plymouth LUKS prompt

And I should mention that my plymouth LUKS screen was working fine with kernels up to and including linux-image-4.15.0-3-amd64 4.15.17-1. Kind regards, -- Ben Caradoc-Davies Director Transient Software Limited New Zealand

Bug#897572: linux-image-4.16.0-1-amd64 breaks plymouth LUKS prompt

Trying to switch consoles with Alt-F1 to Alt-F7 many time eventually causes the plymouth LUKS screen to appear. This does not seem to be deterministic. Kind regards, -- Ben Caradoc-Davies Director Transient Software Limited New Zealand

Bug#897572: linux-image-4.16.0-1-amd64 breaks plymouth LUKS prompt

Manually installing kbl_dmc_ver1_04.bin and kbl_guc_ver9_39.bin from into /lib/firmware/i915 and running update-initramfs does not fix, so it it not a firmware issue. The firmware errors are removed, leaving

Bug#897572: linux-image-4.16.0-1-amd64 breaks plymouth LUKS prompt (missing Kaby Lake firmware?)

Package: linux Version: linux-image-4.16.0-1-amd64 Severity: normal Dear Maintainer, booting with linux-image-4.16.0-1-amd64 causes the plymouth LUKS prompt to not be displayed, preventing password entry and thus boot. System can still be rebooted with Ctrl-Alt-Del. The system is an Intel Kaby L