The GP-electronic T701 has its LCD panel mounted upside-down, initially
my plan was to fix this by transparently rotating the image in the i915
driver (my "drm/i915: Deal with upside-down mounted LCD" patch), but
that approach has been rejected instead the kernel will now export
a "panel orientation" property on the drm-connector for the panel and
let userspace deal with it.
Since the upside-down-ness of the panel is now no longer transparently
hidden from userspace, the current accel mount quirk for the T701 needs
to be updated to take the upside-down-ness into account.
Freescale IMX SoCs serial ports driven by kernel "imx-uart" driver have
names of "ttymxcN", let's add this pattern to an udev rule for serial
ports so they will have proper ownership applied.
The input_id builtin assigns the various ID_INPUT based on the exported evdev
bits. In some cases, the device may not have the properties required to label
a device as one specific type but the physical form factor is clear.
e.g. in the case of #7197 it's a tablet pad that does not have x/y axes which
the kernel exports for pads for historical reasons.
A custom override is needed, best to be solved with a hwdb entry.
Related #7197
https://www.freedesktop.org/wiki/Software/systemd/SystemUpdates/
> This document has been replaced by systemd.offline-updates(7) man page.
It's weird to visit the first "see also", and find that it is what the manpage replaces (and looks very similar). Surely we should remove this link.
This option allows restricting the shown fields in the output modes that
would normally show all fields. It allows clients that are only
interested in a subset of the fields to access those more efficiently.
Also, it makes the resulting size of the output more predictable.
It has no effect on the various `short` output modes, because those
already only show a subset of the fields.
This augments %t which already resolves to the runtime directory root, and
should be useful for units that want to pass any of these paths in
command line arguments.
Example:
ExecStart=/usr/bin/mydaemon --datadir=%S/mydaemon
Why not expose a specifier resolving directly to the configured
state/runtime/cache/log dir? Three reasons:
1. Specifiers should be independent of configuration of the unit itself,
and StateDirectory= and friends are unit configuration. See
03fc9c723c and related work.
2. We permit multiple StateDirectory= values per unit, and it hence
wouldn't be clear which one is passed.
3. We already have %t for the runtime directory root, and we should
continue with the same scheme.
This adds some simply detection logic for cases where dissection is
invoked on an externally created loop device, and partitions have been
detected on it, but partition scanning so far was off. If this is
detected we now print a brief message indicating what the issue is,
instead of failing with a useless EINVAL message the kernel passed to
us.
This adds some basic discovery of block device images for nspawn and
friends. Note that this doesn't add searching for block devices using
udev, but instead expects users to symlink relevant block devices into
/var/lib/machines. Discovery is hence done exactly like for
dir/subvol/raw file images, except that what is found may be a (symlink
to) a block device.
For now, we do not support cloning these images, but removal, renaming
and read-only flags are supported to the point where that makes sense.
Fixe: #6990
If we follow an absolute symlink there's no need to prefix the path with
a "/", since by definition it already has one.
This helps suppressing double "/" in resolved paths containing absolute
symlinks.
Some of the btrfs utility functions already used O_NOFOLLOW others
didn't. Let's streamline this, and refuse operation when we are called
for symlinks on "remove" and "snapshot" too.
In particular in the "remove" case following symlinks is a bad idea, and
is quite different from how unlink() and friends work, which always
remove the symlink, and not the destination, a logic we should follow
here too.
On some devices the display (LCD panel) is mounted non upright
in the device's casing, e.g. mounted upside-down or 90 degree rotated.
Document the expected ACCEL_MOUNT_MATRIX settings for such devices.
This fixes --read-only with --private-users. mkdir_userns_p may return
-EROFS if either mkdir or lchown fails; lchown failing is fine as the
mount point will just be overmounted, and if mkdir fails then the
following mount() will also fail (with ENOENT).
After previous output from systemd-shutdown indicated a bug, my attention
was drawn to redundant output lines. Did they indicate an anomaly?
It turns out to be an expected, harmless result of the current code. But
we don't have much justification to run such redundant operations. Let's
remove the confusing redundant message.
We can stop trying to remount a directory read-only once its mount entry
has successfully been changed to "ro". We can simply let the kernel keep
track of this for us. I don't bother to try and avoid re-parsing the
mountinfo. I appreciate snappy shutdowns, but this code is already
intricate and buggy enough (see issue 7131).
(Disclaimer: At least for the moment, you can't _rely_ on always seeing
suspicious output from systemd-shutdown. By default, you can expect the
kernel to truncate the log output of systemd-shutdown. Ick ick ick!
Because /dev/kmsg is rate-limited by default. Normally it prints a message
"X lines supressed", but we tend to shut down before the timer expires
in this case).
Before:
systemd-shutdown[1]: Remounting '/' read-only with options 'seclabel...
EXT4-fs (vda3): re-mounted. Opts: data=ordered
systemd-shutdown[1]: Remounting '/' read-only with options 'seclabel, ...
EXT4-fs (vda3): re-mounted. Opts: data=ordered
After:
systemd-shutdown[1]: Remounting '/' read-only with options 'seclabel, ...
EXT4-fs (vda3): re-mounted. Opts: data=ordered
I also tested with `systemctl reboot --force`, plus a loopback mount to
cause one of the umounts to fail initially. In this case another 2 lines
of output are removed (out of a larger number of lines).
This creates a second private resolve.conf file which lists the stub resolver
and the resolved acquired search domains.
This runtime file should be used as a symlink target for /etc/resolv.conf such
that non-nss based applications can resolve search domains.
Fixes: #7009
When a user logs in, systemd-pam will wait for the user manager instance to
report readiness. We don't need to wait for all the jobs to finish, it
is enough if the basic startup is done and the user manager is responsive.
systemd --user will now send out a READY=1 notification when either of two
conditions becomes true:
- basic.target/start job is gone,
- the initial transaction is done.
Also fixes#2863.
The current code shifting an integer 1 failed for capabilities like
CAP_MAC_ADMIN (numerical value 33). This caused issues when specifying
them in the nspawn configuration file. Using an uint64_t 1 instead.
The similar code for processing the --capability command line option
was already correctly working.
The vast majority of touchpads are internal, so let's assume that any USB
touchpad is internal by default (exception: bluetooth) and manually mark the
ones that are external. That's a lot more future-proof than having to mark all
internal touchpads that use USB as internal - that number is only going to
increase.
Related to #7068
kmod upstream uses /lib/modprobe.d which means we need to use rootprefix
instead of prefix for installing the modprobe configuration file as
otherwise split-usr systems are broken.
See https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=879191
The assumption was that nothing changes in the final attempt. This
would be confusing if a filesystem with a process in uninterruptible
sleep suddenly became un-stuck for the final attempt, but we still give
up and don't try to e.g. unmount any parent mounts.
I don't know how possible that is. But the code will be easier to read
without an assumption that it does not attempt to justify.
