summaryrefslogtreecommitdiffstats
path: root/units/systemd-journald@.socket
diff options
context:
space:
mode:
authorJonathan Lebon <jonathan@jlebon.com>2020-10-20 22:30:20 +0200
committerLennart Poettering <lennart@poettering.net>2020-10-21 22:08:19 +0200
commit6c5496c492a8d74e54d22bf8824160cab1e63c10 (patch)
tree5dd28fa028c3d690e41449870037a24bac6a7152 /units/systemd-journald@.socket
parentMerge pull request #17356 from yuwata/sd-xxx-stop (diff)
downloadsystemd-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-journald@.socket')
0 files changed, 0 insertions, 0 deletions