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

[Christoph Anton Mitterer]

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.


> >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?
But this is probably a "bug" in grub?

> >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 have no idea what the question is...
see above...
What's not clear?


> >However,.. in the meantime I've read in the kernel docs
> >(Documentation/inird.txt or so) that in the "new way" this should be set
> >to /dev/ram0 ... so I assume Debian's initrd still use the "old way".
> >Is this going to be changed, David?
> 
> I'll answer a question with a question....is an initrd the same as an 
> initramfs environment? (Google will tell you)


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


> It ain't rocket science...


> Answer:
> In the future, we may see uuid's which are just simple character
> strings (see the DDF Raid Specification). For that reason vol_id now
> exports ID_FS_UUID_SAFE, just like ID_FS_LABEL_SAFE. For things like
> the creation of symlinks, the *_SAFE values ensure, that no control
> or whitespace characters are used in the filename.
Ah I see...



> Yes. Which is why the cryptsetup initramfs script and hook includes swap 
> information whenever possible in the initramfs.
ok



I have the feeling that I might have asked too much questions to this
list or proposed to much changes... I'll try to avoid this in the future
and draw back from any unecessary, non-backwards-compatible,
hard-to-implement, etc. proposals I've made.

Anybody know what I've suggested (from my very long mail),... if it is
wanted that I try (I'm not a Debian developer as anyone will notice,
thus that many questions..) to help in implementing them, I ask that it
is told to me how I should do/solve the open questions (prereqs-param or
not, etc.etc.).

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).
If anyone wants the info from Werner,.. he can ask me and I'll provide
it to him.



cam.