If accessing an automount point triggers more changes to
/proc/self/mountinfo than just to add the directly wanted mount, these
changes can lead to spurious -ENODEV notifications on the automount unit
causing the request to fail when in fact the mount will be setup right
afterwards.
E.g. systemctl --all -t masked gives the list of masked units.
The -t/--type option is reused. This is possible because unit types
and unit load states are called differently, so it is possible to
distinguish what the user meant. Using the same option also means that
the interface is user for the user: less options to remember.
This is useful if your keyfile is a block device, and you want to
use a specific part of it, such as an area between the MBR and the
first partition.
This feature is documented in the Arch wiki[0], and has been supported
by the Arch initscripts, so would be nice to get this into systemd.
This requires libcryptsetup >= 1.4.2 (released 12.4.2012).
Acked-by: Paul Menzel <paulepanter@users.sourceforge.net>
[0]:
<https://wiki.archlinux.org/index.php/System_Encryption_with_LUKS#
Storing_the_key_between_MBR_and_1st_partition>
The MeeGo distribution is still a supported distribution, but
will probably not see an updated version of systemd anymore.
Most of the development is focussing on Tizen now, and the
generic support for building --with-distro=other is more than
adequate enough.
This patch removes the support as a custom configuration build
target in systemd. People who are still building this for
the MeeGo distribution should build as "other" distro.
To be considered by timedated for NTP a package simply has to drop in
/usr/lib/systemd/ntp-units.d/foobar.list and write one or more unit
names into it. The first one listed is the one that is enabled.
This naming convention is more inline with other systemd daemon
unit names (systemd-logind.service, systemd-localed.service etc)
The companion .socket units have also been renamed, however the
-trigger and -settle units keep their current name as these are
not directly related to daemon process itself.
<falconindy> kay: just curious -- it looks like nodes created by udev from
modules.devname all have 000 perms, and there's nothing in udev that attempts
to change this. is it intended?
<falconindy> c--------- 1 root root 10, 223 Jul 1 23:10 uinput
<kay> falconindy: we might miss the default of 0600
<falconindy> seems like it
<kay> falconindy: stuff that has a rule works i guess
<kay> falconindy: i'll add the 0600 now
