From mboxrd@z Thu Jan 1 00:00:00 1970 From: Ludovic =?UTF-8?Q?Court=C3=A8s?= Subject: bug#36380: service urandom-seed takes too long on boot Date: Thu, 27 Jun 2019 22:00:37 +0200 Message-ID: <87r27evlwa.fsf@gnu.org> References: <20190626154721.GA2999@jasmine.lan> <87zhm3xdfu.fsf@gnu.org> <20190627190314.GA7403@jasmine.lan> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Return-path: Received: from eggs.gnu.org ([2001:470:142:3::10]:39538) by lists.gnu.org with esmtp (Exim 4.86_2) (envelope-from ) id 1hgaZu-0000xI-D6 for bug-guix@gnu.org; Thu, 27 Jun 2019 16:01:08 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1hgaZs-0006EN-Ct for bug-guix@gnu.org; Thu, 27 Jun 2019 16:01:06 -0400 Received: from debbugs.gnu.org ([209.51.188.43]:54481) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1hgaZq-0006Cw-0H for bug-guix@gnu.org; Thu, 27 Jun 2019 16:01:02 -0400 Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1hgaZp-0004QJ-Rc for bug-guix@gnu.org; Thu, 27 Jun 2019 16:01:01 -0400 Sender: "Debbugs-submit" Resent-Message-ID: In-Reply-To: <20190627190314.GA7403@jasmine.lan> (Leo Famulari's message of "Thu, 27 Jun 2019 15:03:14 -0400") List-Id: Bug reports for GNU Guix List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-guix-bounces+gcggb-bug-guix=m.gmane.org@gnu.org Sender: "bug-Guix" To: Leo Famulari Cc: 36380@debbugs.gnu.org, Robert Vollmert Leo Famulari skribis: > On Thu, Jun 27, 2019 at 05:20:21PM +0200, Ludovic Court=C3=A8s wrote: >> We had a =E2=80=9Cbug report=E2=80=9D at >> , which may = be >> due to the same issue: >>=20 >> The first time I loaded Guix the boot process took an unusually long >> time. At one point the system appeared to lock up for about five >> minutes before continuing. In the end, from boot menu to graphical >> login screen, the start-up time totalled about ten minutes. > > Perhaps, but if the reason for the slowness on their first boot was a > suboptimal /dev/hwrng source, I would expect it to be equally slow for > each boot, since we unconditionally read 64 bytes each time. Perhaps VirtualBox behaves this way? For instance, the VM was rebooted but VirtualBox itself was still running, and thus it had a good random seed to start from on the second boot (does that make sense?). I guess we should try. > They are using an old machine with a spinning disk, so who knows... Still, what else could be taking this long? Thanks, Ludo=E2=80=99.