udev question
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?
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.
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.
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.
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?