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

[Ludovic Courtès]

Hi Danny,

Danny Milosavljevic <address@hidden> 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’.