All of lore.kernel.org
 help / color / mirror / Atom feed
From: Mr Dash Four <mr.dash.four-gM/Ye1E23mwN+BqQ9rBEUg@public.gmane.org>
To: Harald Hoyer <harald-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
Cc: "initramfs-u79uwXL29TY76Z2rM5mHXA@public.gmane.org"
	<initramfs-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>
Subject: Re: udev question
Date: Tue, 26 Oct 2010 12:20:51 +0100	[thread overview]
Message-ID: <4CC6B993.1040808@googlemail.com> (raw)
In-Reply-To: <4CC6B5BD.2020603-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>


>>
>> Am I missing something fundamental here?
>
> udev runs a second time in the real root, just because of this 
> limitation of the initramfs.
Yeah, I sort of figured it out yesterday after running a 'probe' version 
of the '90crypt; module. I have another udev-related query though - if 
multiple rules register for the same udev triggers (like 
ENV{ID_FS_TYPE}=='crypto_LUKS') how are they executed and can the order 
of execution be controlled?

The reason I am asking this is because, as it turns out, I may need to 
design a separate module for smartcard tokens to be used with LUKS and 
the way I see this is when LUKS partition gets matched by udev the 
smartcard module needs to get the first go (for all smartcard-specified 
LUKS partitions) then 90crypt (with key file login, possibly falling 
back on password authentication if the key file data is not successful - 
though this, as far as I can see, is not yet implemented!).

Unfortunately, my udev knowledge is not that much to know is that 
possible, hence the my query.

  parent reply	other threads:[~2010-10-26 11:20 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-10-25 17:46 udev question Mr Dash Four
     [not found] ` <4CC5C26B.9060002-gM/Ye1E23mwN+BqQ9rBEUg@public.gmane.org>
2010-10-26 11:04   ` Harald Hoyer
     [not found]     ` <4CC6B5BD.2020603-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
2010-10-26 11:20       ` Mr Dash Four [this message]
     [not found]         ` <4CC6B993.1040808-gM/Ye1E23mwN+BqQ9rBEUg@public.gmane.org>
2010-10-26 11:24           ` Harald Hoyer
     [not found]             ` <4CC6BA51.5030906-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
2010-10-26 11:30               ` Mr Dash Four
  -- strict thread matches above, loose matches on Subject: below --
2006-07-05 17:08 Udev question Vallimar
2006-07-05 17:21 ` Kay Sievers
2006-07-05 23:14 ` Vallimar
2006-07-06  9:48 ` Kay Sievers
2006-07-21 17:58 ` udev question Lukas Hejtmanek

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4CC6B993.1040808@googlemail.com \
    --to=mr.dash.four-gm/ye1e23mwn+bqq9rbeug@public.gmane.org \
    --cc=harald-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org \
    --cc=initramfs-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.