Up to now each uevent logs the following things at debug level:
- Device is queued
- Processing device
- Device processed
However when the device is queued it might still have to wait for
earlier devices to be processed before being able to start being
processed itself. When analysing logs this dependency information is
quite cruicial, so add respective debug log calls.
Add SECLABEL{selinux}="some value" cause udevadm crash
systemd-udevd[x]: Worker [x] terminated by signal 11 (SEGV)
It happens since 25de7aa7b9 (Yu Watanabe 2019-04-25 01:21:11 +0200)
when udev rules processing changed to token model. Yu forgot store
attr to SECLABEL token so fix it.
In case the dissected image has a filesystem, don't scan for partitions. This
avoids problems with services using a `RootImage=` in early boot when udevd is
not yet started.
/dev used to be mounted with "exec" flag due to /dev/MAKEDEV script but that's
history and it's now located in /sbin. mmap() with file descriptor to
"/dev/zero" (instead of modern mmap(,,,MAP_ANON...)) will still work.
ARM toolchains will sometimes optimize otherwise floating-point-free
code with floating point and SIMD instructions. This was happening with
systemd-bootarm.efi and it was causing U-Boot to crash and reset the
CPU. U-Boot does not support the ARM VFP floating point coprocessor,
which is an optional piece of hardware anyway [1].
Ensure the compiler does not generate FP/SIMD instructions by supplying
the `-mgeneral-regs-only` option when building for ARM [2].
The other option you often see to solve these problems is
`-msoft-float`, but that changes the ABI and prevents linking with
libgnuefi.
[1] https://lists.denx.de/pipermail/u-boot/2011-February/087736.html
[2] https://gcc.gnu.org/onlinedocs/gcc/ARM-Options.html#index-mgeneral-regs-only-1
I assume it’s supposed to be “see Home Directories for details” and not
“… and embeds these JSON records directly in the home directory images …
for details”, but the previous text suggested the latter reading to me.
Widely accepted certificates for IP addresses are expensive and only
affordable for larger organizations. Therefore if the user provides
the hostname in the DNS= option, we should use it instead of the IP
address.
When using the cgroups IO controller, the device that is controlled
should always be the toplevel block device. This did not get resolved
correctly for an LVM volume inside a LUKS device, because the code would
only resolve one level of indirection.
Fix this by recursively looking up the originating block device for DM
devices.
Resolves: #15008
Possible alternative to #14819.
For me, setting RemainAfterExit=yes would be OK, but if people think that it
might cause issues, then this could be a reasonable alternative that still
let's us skip the invocation of the separate binary.
As in 2a5fcfae02
and in 3e67e5c992
using /usr/bin/env allows bash to be looked up in PATH
rather than being hard-coded.
As with the previous changes the same arguments apply
- distributions have scripts to rewrite shebangs on installation and
they know what locations to rely on.
- For tests/compilation we should rather rely on the user to have setup
there PATH correctly.
In particular this makes testing from git easier on NixOS where do not provide
/bin/bash to improve compose-ability.
UnitStatusMessageFormats.finished_job, if present,
will be called with the same arguments as
job_get_done_status_message_format() to provide a format string
appropriate for the context
This commit replaces "Started" with "Finished" for started oneshot
units, as mentioned in the referenced issue
Closes#2458.
This reverts the second part of 8125e8d38e.
The first part was reverted in 750e550eba.
The problem starts when s-v-s.s is pulled in by something that is then pulled
in by sysinit.target. Every time a unit is started, systemd recursively checks
all dependencies, and since sysinit.target is pull in by almost anything, we'll
start s-v-s.s over and over. In particular, plymouth-start.service currently
has Wants=s-v-s.s and After=s-v-s.s.
This minus has been there since the unit was added in
d42d27ead9. I think the idea was not cause things
to fail if the user instance doesn't work. But ignoring the return value
doesn't seem to be the right way to approach the problem. In particular, if
the program fails to run, we'll get a bogus fail state, see
https://bugzilla.redhat.com/show_bug.cgi?id=1727895#c1:
with the minus:
$ systemctl start user@1002
Job for user@1002.service failed because the service did not take the steps required by its unit configuration.
See "systemctl status user@1002.service" and "journalctl -xe" for details.
without the minus:
$ systemctl start user@1002
Job for user@1002.service failed because the control process exited with error code.
See "systemctl status user@1002.service" and "journalctl -xe" for details.