(cherry picked from commit 33a4c98)

Related: RHEL-6210

(cherry picked from commit 49685fb)

Related: RHEL-6210

(cherry picked from commit 6bbd539)

Related: RHEL-6210

…against cryptsetup

Let's hook it into both cryptsetup-generator and gpt-auto-generator with
a shared implementation in generator.c

Fixes: #8472
(cherry picked from commit a7e8855)

Related: RHEL-6210

For static functions the compiler should figure this out on its own.

(cherry picked from commit 219f3cd)

Related: RHEL-6210

…lter it out

(cherry picked from commit 5de0acf)

Related: RHEL-6210

This catches up with the logic we do for mounts: we create deps based on
/proc/swaps now too, with the right flags set.

(cherry picked from commit 61f9cf4)

Related: RHEL-6210

This catches up with 9d06297 and adapts
the change made to swap units. We generally don't want to react
a-posteriori to swap devices disappearing, bad things will happen
anyway.

(cherry picked from commit e3e6f99)

Related: RHEL-6210

This way we shuld be able to order mounts properly against their backing
services in case complex storage is used (i.e. LUKS), even if the device
path used for mounting the devices is different from the expected device
node of the backing service.

Specifically, if we have a LUKS device /dev/mapper/foo that is mounted
by this name all is trivial as the relationship can be established a
priori easily. But if it is mounted via a /dev/disk/by-uuid/ symlink or
similar we only can relate the device node generated to the one mounted
at the moment the device is actually established. That's because the
UUID of the fs is stored inside the encrypted volume and thus not
knowable until the volume is set up. This patch tries to improve on this
situation: a implicit [email protected] dependency is generated for
all mounts, based on the data from /proc/self/mountinfo, which should be
the actual device node, with all symlinks resolved. This means that as
soon as the mount is established the ordering via [email protected] will
work, and that means during shutdown it is honoured, which is what we
are looking for.

Note that specifying /etc/fstab entries via UUID= for LUKS devices still
sucks and shouldn't be done, because it means we cannot know which LUKS
device to activate to make an fs appear, and that means unless the
volume is set up at boot anyway we can't really handle things
automatically when putting together transactions that need the mount.

(cherry picked from commit 44b0d1f)

Related: RHEL-6210

(cherry picked from commit 68bda07)

Related: RHEL-6210

In particular, let's just say "is" and "must" instead of "may be" and
"should". The weaker forms are obviously correct, but the text is easier to
understand if non-conditional forms are used.

(cherry picked from commit 8e92d92)

Related: RHEL-6210

We want that cryptsetup/veritysetup devices can stick around until the
very end, as well as the users of them which might depend on
[email protected] for the devices. Hence leave the targets around till
the very end.

Note that their runtime is managed via StopWhenUnneeded= anyway, hence
unless their are volumes that actually survive still the very end they
target units will still be stopped.

(cherry picked from commit d120ce478dc0043c89899799b5c1aaf62901bea9)

Related: RHEL-6210

Follow-up for d120ce478dc0043c89899799b5c1aaf62901bea9

[email protected] is used as a synchronization point between
the mount unit and corresponding [email protected].
After the mentioned commit, it doesn't get a stop job enqueued
during shutdown, and thus the stop job for [email protected]
could be run before the mount unit is stopped.

Therefore, let's make [email protected] conflict with umount.target,
which is also what [email protected] does.

Fixes #29336

(cherry picked from commit 99f360a46b6304d87a483be8e09d5e5176be13aa)

Related: RHEL-6210