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

On 10/26/2010 01:20 PM, Mr Dash Four wrote:
>
>>>
>>> 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.

place it in a udev rules file with a lower number... first come, first serve.

  parent reply	other threads:[~2010-10-26 11:24 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
     [not found]         ` <4CC6B993.1040808-gM/Ye1E23mwN+BqQ9rBEUg@public.gmane.org>
2010-10-26 11:24           ` Harald Hoyer [this message]
     [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=4CC6BA51.5030906@redhat.com \
    --to=harald-h+wxahxf7alqt0dzr+alfa@public.gmane.org \
    --cc=initramfs-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
    --cc=mr.dash.four-gM/Ye1E23mwN+BqQ9rBEUg@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.