diff options
author | Jonathan Lebon <jonathan@jlebon.com> | 2020-10-20 22:30:20 +0200 |
---|---|---|
committer | Lennart Poettering <lennart@poettering.net> | 2020-10-21 22:08:19 +0200 |
commit | 6c5496c492a8d74e54d22bf8824160cab1e63c10 (patch) | |
tree | 5dd28fa028c3d690e41449870037a24bac6a7152 /units/systemd-homed-activate.service | |
parent | Merge pull request #17356 from yuwata/sd-xxx-stop (diff) | |
download | systemd-6c5496c492a8d74e54d22bf8824160cab1e63c10.tar.xz systemd-6c5496c492a8d74e54d22bf8824160cab1e63c10.zip |
units: add initrd-cryptsetup.target
For encrypted block devices that we need to unlock from the initramfs,
we currently rely on dracut shipping `cryptsetup.target`. This works,
but doesn't cover the case where the encrypted block device requires
networking (i.e. the `remote-cryptsetup.target` version). That target
however is traditionally dynamically enabled.
Instead, let's rework things here by adding a `initrd-cryptsetup.target`
specifically for initramfs encrypted block device setup. This plays the
role of both `cryptsetup.target` and `remote-cryptsetup.target` in the
initramfs.
Then, adapt `systemd-cryptsetup-generator` to hook all generated
services to this new unit when running from the initrd. This is
analogous to `systemd-fstab-generator` hooking all mounts to
`initrd-fs.target`, regardless of whether they're network-backed or not.
Diffstat (limited to 'units/systemd-homed-activate.service')
0 files changed, 0 insertions, 0 deletions