Although it may be true that /sysroot and its children don't belong in
local-fs.target, that doesn't mean they shouldn't come after
local-fs-pre.target. For instance, systemd-hibernate-resume@.service needs to
come before /sysroot and its children, but currently that only happens
coincidentally because of the ordering between systemd-fsck@.service and
local-fs-pre.target. As a result, mount units can be mistakenly started
simultaneously with systemd-hibernate-resume@.service, which can cause
corruption and data loss in the worst of cases.
On Debian the test fails because /run is noexec. Simply create the
script in /tmp (and use a BindPath=), as other tests are doing.
Follow-up for 3b7101183c
Let's invoke dissected_image_decrypt_interactively() at once place only,
instead of in each function separately.
No actual changes, just some minor refactoring.
In various tools and services we have a per-system and per-user concept.
So far we sometimes used a boolean indicating whether we are in system
mode, or a reversed boolean indicating whether we are in user mode, or
the LookupScope enum used by the lookup path logic.
Let's address that, in introduce a common enum for this, we can use all
across the board.
This is mostly just search/replace, no actual code changes.
This enables the ManagerEnvironment= settings in the user's user.conf to
reference some user data like $HOME for the purpose of setting
environment variables derived from these values.
This changes the PSI window duration we default to for watching memory
pressure events from 1s to 2s. This is because apparently the kernel
will soon disallow window durations other than 2s for unprivileged
processes.
Hence, we'll bump the threshold from 100m to 200ms, and the window from
1s to 2s.
This way we'll have the same mount options in place if we boot via the
gpt generator, or if we mount a DDI locally.
Note that this will also enable MS_NOSYMFOLLOW on ESP and XBOOTLDR now,
if booted via gpt-auto-generator.
When we mount a DDI, let's set MS_NOSYMFOLLOW for ESP/XBOOTLDR. They are
generally untrusted territory, (i.e. outside of
encryption/authentication via dm-crypt/dm-verity). Moreover they are
generally FAT, where symlinks don't exist anyway. Let's hence disable
symlinks for them.
This slightly refactors how we put together mount options for mounts,
splitting this out into a new helper call
dissected_partition_pick_options(), which we should be able to reuse
later in gpt-auto-generator, to ensure mounts via loopback as DDI and
those on bare metal get the same options.
This adds symlinks that allow accessing loopback block devices via stable
names that reference their backing block devices, make the unpredictable
naming of loopback devices less of an issue.
Example:
1. Create a loopback block device for a file $F
losetup --find $F
2. Reference the backing block device via its inode:
L="$(stat -c '/dev/loop/by-inode/%Hd:%Ld-%i' $F)"
fdisk $L
In the above the loop device name (which might be /dev/loop47 or any
other name) is not used at all.
When attaching a loopback file this allows us to set an explicit name
for it. This is useful since it allows a caller to pre-select a string
that is directly attached to the loopback file. Via udev rules we'l
later make the device accessible through this name.
Note that "lo_file_name" is supposed to carry a file name of the backing
file, but the kernel actually does not care or enforce any of that, it
just stores the filename and returns it later. This makes it so useful,
as userspace has total control of that field.
"lo_file_name" should not be confused with the sysattr
"loop/backing_file" which is actually maintained by the kernel itself,
and always shows the file to the backing inode without userspace having
direct control over the returned string. Because the sysattr is
generated by the kernel it is subject to file system namespacing and
everything, while "lo_file_name" is not, it's really just a string
passed through the kernel.