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