Add support for the hardware family, SKU (Stock-Keeping Unit) and
version. The values are read from the file /etc/machine-info or DMI as
fallback.
The entries are useful to provide an unified interface to collect detail
hardware information. The /etc/machine-info entries enable embedded
devices without UEFI support to provide the information via a common
interface.
Fixes: #31134
per Daan's explanation:
other subtests running as testuser apparently use systemd-run --user
--machine testuser@.host which turns user tracking in logind into "by
pin" mode. when the last pinning session exits it terminates the user.
This breaks GNOME on Wayland, login no longer works:
gnome-shell[2250]: Running GNOME Shell (using mutter 48.2) as a Wayland display server
gnome-shell[2250]: Failed to setup: Failed to find any matching session
systemd[2054]: org.gnome.Shell@wayland.service: Failed with result 'protocol'.
systemd[2054]: Failed to start org.gnome.Shell@wayland.service - GNOME Shell on Wayland.
This reverts commit b0555149de.
test_keep_configuration_on_restart() works, but the error printed is
misleading because self.assertNotEmpty() doesn't exist.
Add a working assert statement so, when the unmanaged interface is
altered, the test fails with a meaningful error, like:
### ip monitor dev unmanaged0 BEGIN
222:33::/64 proto kernel metric 256 pref medium
FAIL
[...]
Traceback (most recent call last):
File "/work/src/test/test-network/systemd-networkd-tests.py", line 5085, in test_keep_configuration_on_restart
self.assertEqual(line, '')
AssertionError: '222:33::/64 proto kernel metric 256 pref medium' != ''
- 222:33::/64 proto kernel metric 256 pref medium
While at it, strip the trailing newline so we can print easily the
string (and in future build more a robust regexp which uses the $ token)
Add support for the hardware version. The version describes a distinct
version of compatibility hardware. The value is read from the file
/etc/machine-info or DMI as fallback.
The integration provides an unified interface to collect detail hardware
information. The /etc/machine-info entry enables embedded devices
without UEFI support to read the information from a custom store.
Add support for the hardware Stock-Keeping Unit (SKU). The SKU describes
a distinct type of hardware for sale, purchase or inventory management.
The value is read from the file /etc/machine-info or DMI as fallback.
The integration provides an unified interface to collect detail hardware
information. The /etc/machine-info entry enables embedded devices
without UEFI support to read the information from a custom store.
This was broken in f45b801551. Unfortunately
the review does not talk about backward compatibility at all. There are
two places where it matters:
- During upgrades, the replacement of kernel.core_pattern is asynchronous.
For example, during rpm upgrades, it would be updated a post-transaction
file trigger. In other scenarios, the update might only happen after
reboot. We have a potentially long window where the old pattern is in
place. We need to capture coredumps during upgrades too.
- With --backtrace. The interface of --backtrace, in hindsight, is not
great. But there are users of --backtrace which were written to use
a specific set of arguments, and we can't just break compatiblity.
One example is systemd-coredump-python, but there are also reports of
users using --backtrace to generate coredump logs.
Thus, we require the original set of args, and will use the additional args if
found.
A test is added to verify that --backtrace works with and without the optional
args.
We generally frown on config options that are called
EnableXYZ=/DisableXYZ=, hence drop this here too. Note that the original
sin was that the pre-existing D-Bus property already used the prefix.
But given that D-Bus properties are substantially more low-level (i.e.
developer focused) than the config knobs, let's bite the bullet and
name the configuration option cleanly, even if the dbus property carries
the damn prefix.
The knob was added post v257, hence this is not a compat break.
Follow-up for: 130698dc20
We need to protect us from recycled PIDs here like everywhere else: once
we read data from /proc/$PID/ we need to validate that $PID still points
to the original pidfd.
Yu Watanabe
Mike Yuan
Lennart Poettering
AsciiWolf
Ivan Kruglov
AsciiWolf
Luca Boccassi
Daan De Meyer
Zbigniew Jędrzejewski-Szmek
Matteo Croce
Stefan Herbrechtsmeier