Compare commits

..

No commits in common. "f27bb6abd3b825034e0dde631ae3047128d2162d" and "13b6c4c8de3d2e5b0157a78f90bde42f846f7d3d" have entirely different histories.

5 changed files with 24 additions and 35 deletions

View File

@ -436,16 +436,27 @@ sensor:modalias:acpi:SMO8500*:dmi:*:svnMEDION:pnAkoyaE2212TMD99720:*
ACCEL_MOUNT_MATRIX=-1, 0, 0; 0, 1, 0; 0, 0, 1
# Medion Akoya E2215T MD60198
sensor:modalias:acpi:KIOX000A*:dmi:*svnMEDION:pnE2215TMD60198:*
ACCEL_MOUNT_MATRIX=0, -1, 0; -1, 0, 0; 0, 0, 1
# Medion Akoya E3216 MD60900
sensor:modalias:acpi:KIOX010A*:dmi:*:svnMEDION*:pnE3216*:*
ACCEL_MOUNT_MATRIX=0, -1, 0; -1, 0, 0; 0, 0, 1
# Medion Akoya E3221 MD61237
# Medion Akoya E2292 MD63390
# Medion Akoya E2293 MD61130
# Medion Akoya E2293 MD61144
sensor:modalias:acpi:KIOX010A*:dmi:*:svnMEDION:pnE3221MD61237:*
ACCEL_MOUNT_MATRIX=0, -1, 0; -1, 0, 0; 0, 0, 1
# Medion Akoya E3222 MD62450
# and presumably all other Akoya Exxxx
sensor:modalias:acpi:KIOX010A*:dmi:*:svnMEDION:pnE*:*
# Medion Akoya E3222
sensor:modalias:acpi:KIOX010A*:dmi:*:svnMEDION:pnMEDION*:*
sensor:modalias:acpi:KIOX010A*:dmi:*:svnMEDION*:pnE3222*:*
ACCEL_MOUNT_MATRIX=0, -1, 0; -1, 0, 0; 0, 0, 1
# Medion Akoya E2292 MD63390
sensor:modalias:acpi:KIOX010A*:dmi:*:svnMEDION:pnE2292MD63390:*
ACCEL_MOUNT_MATRIX=0, -1, 0; -1, 0, 0; 0, 0, 1
# Medion Akoya E2293 MD61130
sensor:modalias:acpi:KIOX010A*:dmi:*:svnMEDION:pnE2293MD61130:*
ACCEL_MOUNT_MATRIX=0, -1, 0; -1, 0, 0; 0, 0, 1
#########################################

View File

@ -190,7 +190,7 @@
<filename>/dev/mapper/home</filename> and <filename>/dev/mapper/srv</filename>. Note that this might
create conflicts if the same partition is listed in <filename>/etc/crypttab</filename> with a different
device mapper device name.</para>
<para>When systemd is running in the initrd the <filename>/</filename> partition may be encrypted in LUKS
format as well. In this case, a device mapper device is set up under the name <filename>/dev/mapper/root</filename>,
and a <filename>sysroot.mount</filename> is set up that mounts the device under <filename>/sysroot</filename>.

View File

@ -63,7 +63,6 @@
<citerefentry project='man-pages'><refentrytitle>ext4</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
btrfs (see
<citerefentry project='man-pages'><refentrytitle>btrfs-man5</refentrytitle><manvolnum>5</manvolnum></citerefentry>),
<citerefentry project='man-pages'><refentrytitle>xfs</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
<!-- yes, that's what the man page is called. -->
and dm-crypt partitions (see
<citerefentry project='die-net'><refentrytitle>cryptsetup</refentrytitle><manvolnum>8</manvolnum></citerefentry>).

View File

@ -1500,29 +1500,8 @@ int time_change_fd(void) {
if (fd < 0)
return -errno;
if (timerfd_settime(fd, TFD_TIMER_ABSTIME|TFD_TIMER_CANCEL_ON_SET, &its, NULL) >= 0)
return TAKE_FD(fd);
if (timerfd_settime(fd, TFD_TIMER_ABSTIME|TFD_TIMER_CANCEL_ON_SET, &its, NULL) < 0)
return -errno;
/* So apparently there are systems where time_t is 64bit, but the kernel actually doesn't support
* 64bit time_t. In that case configuring a timer to TIME_T_MAX will fail with EOPNOTSUPP or a
* similar error. If that's the case let's try with INT32_MAX instead, maybe that works. It's a bit
* of a black magic thing though, but what can we do?
*
* We don't want this code on x86-64, hence let's conditionalize this for systems with 64bit time_t
* but where "long" is shorter than 64bit, i.e. 32bit archs.
*
* See: https://github.com/systemd/systemd/issues/14362 */
#if SIZEOF_TIME_T == 8 && ULONG_MAX < UINT64_MAX
if (ERRNO_IS_NOT_SUPPORTED(errno)) {
static const struct itimerspec its32 = {
.it_value.tv_sec = INT32_MAX,
};
if (timerfd_settime(fd, TFD_TIMER_ABSTIME|TFD_TIMER_CANCEL_ON_SET, &its32, NULL) >= 0)
return TAKE_FD(fd);
}
#endif
return -errno;
return TAKE_FD(fd);
}

View File

@ -11,8 +11,8 @@
Description=Cleanup udevd DB
DefaultDependencies=no
ConditionPathExists=/etc/initrd-release
Conflicts=systemd-udevd.service systemd-udevd-control.socket systemd-udevd-kernel.socket systemd-udev-trigger.service systemd-udev-settle.service
After=systemd-udevd.service systemd-udevd-control.socket systemd-udevd-kernel.socket systemd-udev-trigger.service systemd-udev-settle.service
Conflicts=systemd-udevd.service systemd-udevd-control.socket systemd-udevd-kernel.socket
After=systemd-udevd.service systemd-udevd-control.socket systemd-udevd-kernel.socket
Before=initrd-switch-root.target
[Service]