Currently translated at 100.0% (286 of 286 strings)
po: Translated using Weblate (Finnish)
Currently translated at 100.0% (286 of 286 strings)
po: Translated using Weblate (Finnish)
Currently translated at 100.0% (286 of 286 strings)
po: Translated using Weblate (Finnish)
Currently translated at 100.0% (286 of 286 strings)
po: Translated using Weblate (Finnish)
Currently translated at 100.0% (286 of 286 strings)
po: Translated using Weblate (Finnish)
Currently translated at 100.0% (286 of 286 strings)
po: Translated using Weblate (Finnish)
Currently translated at 100.0% (286 of 286 strings)
po: Translated using Weblate (Finnish)
Currently translated at 100.0% (286 of 286 strings)
po: Translated using Weblate (Finnish)
Currently translated at 100.0% (286 of 286 strings)
po: Translated using Weblate (Finnish)
Currently translated at 100.0% (286 of 286 strings)
po: Translated using Weblate (Finnish)
Currently translated at 100.0% (286 of 286 strings)
po: Translated using Weblate (Finnish)
Currently translated at 100.0% (286 of 286 strings)
po: Translated using Weblate (Finnish)
Currently translated at 100.0% (286 of 286 strings)
po: Translated using Weblate (Finnish)
Currently translated at 100.0% (286 of 286 strings)
po: Translated using Weblate (Finnish)
Currently translated at 100.0% (286 of 286 strings)
Co-authored-by: Weblate Translation Memory <noreply-mt-weblate-translation-memory@weblate.org>
Translate-URL: https://translate.fedoraproject.org/projects/systemd/main/fi/
Translation: systemd/main
The Claude review workflow posted long, padded inline comments, and every
force push produced a fresh batch of new findings on code that had not
changed. Both make authors stop reading the reviews.
Add a comment style section to the prompt that limits each comment to the
problem and the obvious fix, and truncate anything over 1000 characters in
the post job. Track the number of completed reviews and the last reviewed
head in a hidden state line in the tracking comment. Each successful review
narrows the severities that may be posted: everything on the first review,
no nits on the second, and only must-fix findings from the third on. The
post job enforces the policy so it holds even if the model ignores the
prompt, and reviewers are told to range-diff against the previous head and
skip non-must-fix findings on unchanged code. Commenting "@claude review
full" resets the count for that run.
`TEST-23-UNIT-FILE.dbus-reconnect.sh` SIGKILLs `dbus.service` three
times. Nothing reconnects to the new broker, so logind keeps running
with `org.freedesktop.login1` unowned for the rest of the boot —
activation can't fix it either, as `dbus-org.freedesktop.login1.service`
is already active, so the job finishes at once and the name never
returns.
That leaks into the subtests after it. `statedir.sh`, the first to start
`user@0.service`, spends 2 × 25 s in user-runtime-dir on logind
properties, and where pam_systemd can't use Varlink (memory-max= & co.
in the PAM stack) it blocks in `CreateSession()` for 2 min, past
user@.service's 90 s TimeoutStartSec — failing, and pointing at a
subtest that has nothing to do with the bus.
Hit this in hyperscale v261.3 release test for centos9:
https://artifacts.dev.testing-farm.io/01c1c68b-da64-4b9e-b163-eb3459aabe79/work-upstreamjejyd7ep/log.txt
Killing the broker is destructive well beyond the units under test: nothing
reconnects to the new one, so logind for instance keeps running with
org.freedesktop.login1 unowned for the rest of the boot. As a subtest of
TEST-23-UNIT-FILE that leaked into everything running after it, and
statedir.sh, the first one to start user@0.service, then spent 25s per logind
property in user-runtime-dir and, where pam_systemd can't use Varlink, blocked
in CreateSession() past user@.service's 90s TimeoutStartSec and failed — with
the failure pointing at a subtest that has nothing to do with the bus.
In its own test the damage dies with the machine.
The flags to pass to symlinkat_atomic_full are defined in the
SymlinkFlags enum type. The previous code passed the result of a boolean
check operation directly instead of using flags.
Be explicit about the value to pass instead of relying on true
corresponding to the enum value for the SYMLINK_MAKE_RELATIVE flag.
Signed-off-by: Daniel Wagenknecht <dwagenknecht@emlix.com>
-ENODATA is returned when the message carries no (reply) cookie, but the
text stated the message "carries a reply cookie field". Say it does not
carry one.
- It does not accept NUL for type.
- ret_size is zero and ret_ptr is non-NULL when it returns positive.
- Fixed argument names: ptr -> ret_ptr, size -> ret_size.
The imds-network= meson option has never had an effect on the generated
network configuration. It arrived in 168a7f7770 together with the IMDS
generator, which wired IMDS_NETWORK_LOCKED_DEFAULT (turned into
IMDS_NETWORK_DEFAULT by c3e4e8a527) into the generator's
arg_network_mode. But the generator only ever compares that variable
against IMDS_NETWORK_OFF, to decide whether to pull
systemd-imds-early-network.service into the initial transaction, and
"off" is not one of the option's choices. It also never forwards the
mode on to systemd-imds-early-network.service, neither as a command
line switch nor via a drop-in.
85-imds-early.network is written by systemd-imds-early-network.service,
which runs "systemd-imdsd --setup-network", and that code path's
arg_network_mode was left at _IMDS_NETWORK_MODE_INVALID. As
setup_network() requires "!= IMDS_NETWORK_UNLOCKED" before emitting the
"prohibit" routes, the unset sentinel behaves exactly like "locked".
At first that went unnoticed, because the option defaulted to "locked"
as well: the documented default matched the implemented behaviour by
accident, and only "-Dimds-network=unlocked" was quietly ignored.
6240d420d6 ("meson: unlock imds network by default") then flipped the
default by reordering the option's choices, i.e. moved a macro that
nothing consumed. From that point on the default was wrong for
everybody: unless systemd.imds.network= is passed on the kernel command
line, every generated network file locks the IMDS endpoint down, no
matter how the build is configured. ac64b2dfa3 later documented the new
default in man:systemd-imdsd@.service(8) (#42687), which meant the
documentation now described behaviour that does not exist.
In practice this rarely became visible until the previous commit, since
systemd-imdsd --setup-network mostly lost its race against udev and
wrote no network file at all.
Initialize arg_network_mode from IMDS_NETWORK_DEFAULT, the same way
imds-generator.c does. No other code distinguishes the INVALID sentinel
from a real mode; the remaining users compare against IMDS_NETWORK_OFF
and IMDS_NETWORK_UNLOCKED only. The kernel command line still overrides
the build-time default, and the only difference in the generated network
file are the two "prohibit" routes: the fwmark routing table and the
matching routing policy rule are written in either mode, as before.
systemd-imds-early-network.service carries
After=sys-devices-virtual-dmi-id.device, so that systemd-imdsd
--setup-network sees the IMDS_* properties that udev applies to the DMI
device from hwdb data. Ordering dependencies only take effect if both
units are part of the same transaction though, and nothing ever pulled
the device unit in: the generator hooks the service into
sysinit.target.wants/ only, and the unit sets DefaultDependencies=no.
The ordering was therefore a nop, and the service raced udev's
coldplugging.
When it lost that race the failure was silent: smbios_server_info()
found no IMDS_VENDOR= property, so no endpoint got configured,
cmdline_run() returned EXIT_NOTCONFIGURED, the unit's
SuccessExitStatus=NOTCONFIGURED reported that as success, and no
85-imds-early.network was written at all.
Give the unit the same drop-in we already write for
systemd-imdsd@.service, which adds Wants= in addition to After= for the
device unit, and factor it out into a helper. We only get here once the
DMI device has been found in the hwdb, hence pulling the device unit
into the transaction is safe.
Note that with the race fixed I have yet to see systemd-imdsd actually
work in locked mode: it appears to end up locked out by the "prohibit"
route itself, despite the fwmark bypass. That is a separate issue, and
left for somebody else to look into.
This undoes some of the work in #43603 which was a follow-up to #42900
which – unintentionally I'd claim – renamed some JSON fields. Instead of
setting those changes in stone we should undo them.
Not just to not needlessly break compat, but more importantly because
the old names made more sense given the underlying .feature file knobs.
Similar as the previous commit: the field was renamed by accident, and
we should revert to the old name to not break compat needlessly, and
because the old name actually made sense, given the underlying .transfer
file knob is AppStream=
The "isEnabled" name was changed from "enabled" post v261 by accident
(because a6f7ded859 replaced json
formatting via table formatter to a native json generator which was
introduced for varlink, which changed the names). THis was later made
official in #43603, but it should rather have changed things back to the
original name, in particular as the underling .feature file field
actually is called "Enabled=" and not "IsEnabled=".
We really should take care to generate the same names for Varlink JSON
data as for the data returned by the systemd-sysupdate cli.
a6f7ded859 ensured that, so that's great.
But at the same time I think the varlink names should be adjusted to the
old names, since varlink support for this was just added in this cycle.
Given that v262 is not tagged yet, let's now revert to the old name.
This adds a fallback to `blockdev_get_root`, to handle the case where
`/usr` is a sysext overlay. Additinal changes are:
- move `extension_overlay_block` to `extension-util.h`, and make it
generic to work in both confext and sysext cases (though only sysext is
actually used currently)
- add a usr-only integration test to exercise the failure
Closes#43565.
The `systemd-nspawn` manpage says:
The `--private-users-ownership=auto` option is implied if
`--private-users=pick` is used.
This is true for the CLI, but not when set in a `.nspawn` file.
Assuming these defaults should be the same across both.
This default was also not updated when `managed` was added by #35685.
As a result, this is a change in behavior for users who didn't set an
explicit `PrivateUsersOwnership=` value in their `.nspawn` file.
`store_loadavg_fixed_point()` guarded both of its `<<
LOADAVG_PRECISION_BITS` shifts against overflow, but neither guard was
effective:
- The integer part was rejected with `i >= (~0UL <<
LOADAVG_PRECISION_BITS)`. The shift direction is inverted: that bound is
`0xFFFFFFFFFFFFF800`, so it only rejects the topmost 2048 values of the
range, while the smallest value that actually overflows `i << 11` is
`2^53`. Everything from `2^53` up shifted out of the word and was
accepted.
- The fractional part was shifted first and range-checked afterwards, so
a large `f` wrapped to a small value and then passed the `f >=
LOADAVG_FIXED_POINT_1_0` test.
Concretely, on 64 bit:
```
parse_loadavg_fixed_point("9007199254740992.00", &fp) -> 0, fp == 0 (load reported as 0.00)
parse_loadavg_fixed_point("1.9007199254740992", &fp) -> 0, fp == 1.00
```
Both should be `-ERANGE`. The existing
`ASSERT_ERROR(..."18446744073709551615.5"..., ERANGE)` passes only
because `~0UL` happens to fall inside the narrow band the broken guard
does catch.
Validate both parts before shifting instead. Rejecting `f >= 100` is
exactly equivalent to the old post-shift comparison for every input that
previously succeeded, since `DIV_ROUND_UP(99 << 11, 100) == 2028` and
`DIV_ROUND_UP(100 << 11, 100) == 2048`, so there is no behaviour change
for valid input; only the values that used to wrap are now rejected.
Note this is a latent bug rather than a live one: the only caller of
`parse_loadavg_fixed_point()` is `read_resource_pressure()`, which
parses kernel-generated `/proc/pressure/*` and cgroup `memory.pressure`
files where values are capped at `100.00`, and every direct
`store_loadavg_fixed_point()` caller passes permyriad-derived values
already clamped to 0...10000. Fixing the guards keeps the helper correct
for future callers.
Covered by new cases in `test-parse-util`, including the largest integer
part that must still be accepted (`2^53-1`).
Recently switched to Linux on my Dell Precision 7510 and noticed a
jittery/shaking effect when scrolling slowly with the touchpad, across
multiple applications.
libinput measure fuzz reported no fuzz value set for the touchpad's
axes, which explains the jitter (sensor noise being read as real
motion). Used libinput measure fuzz --fuzz=28 to generate and apply a
hwdb override, then confirmed scrolling was smooth afterward.
Added a new entry to hwdb/60-evdev.hwdb for this device:
evdev:name:AlpsPS/2 ALPS DualPoint
TouchPad:dmi:*:svnDellInc.*:pnPrecision7510*:
This is the same touchpad family as #34133 (Dell Latitude E7440), which
hit the same symptom and fix — this PR extends the coverage to the
Precision 7510.
On the ThinkBook 14 G7 ARP (21MV), ideapad-laptop is bound to both the ACPI
device (VPC2004:00) and the WMI device
(8FC0DE0C-B4E4-43FD-B0F3-8871711C1294) at the same time, and both report the
mic mute key into the same input device ("Ideapad extra buttons") a few
milliseconds apart, with different scan codes: 0x8 from the ACPI path and
0x13e from the WMI path.
Userspace applies the toggle twice, so the microphone returns to its previous
state and the key appears not to work at all. Unmapping the WMI scan code
leaves a single event per keypress, and the key then toggles the microphone
reliably, mic mute LED included.
Note this differs from the ThinkBook 16p G5 IRX entry above, where the
duplicate comes from the AT keyboard; here both events originate from
"Ideapad extra buttons" itself.
This was discussed on platform-driver-x86, where the hwdb approach was
suggested in preference to unbinding the WMI driver.
The PRO X 2 LIGHTSPEED wireless dongle (046d:0af7) exposes a sound card
that is not detected as a headset, since the model name provides no
usable hint and the device has no usb.ids entry either. UPower then
reports its battery as an audio-device rather than a headset. Add a
quirk so the form factor is reported correctly.
## Summary
Clarify `ConditionPathExists=` in `systemd.unit(5)`:
- It checks for any filesystem object (regular file, directory, device
node, FIFO, socket), not only regular files.
- Symbolic links are followed, so a broken symbolic link is not
considered to exist.
Fixes#41900
When an automount goes away, the tokens we answer are only those we have
read from the pipe. Requests the kernel queued after our last read stayed
blocked: closing the pipe does not wake them, the kernel only notices the
closed pipe and turns the autofs catatonic when yet another request fails
to reach us, and after the lazy unmount no request reaches it anymore. In
the normal stop path that window is one event loop iteration; for an
automount torn down at coldplug it spans the whole reload.
Set the autofs to catatonic state before letting go of it, which fails
everything still queued with ENOENT. Answer the known tokens first:
closing our end of the pipe before that made a racing request flip the
kernel into catatonic mode on its own, which discards the queue and
turns our answers into "token not found" errors.
Signed-off-by: Martin Pitt <martin@amutable.com>
When an automount unit ceases to exist across daemon-reload (observed:
because a generator no longer emits it), its deserialized state still
makes `automount_coldplug()` pick up the autofs pipe and resume the unit
as waiting/running. But nothing can serve that mount point anymore. The
kernel keeps blocking every process that touches the mount point until
PID 1 answers (which it won't), forever.
To fix this, fail pending requests and unmount the autofs when
coldplugging an automount unit that is not loaded anymore.
Fixes#43700
Signed-off-by: Martin Pitt <martin@amutable.com>
When an automount goes away, answering the requests the kernel already
queued is the only thing that unblocks the processes waiting on them, and
nothing retries it later. If the `EHOSTDOWN` calls fail, it leaves the
requesting processes hung with no trace in the journal.
Log the failures to make this easier to debug. Also move that teardown into
a helper function, the next commit needs it as well.
Signed-off-by: Martin Pitt <martin@amutable.com>
Releasing the requests the kernel queued goes through `open_ioctl_fd()`, which
asserts on the manager fd for /dev/autofs. That fd stays unset when
`open_dev_autofs()` fails while coldplugging an automount, while the
deserialized pipe and its tokens outlive it.
Report the failure to the caller instead of asserting/crashing PID 1.
Signed-off-by: Martin Pitt <martin@amutable.com>
For re-use in systemd-gpt-auto-generator. This also makes it generic
across sysext/confext - no planned use for this, but to avoid confusion
later when someone tries to use it on a confext.
This updates a couple of links talking about Varlink:
1. anything that refers to specific Varlink concepts now point to the
UAPI.20 spec
2. More general references to Varlink as a whole point to both the
varlink.org domain and the spec.
RFC 4861 section 6.3.7 states that a host should send at least one Router
Solicitation even if it receives an unsolicited Router Advertisement
before sending its first solicitation, and should stop soliciting only
after receiving a valid Router Advertisement with a non-zero Router Lifetime.
Keep the RS timer active until both conditions are met, and add a
regression test for a zero-lifetime RA arriving before the initial RS.
Fixes#43205.
zouge666
Jan Kuparinen
Weblate Translation Memory
Anders Jonsson
Daan De Meyer
Lennart Poettering
Zbigniew Jędrzejewski-Szmek
Ivan Kruglov
Daniel Wagenknecht
Yu Watanabe
Arian van Putten
Luca Boccassi
Chris Down
Cathal Mullan
Armaan Sandhu
Lokesh Patel
Ettore Atalan
Edvard Jaegtnes
Kevin Charpentier
Méven Car
Kai Wohlfahrt
KingPointer
Martin Pitt
quanyeyang