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.000000] random: get_random_bytes called from start_kernel+0x94/0x478 with crng_init=0 [ 1.598566] random: fast init done [ 3.878990] random: plymouthd: uninitialized urandom read (8 bytes read) [ 3.879102] random: plymouthd: uninitialized urandom read (8 bytes read) [ 3.973800] random: lvm: uninitialized urandom read (4 bytes read) [ 3.989370] random: lvm: uninitialized urandom read (4 bytes read) [ 13.779206] random: crng init done Blocking in userspace is I guess not a really perfect because it also prevents userspace feedback entropy back to the kernel, but it boils down to whether the needed entropy is cryptographically critical or not (generating UUID for fontconfig vs. generating long-terme keys, for example). One other thing which is initialized quite early in the kernel is ASLR, stack canaries etc. for which we'd like some good randomness too. My laptop has RDRAND and a TPM which can provide randomness (when rng-tools is running), so it really should not lack entropy, but right now we don't credit RDRAND entropy for trust issue. Is it really that good a decision? Couldn't we have a middle ground, and use hardware entropy sources when they're available and we're not initialized? Regards, -- Yves-Alexis
signature.asc
Description: This is a digitally signed message part
