Hi Mark, Mark H Weaver <m...@netris.org> skribis:
> l...@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. 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?= <l...@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? 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’.