Let's follow the conventions set by "Registry of Reserved TPM 2.0 Handles
and Localities" and only allocate nvindex currently not assigned to any
vendor.
For details see:
https://trustedcomputinggroup.org/resource/registry/
Section 2.2
Since we document /usr/local/lib/systemd/ and other paths for various things,
add notes that this is not supported if /usr/local is a separate partition. In
systemd.unit, I tried to add the footnote in the table where
/usr/local/lib/systemd/ is listed, but that get's rendered as '[sup]a[/sup]'
with a mangled footnote at the bottom of the table :( .
Also, split paragraphs in one place where the subject changes without any
transition.
Follow-up for 02f35b1c90.
Replaces https://github.com/systemd/systemd/pull/33231.
Follow-up for 1d617b35fe.
Should fix https://github.com/systemd/systemd/issues/33269.
From the logs in the bug:
Jun 10 22:55:37 systemd-logind[909]: The system will suspend now!
Jun 10 22:55:37 ModemManager[996]: <msg> [sleep-monitor-systemd] system is about to suspend
...
Jun 10 22:55:48 systemd-sleep[422408]: Failed to freeze unit 'user.slice': Connection timed out
Jun 10 22:55:48 systemd-sleep[422408]: Performing sleep operation 'suspend'...
The delay is ~11 s, consistent with the patch that set the timeout to 10 s.
Looks like this is not enough. It's the freeze operation that fails, but
thawing might be slow too, so just bump the timeout again.
Currently the check also succeeds if the input path starts with a dot, whereas
we only want it to succeed for "." and "./". Tighten the check and add a test.
Enabling this service by default means every CI image without a
regular user now gets stuck on first boot due to the password prompt
from systemd-homed-firstboot.service. Let's not enable the service
by default but instead require users to enable it explicitly if they
want its behavior.
Fixes#33249
systemd-nspawn sets up /dev/console as a symlink to a pty, so let's
make sure we follow the symlink when trying to lock /dev/console so
we don't fail with ELOOP.
Follow-up for 28459ba1f4
The pty path returned by OpenMachinePTY() cannot be opened from outside
the machine, hence let's use the plain Standard{Input,Output,Error}=tty
in such a case. This means if --machine= is specified, #32916 would occur.
A comprehensive fix requires a new dbus method in machined, which shall
be material for v257.
See also: https://github.com/systemd/systemd/pull/33216#discussion_r1628020429
Replaces #33216
Co-authored-by: Mike Yuan <me@yhndnzj.com>
This reverts commit 0f5a529217.
As discussed in https://github.com/systemd/systemd/issues/33104,
that patch caused problems in Debian which has a udev drop-in with
[Match]
Path=*-usb-*
[Link]
NamePolicy=mac
The rename fails:
eth0: Policy *mac* yields "enx00*".
eth0: /usr/lib/udev/rules.d/80-net-setup-link.rules:11 NAME 'enx00*'
eth0: /usr/lib/udev/rules.d/99-systemd.rules:69 RUN '/usr/lib/systemd/systemd-sysctl --prefix=/net/ipv4/conf/$name --prefix=/net/ipv4/neigh/$
eth0: sd-device: Created database file '/run/udev/data/n9' for '/devices/pci0000:00/0000:00:1c.4/0000:02:00.0/0000:03:01.0/0000:05:00.0/0000:
eth0: Failed to rename network interface 9 from 'eth0' to 'enx00*': File exists
eth0: sd-device: Created database file '/run/udev/data/n9' for '/devices/pci0000:00/0000:00:1c.4/0000:02:00.0/0000:03:01.0/0000:05:00.0/0000:
eth0: Failed to process device, ignoring: File exists
Two network interfaces have the same MAC and it's not marked NET_ADDR_STOLEN.
In this case the conflict is very visible because it causes the rename to fail,
but it would also occur in other cases, for alternative names.
A patch has been submitted for r8152 to properly set NET_ADDR_STOLEN:
https://lore.kernel.org/linux-usb/20240605153340.25694-1-gmazyland@gmail.com/T/#u
Let's revert this now to avoid a regression. We can try again after the kernel
issue is resolved.
Closes https://github.com/systemd/systemd/issues/33104.