Currently, the hash_ops is only used by set, so this does not change
anything. But, there are several benefits,
- we can drop cast in the definition,
- the hash_ops can be also used by hashmap.
Otherwise, if already 'remove' uevent for the device is queued, then
the device node may not exist any more when 'udevadm wait' command succeeds.
Follow-up for 90941d458a.
This also makes udevd/udevadm mention that the parent device rules
also tested with the device currently processing.
With the following rules file:
```
ATTRS{idVendor}=="0001", ATTRS{idProduct}=="44ff", MODE="0666", GROUP="input",
```
Before:
```
event0: /tmp/hoge.rules:1 Checking conditions for parent devices: ATTRS{idVendor}=="0001", ATTRS{idProduct}=="44ff"
event0: /tmp/hoge.rules:1 No parent device passed parent conditions.
```
After:
```
event0: /tmp/hoge.rules:1 Checking conditions for parent devices (including self): ATTRS{idVendor}=="0001", ATTRS{idProduct}=="44ff"
event0: /tmp/hoge.rules:1 ATTRS{idVendor}=="0001": Cannot read sysfs attribute: No such file or directory
input0: /tmp/hoge.rules:1 ATTRS{idVendor}=="0001": Cannot read sysfs attribute: No such file or directory
PNP0C0E:00: /tmp/hoge.rules:1 ATTRS{idVendor}=="0001": Cannot read sysfs attribute: No such file or directory
LNXSYBUS:00: /tmp/hoge.rules:1 ATTRS{idVendor}=="0001": Cannot read sysfs attribute: No such file or directory
LNXSYSTM:00: /tmp/hoge.rules:1 ATTRS{idVendor}=="0001": Cannot read sysfs attribute: No such file or directory
event0: /tmp/hoge.rules:1 No parent device passed parent conditions.
```
Prompted by #37063.
Previously, log level, properties, maximum number of worker processes,
and so on set by 'udevadm control' are discarded on restart. This makes
the configuration serialized on stop and deserialized in next
invocation. Also, this introduces 'udevadm control --revert' to clear
previous configurations.
Previously, configurations set by 'udevadm control' such as log level,
maximum number of childrens, global properties, and so on were discarded
on restart. This makes udevd serialize those configurations on stop, and
deserialize them in the next invocation.
Installing symlinks pointing to directories with install_subdir() is
broken (see https://github.com/mesonbuild/meson/pull/14471). Let's work
around the issue for now by manually installing the standalone directory
until the issue is fixed upstream and available in meson in all supported
distributions.
It is useful to have stable and unique identifiers for a security
principal. The majority of identitiy management systems in use with Unix
systems today (e.g. Active Directory objectGUID, FreeIPA ipaUniqueID,
Kanidm UUIDs) assign each account and group a unique UUID and exposing
that to applications allows them to refer to accounts in a stable
manner.
At this time we are merely adding the properties to the user/group
records. Adding ways to perform lookups by these IDs is left for a
future PR.
See [discussion](https://mastodon.social/@pid_eins/114283987142625086) and
[this comment](https://github.com/systemd/systemd/issues/24032#issuecomment-2745246757).
I'm sure there are wording aspects which could be improved, but I
believe this is a reasonable initial stab at the problem.
Let's make sure the mkosi can be built (with `NO_BUILD` enabled) without
the source tree available. This allows running the integration tests
when only distribution packages are available but the source tree is
not.
If the integration tests have been installed in the systemd-tests
package, the path to these in mkosi.postinst.chroot will be wrong.
Let's fix the issue by moving these files into the mkosi/ directory
as they're only used by mkosi regardless so they make more sense to
be there anyway.
Let's rely on tmpfiles to put our nsswitch.conf in place instead of
doing it in the post-install script. This moves us one step closer
to being able to build the mkosi image without having the source
tree available when NO_BUILD is used.
* 11efce9445 Install /usr/share/factory for upstream profile
* 4c3d753649 d/t/upstream: copy mkosi key from mkosi/ subdir if it exists
* 00f2ab1bce Install etc.conf tmpfiles.d in upstream builds
* dcf5869729 Refresh patch for upstream review changes
* f94714d8cc d/copyright: use GPL URL instead of old FSF postal address
* bf005e69f5 Update changelog for 257.5-2 release
* 709e474e5b Backport new patch to workaround /lib64 symlink incompatibility
* fa6c61db40 Update changelog for 257.5-1 release
* 9c9ca29ceb Remove conflicts with dracut:arm64 and build nspawn:arm64 again
* 5899bcc55d Update changelog for 257.5-1 release
* dd5cb92d08 Drop backports, included in 257.5
* c1373fb99e d/t/upstream: run mkosi genkey before summary
* 223d7a412a Install new files for upstream
* b9d337abd9 Use Conflicts instead of Breaks/Replaces for file move
* 9379847813 d/t/upstream: write mkosi.local.conf in subdir if the rest of the configs are in subdir
* 86fc24b565 d/t/upstream: do not fail if 10-root.conf is not present
The test "hangs" and times out on some arm64 machines. It actually works as
expected, but the machine has 2016 children under /sys/devices/system/memory/,
and the tests do a double loop over this, which is slow enough to hit the 120 s
limit. Add a limit on the number of iterations.
Another option would be to exclude "memory" subsystem. But we may have other
subsystems which have the same problem in the future, so I think it'll be more
robust to not try to limit the fix to a specific subsystem.
We had a downstream discussion on what `systemctl reload-or-restart
--marked` does, until upstream chimed in and pointed on very special
behavior for that combination. 😜
The second references the first, but not vice versa. Let's fix this.
Some AMD systems have support for features like custom brightness
curve or adaptive backlight management. These features allow the
display driver to adjust the brightness based upon other factors
than just the user brightness request.
The user's brightness request is indicated in the 'brightness' file
but the effective result of the logic in the display driver is stored
in the 'actual_brightness' file.
This leads to problems when shutting the system down because the value
of 'actual_brightness' may be lower than 'brightness' and the wrong value
gets stored for the next boot.
For example if the brightness a user requested was 150, the actual_brightness
might be 130. So the next boot the brightness will be "set" to 130, but the
actual brightness might be 115. If the user reboots again it will be set to 115
for the next boot but the actual brightness might be 100. That is this gets worse
and worse each reboot cycle until the system eventually boots up at minimum
brightness.
Furthermore the kernel documentation indicates that the brightness and
actual_brightness files are not guaranteed to be the same values.
Due to this; drop the use of 'actual_brightness' when saving/restoring brightness
and instead rely only upon 'brightness'.
Signed-off-by: Mario Limonciello <mario.limonciello@amd.com>
Yu Watanabe
Luca Boccassi
Busayo Dada
Luca Boccassi
Mike Yuan
Daan De Meyer
Zbigniew Jędrzejewski-Szmek
Nick Labich
Christian Hesse
ZIHCO
Mario Limonciello