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

[David Härdeman]

On Wed, July 9, 2008 00:15, Christoph Anton Mitterer wrote:
> On Tue, 2008-07-01 at 20:31 +0200, David Härdeman wrote:
>>
>> Exactly, that was my point, LUKS headers do not support any labels so
>> we can't support any label for luks headers.
>
> Yes,... but (at least in)
> /usr/share/initramfs-tools/scripts/local-top/cryptroot
> "you" seem to use it.
>
> As far as I understand, parse_options() parses the option for the LUKS
> partition, right?
>
> And there we have:
>>elif [ ${cryptsource#LABEL=} != $cryptsource ]; then
>>	cryptsource="/dev/disk/by-label/${cryptsource#LABEL=}"

parse_options() parses the options for the LUKS *or* dm-crypt partition.
If the user has specified a label, a label is what the script should look
for, whether LUKS supports labels or not is a completely different issue.
Linux md-raid devices *do* for instance support labels (and other future
yet-unknown blockdevs might as well).

>> I think the point of my previous mail was that you should/could
>> investigate that yourself rather than asking us.
>>
> I had a little discussion about this with Jonas. I see your point of
> view, but you should also see that I have only limited time, too, and
> for me this is only a little project (not cryptsetup, but that what I'd
> like to contribute to it).
>
> And for some of the questions that seem to be simple for you, I'd
> require a lot of time to find the answer,... understand what I mean? :-)

Yes, I understand what you mean, but your conclusion is flawed.

First, suppose you have a question, in finding an answer you can either:

a) spend 20 minutes researching the answer yourself; or

b) spend 5 minutes writing an email asking someone else for the answer,
that person then spends 5 minutes finding your answer and another 5
minutes writing up a reply.

With alternative a) you'll leave "someone else" with more spare time,
you'll learn something and you'll later also show that you've done your
homework when you post patches *or* ask question which you absolutely
*can't* find the answer to (for instance, the controlling-terminal
question below which is a reasonable question...terminal handling is
grotty).

With alternative b), "someone else" will spend her personal hacking-time
answering questions instead.

Second, if your logic was sound, we should forward all questions to Alan
Cox: I was once debugging a sound card driver once and I was scratching my
head over how some piece of code was supposed to work. Hours of grepping
gave no result so I sent him an email. I got the answer literally less
than a minute later (ie. he knew the answer by heart and not by looking at
any source). What takes you 20 minutes to find an answer to perhaps takes
me 5 minutes and Alan Cox 1 minute. Every question should therefore go to
Alan?

Sorry if I come across as a condescending fecal exit, it's certainly not
my objective, I don't want this list to look like
openbsd-pkg-cryptsetup-devel :)

Anyway, we seem to be digressing even more from the technical arguments
here...

>>> 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.
>>
> Is there a way I can help you with this?

Patches? :)

>>> 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:
...
> I've tried exactly the same (and all other possible redirections that
> made sense for me),... but non of them worked...

I see. If gpg can't be convinced to use something else than /dev/tty (are
you sure it can't?), it might be an idea to patch initramfs-tools (or
klibc) so that it sets up the controlling console to /dev/console as early
as possible in the boot process. That should also be valuable to any
shells running in the initramfs (I think some shells, like busybox, have
automagic controlling console setup though). I think I'll ask the
initramfs-tools/klibc maintainer about it...

-- 
David Härdeman