[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#21843: Generated grub.cfg does not support encrypted roots
From: |
Ludovic Courtès |
Subject: |
bug#21843: Generated grub.cfg does not support encrypted roots |
Date: |
Fri, 11 Mar 2016 09:45:07 +0100 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/24.5 (gnu/linux) |
Andreas Enge <address@hidden> skribis:
> On Thu, Mar 10, 2016 at 10:17:46AM +0100, Ludovic Courtès wrote:
>> IIUC we don’t *have* to pass the UUID to ‘cryptomount’; we could also
>> pass the device name, in GRUB format
>
> Yes, but my idea was that the uuid is something we can determine
> at instantiation time. If the mapped device is /dev/sdd3, we can run
> (system* "cryptsetup" "luksUUID" "/dev/sdd3")
> and obtain the uuid.
Hmm yeah, but we don’t even do that for regular partitions.
> I suppose we could also use the grub device (hd3,msdos3) in this case,
> but I do not know what is the mapping between /dev nodes and these devices,
> and if it is actually a function that could be computed from the file name
> in /dev only or not.
‘grub-probe’ should know, I think.
>> (mapped-device
>> (source (uuid "cb67fc72-0d54-4c88-9d4b-b225f30b0f44")) ;LUKS UUID
>> (target "root")
>> (type luks-device-mapping))
>> we’d have to extend <mapped-device-kind> with a method to resolve UUIDs
>> (in this case, to map a UUID to a /dev node.)
>
> We can also let the users do the work (and document this in the manual),
> by having them supply all the informatin:
>
> (mapped-device
> (source "/dev/sdd3")
> (uuid "cb67fc72-0d54-4c88-9d4b-b225f30b0f44") ;LUKS UUID
> (target "root")
> (type luks-device-mapping)
> (needed-for-boot? #t))
I think the goal of providing a UUID is to not have to worry about the
actual device name (which could change).
The ‘needed-for-boot?’ flag should be unnecessary because it can be
inferred from corresponding file systems, as is already the case.
>> Besides, I think we should only worry about the mapped device(s) that
>> back / and /boot, rather than any mapped device, no?
>
> This could either be solved by determining which file systems have
> needed-for-boot? #t and determine the corresponding mapped devices,
> or by adding such a parameter for the mapped-device as in my suggestion
> above.
>
> Or we do it all automatically for / and /boot and drop the parameter
> needed-for-boot? everywhere.
We keep it only in ‘file-system’, I think.
Anyway, sounds like quite a bit of work here. :-)
Ludo’.