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

---

gnu/build/vm.scm | 2 +-

gnu/system/install.scm | 2 +-

gnu/system/vm.scm | 2 +-

3 files changed, 3 insertions(+), 3 deletions(-)

Hi!

On Wed, Jun 28, 2017 at 11:38:41PM +0200, Danny Milosavljevic wrote:

I assume there is some reason for this change, but I'm not sure what it

is. Can you tell us? :)

Hi Leo,

On Wed, 28 Jun 2017 18:01:17 -0400

Leo Famulari <leo@famulari.name> wrote:

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 :-)

On Thu, Jun 29, 2017 at 12:17:01AM +0200, Danny Milosavljevic wrote:

Good story :)

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.

Danny Milosavljevic <dannym@scratchpost.org> skribis:

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. :-)

Hi Ludo,

On Thu, 29 Jun 2017 18:18:03 +0200

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

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...

Hi Ludo,

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.

Hi Danny,

Danny Milosavljevic <dannym@scratchpost.org> skribis:

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?

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’.

label.

---

gnu/build/vm.scm | 2 +-

gnu/system/install.scm | 2 +-

gnu/system/vm.scm | 8 +++++++-

3 files changed, 9 insertions(+), 3 deletions(-)

Danny Milosavljevic <dannym@scratchpost.org> skribis:

LGTM, thanks for your patience!

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

Ludo’.

Hi Ludo,

On Mon, 10 Jul 2017 12:33:39 +0200

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

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)

Hi Danny,

Danny Milosavljevic <dannym@scratchpost.org> skribis:

Cool!

[...]

This one is “known to fail”.

… 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’.

On Tue, 11 Jul 2017 17:30:44 +0200

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

Both say "Connection refused".

I've attached the entire log file.

I've ran it using

$ guix environment guix --pure --fallback

$ make check-system

Danny Milosavljevic <dannym@scratchpost.org> skribis:

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’.