Skip to contentSkip to conversation

udev question

DISCUSSION Mr Dash Four 2 participants 5 messages Oct 25, 2010 – Oct 26, 2010 4 messages not in the archive

lore
Share & tools
lore
#0 lore raw

A simple question: in /etc/udev/rules.d/ (on the root partition!) I have a .rules file for one of my smartcard devices which has, among other things, this statement:

PROGRAM="/bin/sleep 0.1"

This program is not on the initramfs image, but it is in the /bin directory on the root partition. I was under the impression that root is not mounted until udev has finished its job - is that not the case? If so, how is this program executed then? I also have a lot of other statements with RUN+=... which also refer to executables not present in initramfs - they are all present in the root partition. When/How do these execute then?

Am I missing something fundamental here?

A message that is not in the archive (sent off-list or not yet received): 4CC5C26B.9060002-gM/[email protected]

#2 lore raw
Quoted 6 lines · Mr Dash Four

A simple question: in /etc/udev/rules.d/ (on the root partition!) I have a .rules file for one of my smartcard devices which has, among other things, this statement:

PROGRAM="/bin/sleep 0.1"

Quoted 8 lines

This program is not on the initramfs image, but it is in the /bin directory on the root partition. I was under the impression that root is not mounted until udev has finished its job - is that not the case? If so, how is this program executed then? I also have a lot of other statements with RUN+=... which also refer to executables not present in initramfs - they are all present in the root partition. When/How do these execute then?

Am I missing something fundamental here?

udev runs a second time in the real root, just because of this limitation of the initramfs.

A message that is not in the archive (sent off-list or not yet received): [email protected]

#4 lore raw
Quoted 5 lines
Quoted 3 lines

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.

A message that is not in the archive (sent off-list or not yet received): 4CC6B993.1040808-gM/[email protected]

#6 lore raw
Quoted 19 lines · Mr Dash Four
Quoted 6 lines
Quoted 3 lines

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

Quoted 2 lines

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.

A message that is not in the archive (sent off-list or not yet received): [email protected]

#8 lore raw
Quoted 5 lines
Quoted 3 lines

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.

In other words if I do udev/rules.d/65token.rules that should be enough, right? I also presume that once the /tmp/crypt-root-asked-$2 is set 90crypt won't touch it. Is that right?