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

[Ludovic Courtès]

Hi Mark,

Mark H Weaver <address@hidden> skribis:

> address@hidden (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.

Yeah, I think #1 is OK because it’s “just” FAT serial numbers, but #2
could be more problematic.

We could keep these package variants private though, and use them only
for the purposes of ‘qemu-image’ if we don’t find a better solution.

>> From 8aa37a4124db90a9991485477d1af85677c7fa1b Mon Sep 17 00:00:00 2001
>> From: =?UTF-8?q?Ludovic=20Court=C3=A8s?= <address@hidden>
>> 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?

mke2fs generates two UUIDs:

--8<---------------cut here---------------start------------->8---
        if (fs_uuid) { … }
        else
                uuid_generate(fs->super->s_uuid);

        [...]

        uuid_generate((unsigned char *) fs->super->s_hash_seed);
--8<---------------cut here---------------end--------------->8---

The first ‘uuid_generate’ call is omitted when we pass “-U UUID” but the
second one isn’t.  I don’t think we can get around it.

Thanks,
Ludo’.