[bug#27520] [PATCH] build: Use "GUIXSD" as root label.

[bug#27520] [PATCH] build: Use "GUIXSD" as root label.

[Danny Milosavljevic]

* gnu/build/vm.scm (initialize-hard-disk): Make grub search for label "GUIXSD".
* gnu/system/install.scm (installation-os): Set filesystem root label to "GUIXSD".
* gnu/system/vm.scm (system-disk-image): Set filesystem root label to "GUIXSD".
---
 gnu/build/vm.scm       | 2 +-
 gnu/system/install.scm | 2 +-
 gnu/system/vm.scm      | 2 +-
 3 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/gnu/build/vm.scm b/gnu/build/vm.scm
index 57619764c..6b91e767f 100644
--- a/gnu/build/vm.scm
+++ b/gnu/build/vm.scm
@@ -398,7 +398,7 @@ passing it a directory name where it is mounted."
           (lambda (port)
             (format port
                     "insmod part_msdos~@
-                    search --set=root --label gnu-disk-image~@
+                    search --set=root --label GUIXSD~@
                     configfile /boot/grub/grub.cfg~%")))
 
         (display "creating EFI firmware image...")
diff --git a/gnu/system/install.scm b/gnu/system/install.scm
index 0a78d030d..24c736304 100644
--- a/gnu/system/install.scm
+++ b/gnu/system/install.scm
@@ -300,7 +300,7 @@ Use Alt-F2 for documentation.
      ;; the appropriate one.
      (cons* (file-system
               (mount-point "/")
-              (device "gnu-disk-image")
+              (device "GUIXSD")
               (title 'label)
               (type "ext4"))
 
diff --git a/gnu/system/vm.scm b/gnu/system/vm.scm
index 392737d07..6fae999ef 100644
--- a/gnu/system/vm.scm
+++ b/gnu/system/vm.scm
@@ -282,7 +282,7 @@ to USB sticks meant to be read-only."
     ;; Volume name of the root file system.  Since we don't know which device
     ;; will hold it, we use the volume name to find it (using the UUID would
     ;; be even better, but somewhat less convenient.)
-    "gnu-disk-image")
+    "GUIXSD")
 
   (define file-systems-to-keep
     (remove (lambda (fs)

[bug#27520] [PATCH] build: Use "GUIXSD" as root label.

[Leo Famulari]

[-- Attachment #1: Type: text/plain, Size: 420 bytes --]

Hi!

On Wed, Jun 28, 2017 at 11:38:41PM +0200, Danny Milosavljevic wrote:
> * gnu/build/vm.scm (initialize-hard-disk): Make grub search for label "GUIXSD".
> * gnu/system/install.scm (installation-os): Set filesystem root label to "GUIXSD".
> * gnu/system/vm.scm (system-disk-image): Set filesystem root label to "GUIXSD".

I assume there is some reason for this change, but I'm not sure what it
is. Can you tell us? :)

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

[bug#27520] [PATCH] build: Use "GUIXSD" as root label.

[Danny Milosavljevic]

Hi Leo,

On Wed, 28 Jun 2017 18:01:17 -0400
Leo Famulari <leo@famulari.name> wrote:

> On Wed, Jun 28, 2017 at 11:38:41PM +0200, Danny Milosavljevic wrote:
> > * gnu/build/vm.scm (initialize-hard-disk): Make grub search for label "GUIXSD".
> > * gnu/system/install.scm (installation-os): Set filesystem root label to "GUIXSD".
> > * gnu/system/vm.scm (system-disk-image): Set filesystem root label to "GUIXSD".  
> 
> I assume there is some reason for this change, but I'm not sure what it
> is. Can you tell us? :)

ISO9660 support.  The iso9660 volume label only supports uppercase letters and underscore.  While I was at it I removed the "-image" suffix because it's an implementation detail and it's really not an image once it's burned to a real CD / written to a real USB stick etc.  Then I removed the "-disk" suffix because volume labels are not on a disk but on individual partitions.  Then it was just "gnu" and I thought that was too generic.  So here we are :-)

[bug#27520] [PATCH] build: Use "GUIXSD" as root label.

[Leo Famulari]

[-- Attachment #1: Type: text/plain, Size: 1163 bytes --]

On Thu, Jun 29, 2017 at 12:17:01AM +0200, Danny Milosavljevic wrote:
> Hi Leo,
> 
> On Wed, 28 Jun 2017 18:01:17 -0400
> Leo Famulari <leo@famulari.name> wrote:
> 
> > On Wed, Jun 28, 2017 at 11:38:41PM +0200, Danny Milosavljevic wrote:
> > > * gnu/build/vm.scm (initialize-hard-disk): Make grub search for label "GUIXSD".
> > > * gnu/system/install.scm (installation-os): Set filesystem root label to "GUIXSD".
> > > * gnu/system/vm.scm (system-disk-image): Set filesystem root label to "GUIXSD".  
> > 
> > I assume there is some reason for this change, but I'm not sure what it
> > is. Can you tell us? :)
> 
> ISO9660 support.  The iso9660 volume label only supports uppercase
> letters and underscore.  While I was at it I removed the "-image"
> suffix because it's an implementation detail and it's really not an
> image once it's burned to a real CD / written to a real USB stick etc.
> Then I removed the "-disk" suffix because volume labels are not on a
> disk but on individual partitions.  Then it was just "gnu" and I
> thought that was too generic.  So here we are :-)

Good story :)

And ISO9660 requires uppercase letters?

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

[bug#27520] [PATCH] build: Use "GUIXSD" as root label.

[Danny Milosavljevic]

> And ISO9660 requires uppercase letters?

If we don't support special extensions (Rock Ridge, Joliet etc), yes.  And we don't support them right now.

[bug#27520] [PATCH] build: Use "GUIXSD" as root label.

[Ludovic Courtès]

Danny Milosavljevic <dannym@scratchpost.org> skribis:

>> And ISO9660 requires uppercase letters?
>
> If we don't support special extensions (Rock Ridge, Joliet etc), yes.  And we don't support them right now.

So what about literally “GuixSD” and then using ‘string-upcase’ in the
ISO9660 code?  That would avoid the all-caps style on all the other file
systems, which is a good thing.

Otherwise LGTM.

Ludo’, happy to discuss the bikeshed spelling.  :-)

[bug#27520] [PATCH] build: Use "GUIXSD" as root label.

[Danny Milosavljevic]

Hi Ludo,

On Thu, 29 Jun 2017 18:18:03 +0200
ludo@gnu.org (Ludovic Courtès) wrote:

> So what about literally “GuixSD” and then using ‘string-upcase’ in the
> ISO9660 code?  That would avoid the all-caps style on all the other file
> systems, which is a good thing.

As the code is written, it would be best and least confusing if gnu/build/file-systems.scm partition-label-predicate then just said

(define partition-label-predicate
  (partition-predicate read-partition-label string-ci=?))

instead of

(define partition-label-predicate
  (partition-predicate read-partition-label string=?))

, i.e. if it was done for all the filesystems.

Other alternatives are
- Implementing support for the Joliet extension just to get get lowercase letters on CDs
- Ignoring the problem and putting the lowercase letters in the primary volume name on CD anyway, using ISO-9660.  After all it's just forbidden, not impossible.

I personally favor just actually using all uppercase letters as the label.  Everything else makes it just needlessly complicated.

That said, the right fix would be to use the UUID instead of the label for finding the root filesystem.  Using the label isn't really safe anyway - whereas a random UUID should be preeeeeeetty safe.

I'm testing passing the UUID now.  Let's see...

[bug#27520] Booting by UUID - UUID types and bootloader

[Danny Milosavljevic]

Hi Ludo,

> That said, the right fix would be to use the UUID instead of the label for finding the root filesystem.  Using the label isn't really safe anyway - whereas a random UUID should be preeeeeeetty safe.
> 
> I'm testing passing the UUID now.  Let's see...

Doesn't work.

The main reason is that the root-device stored into "/gnu/store/*system*/parameters" for UUIDs is (sometimes) a bytevector.  That means that if it is then later on we won't know what kind of uuid it is - and gnu/system.scm operating-system-bootcfg will just use uuid->string (in order to add it to argv) and it will break.

Also, gnu/bootloader/grub.scm grub-root-search assumes the UUID is a non-iso9660 UUID and thus grub will be very confused.  Also, it doesn't (and shouldn't need to) know the root filesystem type either - that means that it can't select the right kind of UUID.  We get a warning about it on bootup (after a long time) but it still tries to boot to the kernel successfully.

read-boot-parameters-file also converts bytevector UUIDs (read from disk, file "parameters") to string UUIDs (using uuid->string, so no support for ISO9660 or FAT) and uses those in order to build up the kernel argument list "--root=" and so on.  It doesn't (and shouldn't need to) know the filesystem type.

(There are more places where I added a special-case for iso9660 UUIDs - I can dig them up from my git repo clone)

I would like to ask again that we just store UUIDs as strings and stop this.  If we want to verify UUIDs, we can verify them as strings.  We can even distinguish UUID types then.

We could just have string->*-uuid do the verification but then return the string after all.  uuid->string could be a no-op.  And the uuid readers could return the readable representation in the first place.


Or, alternatively, we could add a uuid type field as the first byte of the bytevector (making them longer by 1 Byte).  That way, we would intrinsically know which kind of UUID it is.  That would still mean that the user would have to specify which it is by calling string->...-uuid - and that we'd have to adapt the on-disk "parameters" format - but I think it would work fine and not suck.  uuid->string would then just do the right thing depending on the first Byte.

The latter alternative would mean that the user has to know what kind of uuid it is - and what kind of filesystem it is.  Not so with the former alternative.

[bug#27520] Booting by UUID - UUID types and bootloader

[Ludovic Courtès]

Hi Danny,

Danny Milosavljevic <dannym@scratchpost.org> skribis:

>> That said, the right fix would be to use the UUID instead of the
>> label for finding the root filesystem.  Using the label isn't really
>> safe anyway - whereas a random UUID should be preeeeeeetty safe.
>> 
>> I'm testing passing the UUID now.  Let's see...
>
> Doesn't work.
>
> The main reason is that the root-device stored into
> "/gnu/store/*system*/parameters" for UUIDs is (sometimes) a
> bytevector.  That means that if it is then later on we won't know what
> kind of uuid it is - and gnu/system.scm operating-system-bootcfg will
> just use uuid->string (in order to add it to argv) and it will break.
>
> Also, gnu/bootloader/grub.scm grub-root-search assumes the UUID is a
> non-iso9660 UUID and thus grub will be very confused.  Also, it
> doesn't (and shouldn't need to) know the root filesystem type either -
> that means that it can't select the right kind of UUID.  We get a
> warning about it on bootup (after a long time) but it still tries to
> boot to the kernel successfully.
>
> read-boot-parameters-file also converts bytevector UUIDs (read from
> disk, file "parameters") to string UUIDs (using uuid->string, so no
> support for ISO9660 or FAT) and uses those in order to build up the
> kernel argument list "--root=" and so on.  It doesn't (and shouldn't
> need to) know the filesystem type.

The good thing is that ‘find-partition-by-uuid’ takes a bytevector and
just looks up a partition with that UUID, no matter if it’s a DCE UUID
or something else.

The problem comes as soon as we want to convert it to a string, as is
the case with --root.

For --root (the 2 occurrences of ‘uuid->string’ in (gnu system)), we
could convert it the UUID to a base16/base32/base64 string.  That would
be good enough and wouldn’t require a specialized ‘string->*-uuid’ to
parse it.  We’d just need, say, a “uuid:” prefix to distinguish it from
a label, but that should be about it.

WDYT?

> I would like to ask again that we just store UUIDs as strings and stop
> this.  If we want to verify UUIDs, we can verify them as strings.  We
> can even distinguish UUID types then.
>
> We could just have string->*-uuid do the verification but then return
> the string after all.  uuid->string could be a no-op.  And the uuid
> readers could return the readable representation in the first place.
>
>
> Or, alternatively, we could add a uuid type field as the first byte of
> the bytevector (making them longer by 1 Byte).  That way, we would
> intrinsically know which kind of UUID it is.  That would still mean
> that the user would have to specify which it is by calling
> string->...-uuid - and that we'd have to adapt the on-disk
> "parameters" format - but I think it would work fine and not suck.
> uuid->string would then just do the right thing depending on the first
> Byte.
>
> The latter alternative would mean that the user has to know what kind
> of uuid it is - and what kind of filesystem it is.  Not so with the
> former alternative.

As a last resort, we could indeed have:

  (define-record-type <uuid>
    (make-uuid type bytes)
    uuid?
    (type  uuid-type)   ;'dce, 'vfat, etc.
    (bytes uuid-bytes)) ;bytevector

Then ‘uuid->string’ would always know what external representation; it
would simply dispatch to one of the other *-uuid->string procedures.

But, if possible, I think it’s simpler to always keep bytevectors
everywhere.

Why bytevectors are not strings?  Because then we keep the bytes, which
is all that matters, while avoiding all the shenanigans associated with
producing and parsing UUID strings, each with its own syntax.

WDYT?

Ludo’.

[bug#27520] [PATCH v2] build, vm: Use "GuixSD" or "GUIXSD" as volume label.

[Danny Milosavljevic]

* gnu/build/vm.scm (initialize-hard-disk): Use "GuixSD" as label.
* gnu/system/install.scm (installation-os): Use "GuixSD" as label.
* gnu/system/vm.scm (system-disk-image): Use "GuixSD" or "GUIXSD" as volume
label.
---
 gnu/build/vm.scm       | 2 +-
 gnu/system/install.scm | 2 +-
 gnu/system/vm.scm      | 8 +++++++-
 3 files changed, 9 insertions(+), 3 deletions(-)

diff --git a/gnu/build/vm.scm b/gnu/build/vm.scm
index e631e5a83..2d41c5756 100644
--- a/gnu/build/vm.scm
+++ b/gnu/build/vm.scm
@@ -431,7 +431,7 @@ passing it a directory name where it is mounted."
           (lambda (port)
             (format port
                     "insmod part_msdos~@
-                    search --set=root --label gnu-disk-image~@
+                    search --set=root --label GuixSD~@
                     configfile /boot/grub/grub.cfg~%")))
 
         (display "creating EFI firmware image...")
diff --git a/gnu/system/install.scm b/gnu/system/install.scm
index d5d11371a..f9aa7f673 100644
--- a/gnu/system/install.scm
+++ b/gnu/system/install.scm
@@ -306,7 +306,7 @@ Use Alt-F2 for documentation.
      ;; the appropriate one.
      (cons* (file-system
               (mount-point "/")
-              (device "gnu-disk-image")
+              (device "GuixSD")
               (title 'label)
               (type "ext4"))
 
diff --git a/gnu/system/vm.scm b/gnu/system/vm.scm
index 3e722d081..66a2448ce 100644
--- a/gnu/system/vm.scm
+++ b/gnu/system/vm.scm
@@ -335,11 +335,17 @@ the image."
 system described by OS.  Said image can be copied on a USB stick as is.  When
 VOLATILE? is true, the root file system is made volatile; this is useful
 to USB sticks meant to be read-only."
+  (define normalize-label
+    ;; ISO labels are all-caps (case-insensitive), but since
+    ;; 'find-partition-by-label' is case-sensitive, make it all-caps here.
+    (if (string=? "iso9660" file-system-type)
+        string-upcase
+        identity))
   (define root-label
     ;; Volume name of the root file system.  Since we don't know which device
     ;; will hold it, we use the volume name to find it (using the UUID would
     ;; be even better, but somewhat less convenient.)
-    "gnu-disk-image")
+    (normalize-label "GuixSD"))
 
   (define file-systems-to-keep
     (remove (lambda (fs)

[bug#27520] [PATCH v2] build, vm: Use "GuixSD" or "GUIXSD" as volume label.

[Ludovic Courtès]

Danny Milosavljevic <dannym@scratchpost.org> skribis:

> * gnu/build/vm.scm (initialize-hard-disk): Use "GuixSD" as label.
> * gnu/system/install.scm (installation-os): Use "GuixSD" as label.
> * gnu/system/vm.scm (system-disk-image): Use "GuixSD" or "GUIXSD" as volume
> label.

LGTM, thanks for your patience!

> --- a/gnu/build/vm.scm
> +++ b/gnu/build/vm.scm
> @@ -431,7 +431,7 @@ passing it a directory name where it is mounted."
>            (lambda (port)
>              (format port
>                      "insmod part_msdos~@
> -                    search --set=root --label gnu-disk-image~@
> +                    search --set=root --label GuixSD~@
>                      configfile /boot/grub/grub.cfg~%")))

This won’t cause problems with ISO images, right?

Ludo’.

bug#27520: [PATCH v2] build, vm: Use "GuixSD" or "GUIXSD" as volume label.

[Danny Milosavljevic]

Hi Ludo,

On Mon, 10 Jul 2017 12:33:39 +0200
ludo@gnu.org (Ludovic Courtès) wrote:

> > +++ b/gnu/build/vm.scm
> > @@ -431,7 +431,7 @@ passing it a directory name where it is mounted."
> >            (lambda (port)
> >              (format port
> >                      "insmod part_msdos~@
> > -                    search --set=root --label gnu-disk-image~@
> > +                    search --set=root --label GuixSD~@
> >                      configfile /boot/grub/grub.cfg~%")))  
> 
> This won’t cause problems with ISO images, right?

Good question.

I successfully tested it in qemu (both iso9660 and normal disk-image).

I also ran the system checks.  Some work, some don't work.  The bootup part does generally work.

But I'm not that knowledgeable with UEFI, so no idea whether ISO9660 bootup would even use this UEFI wrapper thing.

Anyway, it doesn't worsen anything so I pushed it to master, commit 651de2bdb5fd451c50933dcf8d647d470d826261.

Thanks!

P.S. Some system tests look not-so-good either with or without the patch applied:

Jul 10 15:30:54 localhost avahi-daemon[438]: simple-protocol.c: Got RESOLVE-ADDRESS request for 'fe80::5054:ff:fe12:3456'.
Mon Jul 10 15:30:54 2017 - 341: add new entry "komputilo.local" of type GETAI for hosts to cache (first)
ice-9/eval.scm:387:11: In procedure eval:
ice-9/eval.scm:387:11: In procedure getaddrinfo: System error
ice-9/eval.scm:387:11: In procedure eval:
ice-9/eval.scm:387:11: In procedure gethost: Host name lookup failure
QEMU runs as PID 3
connected to QEMU's monitor
read QEMU monitor prompt
connected to guest REPL
%%%% Starting test avahi  (Writing full log to "avahi.log")
marionette is ready
/gnu/store/mw90mh1jb8z4s67k5pi2pk9zid0cqgjl-nss-mdns-builder:1: FAIL getaddrinfo .local

;;; (gethostbyname #f)
/gnu/store/mw90mh1jb8z4s67k5pi2pk9zid0cqgjl-nss-mdns-builder:1: FAIL gethostbyname .local
# of expected passes      3
# of unexpected failures  2
note: keeping build directory `/tmp/guix-build-nss-mdns.drv-0'
builder for `/gnu/store/b4ikx6m6952a5q5hx8576pismks8mq72-nss-mdns.drv' failed with exit code 1
@ build-failed /gnu/store/b4ikx6m6952a5q5hx8576pismks8mq72-nss-mdns.drv - 1 builder for `/gnu/store/b4ikx6m6952a5q5hx8576pismks8mq72-nss-mdns.drv' failed with exit code 1
TOTAL: 19
PASS: /gnu/store/jsmkjv57sdycy89whbpj8w0ggzladmy1-basic
PASS: /gnu/store/i3rpc4na0s8n3ys37qlrzbmsd63g0x4n-mcron
PASS: /gnu/store/dx2ibskh8a6qirk20n19d5xam2wk3yzy-opensmtpd-test
PASS: /gnu/store/xgmmghm577xp41w6j1xlzr912x7c1l72-prosody
PASS: /gnu/store/dl4bjcwwgrrp84mmfm4gcxrp9mfvcwqs-inetd-test
PASS: /gnu/store/9hg2bp1yk5mdl3wqgfkzvdxm1qmkk6pz-nfs
PASS: /gnu/store/658s8abgckc4anzlqh9sn17vjhngnyy1-openssh
PASS: /gnu/store/p6visdc6p4najg7dy4rfpy201136ysn5-dropbear
PASS: /gnu/store/kynb05cj7kd5kfh9690xwm0i8gvc536z-nginx-test
FAIL: /gnu/store/90484bwhiizialy1qfvm3gk2fn9r499n-nss-mdns
FAIL: /gnu/store/csxh0dnpbjqc8q1qkb9j5gbjrlhbpy7v-dicod
FAIL: /gnu/store/6vp4xg0zzrcz5ksdykd9zr5ydwpvjgvk-btrfs-root-os
FAIL: /gnu/store/5lw5gfvljp3kkf32k71g2vik258g9jpj-raid-root-os
FAIL: /gnu/store/n5dq0nx8vgw6ci6wpl7r78bchfs29lfc-installed-os
FAIL: /gnu/store/bm6n23mp1x74jj57kvy2hlfhi2iyxjhs-encrypted-root-os
FAIL: /gnu/store/3sjjq1xavrvhkbj7hqbjgvmcmpagmcpz-installed-extlinux-os
FAIL: /gnu/store/0mj78x3awxwrrjp9s53xgcaa1y5aps8k-separate-store-os
FAIL: /gnu/store/64wmjlfidh0mzl700zfqmrxmc475vhbk-separate-home-os
FAIL: /gnu/store/xrbg9b6xc1q26byw0pxi0lk7q58p3z52-exim-test
make: *** [Makefile:5188: check-system] Error 1

(At the same time, my normal internet connection works fine)

[bug#27520] [PATCH v2] build, vm: Use "GuixSD" or "GUIXSD" as volume label.

[Ludovic Courtès]

Hi Danny,

Danny Milosavljevic <dannym@scratchpost.org> skribis:

> On Mon, 10 Jul 2017 12:33:39 +0200
> ludo@gnu.org (Ludovic Courtès) wrote:
>
>> > +++ b/gnu/build/vm.scm
>> > @@ -431,7 +431,7 @@ passing it a directory name where it is mounted."
>> >            (lambda (port)
>> >              (format port
>> >                      "insmod part_msdos~@
>> > -                    search --set=root --label gnu-disk-image~@
>> > +                    search --set=root --label GuixSD~@
>> >                      configfile /boot/grub/grub.cfg~%")))  
>> 
>> This won’t cause problems with ISO images, right?
>
> Good question.
>
> I successfully tested it in qemu (both iso9660 and normal disk-image).
>
> I also ran the system checks.  Some work, some don't work.  The bootup part does generally work.
>
> But I'm not that knowledgeable with UEFI, so no idea whether ISO9660 bootup would even use this UEFI wrapper thing.
>
> Anyway, it doesn't worsen anything so I pushed it to master, commit 651de2bdb5fd451c50933dcf8d647d470d826261.

Cool!

> P.S. Some system tests look not-so-good either with or without the patch applied:

[...]

> TOTAL: 19
> PASS: /gnu/store/jsmkjv57sdycy89whbpj8w0ggzladmy1-basic
> PASS: /gnu/store/i3rpc4na0s8n3ys37qlrzbmsd63g0x4n-mcron
> PASS: /gnu/store/dx2ibskh8a6qirk20n19d5xam2wk3yzy-opensmtpd-test
> PASS: /gnu/store/xgmmghm577xp41w6j1xlzr912x7c1l72-prosody
> PASS: /gnu/store/dl4bjcwwgrrp84mmfm4gcxrp9mfvcwqs-inetd-test
> PASS: /gnu/store/9hg2bp1yk5mdl3wqgfkzvdxm1qmkk6pz-nfs
> PASS: /gnu/store/658s8abgckc4anzlqh9sn17vjhngnyy1-openssh
> PASS: /gnu/store/p6visdc6p4najg7dy4rfpy201136ysn5-dropbear
> PASS: /gnu/store/kynb05cj7kd5kfh9690xwm0i8gvc536z-nginx-test
> FAIL: /gnu/store/90484bwhiizialy1qfvm3gk2fn9r499n-nss-mdns

This one is “known to fail”.

> FAIL: /gnu/store/csxh0dnpbjqc8q1qkb9j5gbjrlhbpy7v-dicod
> FAIL: /gnu/store/6vp4xg0zzrcz5ksdykd9zr5ydwpvjgvk-btrfs-root-os
> FAIL: /gnu/store/5lw5gfvljp3kkf32k71g2vik258g9jpj-raid-root-os
> FAIL: /gnu/store/n5dq0nx8vgw6ci6wpl7r78bchfs29lfc-installed-os
> FAIL: /gnu/store/bm6n23mp1x74jj57kvy2hlfhi2iyxjhs-encrypted-root-os
> FAIL: /gnu/store/3sjjq1xavrvhkbj7hqbjgvmcmpagmcpz-installed-extlinux-os
> FAIL: /gnu/store/0mj78x3awxwrrjp9s53xgcaa1y5aps8k-separate-store-os
> FAIL: /gnu/store/64wmjlfidh0mzl700zfqmrxmc475vhbk-separate-home-os
> FAIL: /gnu/store/xrbg9b6xc1q26byw0pxi0lk7q58p3z52-exim-test

… but those are alarming.

“make check-system TESTS="dicod exim"” works for me on current master; I
haven’t checked the other ones.  Could you see what’s wrong?

Thanks,
Ludo’.

[bug#27520] [PATCH v2] build, vm: Use "GuixSD" or "GUIXSD" as volume label.

[Danny Milosavljevic]

[-- Attachment #1: Type: text/plain, Size: 388 bytes --]

On Tue, 11 Jul 2017 17:30:44 +0200
ludo@gnu.org (Ludovic Courtès) wrote:

> “make check-system TESTS="dicod exim"” works for me on current master; I
> haven’t checked the other ones.  Could you see what’s wrong?

Both say "Connection refused".

I've attached the entire log file.

I've ran it using

$ guix environment guix  --pure --fallback
$ make check-system


[-- Attachment #2: L.bz2 --]
[-- Type: application/x-bzip, Size: 591671 bytes --]

[bug#27520] System test failures

[Ludovic Courtès]

Danny Milosavljevic <dannym@scratchpost.org> skribis:

> On Tue, 11 Jul 2017 17:30:44 +0200
> ludo@gnu.org (Ludovic Courtès) wrote:
>
>> “make check-system TESTS="dicod exim"” works for me on current master; I
>> haven’t checked the other ones.  Could you see what’s wrong?
>
> Both say "Connection refused".

Weird, it looks as though port forwards from the guest to the host
didn’t work, although it definitely works here and on hydra:

  https://hydra.gnu.org/job/gnu/master/test.dicod.x86_64-linux
  https://hydra.gnu.org/job/gnu/master/test.exim.x86_64-linux

The build environment lives in a separate network namespace, which I
think means that there cannot be conflicts regarding the TCP ports being
used, so I wonder what could be interfering.

Ludo’.