On Tue, 29.03.16 18:15, Nathaniel McCallum ([email protected]) wrote: > I have a rule like this: > > ACTION=="add", SUBSYSTEM=="block", ENV{ID_FS_TYPE}=="crypto_LUKS", > ENV{ID_FS_VERSION}="1", RUN+="sh -c 'echo password | cryptsetup open > $devnode luks-$env{ID_FS_UUID_ENC}'" > > Okay, my real rule isn't so security braindead, but the above will > suffice for concept. :) > > What I find interesting is that the udev events happen backwards in > this case. First, two udev events are generated for the new plaintext > block device and then finally I get the add event for the ciphertext > block device. For instance:
udev dispatches events in an undefined order generally, with one exception: parent devices are processed before child devices. Since in the udev tree the DM devices and the backing devices are not in a parent/child relationship (in fact any relationship at all) their events may be dispatched in any order. Lennart -- Lennart Poettering, Red Hat _______________________________________________ systemd-devel mailing list [email protected] https://lists.freedesktop.org/mailman/listinfo/systemd-devel
