diff options
| author | Jinyuan Si <jisi@cisco.com> | 2020-12-04 10:38:28 +0800 |
|---|---|---|
| committer | Lennart Poettering <lennart@poettering.net> | 2020-12-10 20:46:00 +0100 |
| commit | 239952e890fd4b53859f84bbc43d910e68a8f6bc (patch) | |
| tree | 2b9a7e5432460f9cf0105f1f9546b070b71eb8d5 | |
| parent | 4add63c79ef5c19c50f4ed36bbd5930146debe5b (diff) | |
| download | systemd-239952e890fd4b53859f84bbc43d910e68a8f6bc.tar.gz | |
cryptsetup: Fix crypto device missing issue after bootup
Normally, the udev rules operate on "change" events. But when
coldplugging, there's an "add" event present. The udev rules have to
recognize this and do some actions in this particular situation, too.
Also, we don't want the nodes to be created prematurely on "add"
events while not coldplugging. The udev rules will check
DM_UDEV_PRIMARY_SOURCE_FLAG to see if the device was activated
correctly before and if not, it ignore the "add" event totally.
This way the udev rules can support udev triggers generating "add"
events (e.g. "udevadm trigger --action=add" or
"echo add > /sys/block/<dm_device>/uevent").
In this case, the udevd service is started after
systemd-cryptsetup@config.service, is started, which will cause udevd
service to miss the "change" uevent with DM_UDEV_PRIMARY_SOURCE_FLAG
flag generated by systemd-cryptsetup@config.service. To solve this
issue, we let the cryptsetup service be started after the udevd
service.
| -rw-r--r-- | src/shared/generator.c | 2 |
1 files changed, 1 insertions, 1 deletions
diff --git a/src/shared/generator.c b/src/shared/generator.c index 4d49b7d52b..1eccc5a289 100644 --- a/src/shared/generator.c +++ b/src/shared/generator.c @@ -564,7 +564,7 @@ int generator_write_cryptsetup_unit_section( fprintf(f, "DefaultDependencies=no\n" "IgnoreOnIsolate=true\n" - "After=cryptsetup-pre.target\n" + "After=cryptsetup-pre.target systemd-udevd-kernel.socket\n" "Before=blockdev@dev-mapper-%%i.target\n" "Wants=blockdev@dev-mapper-%%i.target\n"); |