From mboxrd@z Thu Jan 1 00:00:00 1970 From: ludo@gnu.org (Ludovic =?UTF-8?Q?Court=C3=A8s?=) Subject: bug#31268: 'guix system vm-image' hangs Date: Wed, 23 May 2018 09:27:54 +0200 Message-ID: <87vabe3k79.fsf@gnu.org> References: <87604en3u5.fsf@gmail.com> <20180425223706.22d91e40@centurylink.net> <877eoua9v1.fsf@gmail.com> <87r2mxw1ax.fsf@netris.org> <87bme0ydzn.fsf@gnu.org> <87y3h4fy8c.fsf@netris.org> <87muwx9h82.fsf@lassieur.org> <87a7swrk8i.fsf@gnu.org> <87h8mz4q2g.fsf@gnu.org> <8736yj711l.fsf@netris.org> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:57017) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1fLOCo-0000kp-Du for bug-guix@gnu.org; Wed, 23 May 2018 03:29:07 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1fLOCk-0004hB-8R for bug-guix@gnu.org; Wed, 23 May 2018 03:29:06 -0400 Received: from debbugs.gnu.org ([208.118.235.43]:36796) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1fLOCk-0004h3-4g for bug-guix@gnu.org; Wed, 23 May 2018 03:29:02 -0400 Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1fLOCj-0004Ld-VF for bug-guix@gnu.org; Wed, 23 May 2018 03:29:01 -0400 Sender: "Debbugs-submit" Resent-Message-ID: In-Reply-To: <8736yj711l.fsf@netris.org> (Mark H. Weaver's message of "Tue, 22 May 2018 18:55:50 -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: Mark H Weaver Cc: 31268@debbugs.gnu.org, George myglc2 Clemmer , =?UTF-8?Q?Cl=C3=A9ment?= Lassieur Hi Mark, Mark H Weaver skribis: > ludo@gnu.org (Ludovic Court=C3=A8s) writes: > >> I was looking at the wrong code: we=E2=80=99re using libuuid from util-l= inux, >> which in turn uses getrandom(2). Since it doesn=E2=80=99t pass the >> GRND_NONBLOCK flag, it ends up blocking forever because too little >> entropy is available in the VM. >> >> The following patches work around that: >> >> 1. Parted now explicitly uses getrandom(2) with GRND_NONBLOCK instead >> of libuuid=E2=80=99s =E2=80=98uuid_generate=E2=80=99, which is good= enough for this >> purpose. I=E2=80=99ll submit it upstream. >> >> 2. e2fsprogs is changed to use a libuuid that passes GRND_NONBLOCK. >> It does the job, but it=E2=80=99s quite inelegant. > > I'm uncomfortable with this approach. I think that it's proper for uuid > generation to block if there's not enough entropy. Yeah, I think #1 is OK because it=E2=80=99s =E2=80=9Cjust=E2=80=9D FAT seri= al numbers, but #2 could be more problematic. We could keep these package variants private though, and use them only for the purposes of =E2=80=98qemu-image=E2=80=99 if we don=E2=80=99t find a= better solution. >> From 8aa37a4124db90a9991485477d1af85677c7fa1b Mon Sep 17 00:00:00 2001 >> From: =3D?UTF-8?q?Ludovic=3D20Court=3DC3=3DA8s?=3D >> Date: Tue, 22 May 2018 17:36:35 +0200 >> Subject: [PATCH 2/3] vm: Use a deterministic file system UUID in shared-= store >> VMs. >>=20 >> * gnu/system/vm.scm (system-qemu-image/shared-store): Pass >> #:file-system-uuid to 'qemu-image'. >> --- >> gnu/system/vm.scm | 8 ++++++++ >> 1 file changed, 8 insertions(+) >>=20 >> diff --git a/gnu/system/vm.scm b/gnu/system/vm.scm >> index 09a11af86..b6561dfc7 100644 >> --- a/gnu/system/vm.scm >> +++ b/gnu/system/vm.scm >> @@ -752,6 +752,13 @@ with the host. >> When FULL-BOOT? is true, return an image that does a complete boot sequ= ence, >> bootloaded included; thus, make a disk image that contains everything t= he >> bootloader refers to: OS kernel, initrd, bootloader data, etc." >> + (define root-uuid >> + ;; Use a fixed UUID so that 'mke2fs' doesn't wait for strong random= ness >> + ;; while generating a UUID. See . >> + ;; XXX: Actually it doesn't help since 'mke2fs' calls 'uuid_generat= e' >> + ;; anyway. > > How about fixing mke2fs so that if you specify a fixed UUID, it won't > try to generate a random one? Would that be sufficient? mke2fs generates two UUIDs: --8<---------------cut here---------------start------------->8--- if (fs_uuid) { =E2=80=A6 } else uuid_generate(fs->super->s_uuid); [...] uuid_generate((unsigned char *) fs->super->s_hash_seed); --8<---------------cut here---------------end--------------->8--- The first =E2=80=98uuid_generate=E2=80=99 call is omitted when we pass =E2= =80=9C-U UUID=E2=80=9D but the second one isn=E2=80=99t. I don=E2=80=99t think we can get around it. Thanks, Ludo=E2=80=99.