bug#31268: 'guix system vm-image' hangs

[Mark H Weaver <mhw@netris.org>]

Hi Ludovic,

ludo@gnu.org (Ludovic Courtès) writes:

> I was looking at the wrong code: we’re using libuuid from util-linux,
> which in turn uses getrandom(2).  Since it doesn’t 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’s ‘uuid_generate’, which is good enough for this
>      purpose.  I’ll submit it upstream.
>
>   2. e2fsprogs is changed to use a libuuid that passes GRND_NONBLOCK.
>      It does the job, but it’s 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.

> Another approach I looked at was to seed the VM’s PRNG from /dev/hwrng,
> which I thought was connected to the host via ‘virtio-rng-pci’, but I
> get ENODEV while trying to read from /dev/hwrng in the guest like this:

I much prefer this approach, where we seed the VM's PRNG from another
source.

> From 8aa37a4124db90a9991485477d1af85677c7fa1b Mon Sep 17 00:00:00 2001
> From: =?UTF-8?q?Ludovic=20Court=C3=A8s?= <ludo@gnu.org>
> Date: Tue, 22 May 2018 17:36:35 +0200
> Subject: [PATCH 2/3] vm: Use a deterministic file system UUID in shared-store
>  VMs.
> 
> * 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(+)
> 
> 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 sequence,
>  bootloaded included; thus, make a disk image that contains everything the
>  bootloader refers to: OS kernel, initrd, bootloader data, etc."
> +  (define root-uuid
> +    ;; Use a fixed UUID so that 'mke2fs' doesn't wait for strong randomness
> +    ;; while generating a UUID.  See <https://bugs.gnu.org/31268>.
> +    ;; XXX: Actually it doesn't help since 'mke2fs' calls 'uuid_generate'
> +    ;; 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?

      Thanks,
        Mark