GNU bug report logs - #36380
service urandom-seed takes too long on boot

Previous Next

Package: guix;

Reported by: Robert Vollmert <rob <at> vllmrt.net>

Date: Tue, 25 Jun 2019 18:13:02 UTC

Severity: important

Full log


View this message in rfc822 format

From: Leo Famulari <leo <at> famulari.name>
To: Robert Vollmert <rob <at> vllmrt.net>
Cc: 36380 <at> debbugs.gnu.org
Subject: bug#36380: service urandom-seed takes too long on boot
Date: Wed, 26 Jun 2019 11:47:21 -0400
[Message part 1 (text/plain, inline)]
On Tue, Jun 25, 2019 at 08:12:28PM +0200, Robert Vollmert wrote:
> On my VPS, booting takes forever (long enough that for a long
> time I thought the install had failed). I just rebooted again,
> and it took over 7 minutes, see attached screenshot.

Yikes, that's way too long. Can you say what VPS it is?

> I would suggest skipping the seeding from /dev/hwrng by default
> if /var/lib/random-seed is available. I’m assuming here that my
> problem is not too rare — if it is, an option to disable the
> seeding from /dev/hwrng seems like a good idea.

Originally I added the HWRNG read specifically the for VM / VPS use case
[0], where the first boot environment is relatively deterministic. I
agree it's superfluous if the random-seed file is handled properly but
it's nice to unconditionally have this other entropy source that avoids
the pitfalls of file-based entropy seeding.

Ideally the hypervisor would seed the guest's HWRNG interface with the
host's /dev/urandom, which would avoid significant delays. It seems they
are using some other more limited resource instead.

Does anyone else have an opinion or experience with this issue? It would
be great to know how widespread it is.

[0]
https://git.savannah.gnu.org/cgit/guix.git/commit/?id=9a56cf2b5b4970843c215091ea9823a67e077310
https://lists.gnu.org/archive/html/guix-devel/2017-12/msg00096.html
[signature.asc (application/pgp-signature, inline)]

This bug report was last modified 4 years and 126 days ago.

Previous Next


GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.