[Pkg-cryptsetup-devel] Questions about cryptsetup/initramfs

David Härdeman david at hardeman.nu
Tue Jul 1 18:31:25 UTC 2008


On Wed, Jun 25, 2008 at 12:01:01AM +0200, Christoph Anton Mitterer wrote:
>On Tue, 2008-06-24 at 23:33 +0200, David Härdeman wrote:
>> Riddle me this....read the LUKS specification 
>> (http://luks.endorphin.org/LUKS-on-disk-format.pdf) and find where any 
>> label would be stored...
>What do you mean?
>I've already looked through it before and was not able to find anything
>where a LABEL could be stored, can you?
>I've even contacted Clemens Furwith some days ago,.. but he seems to be
>busy.

Exactly, that was my point, LUKS headers do not support any labels so 
we can't support any label for luks headers.

>> >The problems with this go even further:
>> >1) while grub-pc (grub2) detects that it mus set root=
>> >to /dev/mapper/sda2 it seems not to be able to use it's UUID (as it does
>> >per default with non-dm-crypt-devices).
>--> why doesn't update-grub use UUID on dm-crypt-root-filesystems but on
>non-dm-crypt root filesystems?

I think the point of my previous mail was that you should/could 
investigate that yourself rather than asking us.

>But this is probably a "bug" in grub?

See above.

>> >2) When I e.g. use LABEL= in fstab, but device-names (/dev/sda or so) in
>> >crypttab,.. cryptsetup was not able to detect root and didn't write
>> >this /conf/conf.d/cryptroot (in the initrd).
>If for example I use LABEL in fstab but device-names in crypttab,... the
>root-filesystem is not found,... and the initrd doesn't contain the
>necessary stuff.

I see, that is probably something we should fix.

>> Read udev sources (the answer is...of course it can, label and uuid are 
>> stored on disk, userspace can read the disk...)
>Of course userspace can read this,.. but how should userspace know which
>devices it should probe? What if people change their udev rules to
>produce different names (e.g. /dev/___sdaX).
>That was the reason why I didn't believe that udev is the source of
>information WHICH devices are looked at but the kernel (via proc).
>
>Anyway,... I've asked this just out of curiosity and you don't have to
>waste your time in answering this.

Again, the answer can be found by some simple research. The kernel sends 
a netlink event for each blockdev that is added, udev reacts by calling 
a helper script which reads the label and uuid from the blockdev (in 
userspace) and creates links accordingly.

>btw: In the meantime Werner Koch found out why gpg (and perhaps other
>applications, too) have this no-tty-found problem in an initrd...
>While my current but surely poor workaround (move /dev/tty away and ln
>-s console to it) works it is probably no very professional.
>The reasons seems to be that there is no controlling terminal available
>at all and one would have to be set up (which seems to be not very
>easy).

I'm guessing that it might be sufficient to call gpg with the proper 
redirections....something like:

gpg < /dev/console > /dev/console 2>&1

This is how many functions are called right now in the crypsetup 
initramfs script.

-- 
David Härdeman



More information about the pkg-cryptsetup-devel mailing list