There are a lot of edge cases that the current implementation
doesn't handle, especially in cases where one of passwd/shadow
exists and the other doesn't exist. For example, if
--root-password is specified, we will write /etc/shadow but
won't add a root entry to /etc/passwd if there is none.
To fix some of these issues, we constrain systemd-firstboot to
only modify /etc/passwd and /etc/shadow if both do not exist
already (or --force) is specified. On top of that, we calculate
all necessary information for both passwd and shadow upfront so
we can take it all into account when writing the actual files.
If no root password options are given --force is specified or both
files do not exist, we lock the root account for security purposes.
libc in the Debian container got updated to 2.31, which in combination
with clang-9 triggers systemd/systemd#14865.
This has been fixed by https://reviews.llvm.org/D74712 which is (to my
knowledge) included in clang-10. To mitigate this without upgrading to
clang-10 we can compile with -O1 which works around it as well, see
https://bugzilla.redhat.com/show_bug.cgi?id=1803203.
network: stop already running engines before updating MAC address
In NetworkdBridgeTests.test_bridge_configure_without_carrier of
systemd-networkd-tests.py
```
bridge99: MAC address: 2e:3a:ec:4d:d3:62
Assertion 'sd_ipv4ll_is_running(ll) == 0' failed at src/libsystemd-network/sd-ipv4ll.c:110, function int sd_ipv4ll_set_mac(sd_ipv4ll *, const struct ether_addr *)(). Ignoring.
bridge99: Could not update MAC address in IPv4LL client: Device or resource busy
```
vconsole-setup: downgrade log message when setting font fails on dummy console
Since commit 883eb9be985fd86d9cabe967eeeab91cdd396a81, vconsole-setup might be
called again to operate on dummy console where font operations are not
supported but where it's still important to have the correct keymap set [0][1].
vconsole-setup is mainly called by udev but can also be run via a dependency of
an early service. Both cases might end up calling vconsole-setup on the dummy
console.
The first case can happen during early boot even on systems that use (instead
of the dummy console) a "simple" video console driver supporting font
operations (such as vgacon) until a more specific driver (such as i915) takes
the console over. While this is happening vgacon is deactivated and temporarly
replaced by the dummy console [2].
There are also other cases where systemd-vconsole-setup might be called on
dummy console especially during (very) early boot. Indeed
systemd-vconsole-setup.service might be pulled in by early interactive services
such as 'dracut-cmdline-ask.service` which is run before udev.
If that happens on platforms with no grapical HWs (such as embedded ARM) or
with dummy console initially installed until a driver takes over (like Xen and
xen-fbfront) then setting font will fail.
Therefore this patch downgrades the log message emitted when setting font fails
to LOG_DEBUG and when font operations is not implemented like it's the case for
the dummy console.
When sd_netlink_call_async() timed out, then we reply the synthetic
error message, but it was not sealed. So, reading the message causes
the following assertion:
```
Assertion 'm->sealed' failed at src/libsystemd/sd-netlink/netlink-message.c:652, function netlink_message_read_internal(). Ignoring.
```
networkd: Use NLM_F_ACK on the netlink message to add a neighbor.
sd_netlink_message_set_flags is called without NLM_F_ACK which results in
a timeout while networkd is waiting for an ACK that the kernel will never send.
shared/offline-passwd: look at /usr/lib/{passwd,group} too
This changes the code to allow looking at multiple files with different
prefixes, but uses "/etc" and "/usr/lib". rpm-ostree uses
/usr/lib/{passwd,group} with nss-altfiles. I see no harm in simply trying both
paths on all systems.
A minor memory leak is fixed: hashmap_put() returns -EEXIST is the key is
present *and* and the value is different. It return 0 if the value is the
same. Thus, we would leak the user/group name if it was specified multiple
times with the same uid/gid. I opted to remove the warning message completely:
with multiple files it is reasonable to have the same name defined more than
once. But even with one file the warning is dubious: all tools that read those
files deal correctly with duplicate entries and we are not writing a linter.
Move offline-password.[ch] to shared and add test-offline-passwd
The test binary has two modes: in the default argument-less mode, it
just checks that "root" can be resolved. When invoked manually, a root
prefix and user/group names can be specified.
netlink: do not fail when new interface name is already used as an alternative name
When renaming a network interface, the new name may be used as an
alternative name. In that case, let's swap the current name and the
alternative name. That is, first drop the new name from the list of
alternative names, then rename the interface, finally set the old name
as an alternative name.
hwdb: check that uppercase digits are used in modalias patterns
This is all confusing as hell, becuase in some places lowercase hexadecimal
digits are used, and in other places uppercase. This adds a check for the
most common case that we and others got wrong.
I tried to extend the general grammar in hwdb_grammar() to include this check,
but it quickly became very complicated and didn't seem to work properly. Doing
initial parsing with more general rules is easier and also seems to give better
error messages:
/home/zbyszek/src/systemd-work/build/../hwdb.d/60-autosuspend.hwdb: 3 match groups, 5 matches, 3 properties
Pattern 'v058fp9540*' is invalid: Expected W:(0123...), found 'f' (at char 4), (line:1, col:5)
Defaulting to fedora makes it a pain to override mkosi.default
point to one of the other mkosi settings files. Instead, have
every developer manually add the symlink to his distro
of choice and don't commit the symlink to the repository by
putting it in the .gitignore.
We use LOG_PRI() in all log_*() functions, so let's do that here too for
consistency. Effectively this doesn't change anything since we only use
LOG_{INFO,DEBUG,...} as the argument.
This effectively partially reverts "rules: remove all power management from
udev" / e2452eef02a839e1928f4ffd893c93a460474ab6. The rules for emulated QEMU
hardware were removed in one fell swoop with other rules which were causing
problems. But the qemu rules were working properly (and were adjusted through
patches over time). Nowadays we have a hwdb for this, so add hwdb entries using
the new detailed modalias.
udev: change the modalias string for usb devices to include the device name
When the kernel does not provide a modalias, we generate our own for usb devices.
For some reason, we generated the expected usb:vXXXXpYYYY string, suffixed by "*".
It was added that way already in 796b06c21b62d13c9021e2fbd9c58a5c6edb2764, but I
think that was a mistake, and Kay was thinking about the match pattern instead
of the matched string.
For example, for a qemu device:
old: "usb:v0627p0001*"
new: "usb:v0627p0001:QEMU USB Tablet"
On the match side, all hwdb files in the wild seem to be using match patterns
with "*" at the end. So we can add more stuff to our generated modalias with
impunity.
This will allow more obvious and more certain matches on USB devices. In
principle the vendor+product id should be unique, but it's only 8 digits, and
there's a high chance of people getting this wrong. And matching the wrong
device would be quite problematic. By including the name in the match string we
make a mismatch much less likely.
udev: don't complain when udev_watch_end() is called without udev_watch_init()
E.g. udevadm test prints "Invalid inotify descriptor." which is
meaningless without any context. I think it should be OK to call udev_watch_end()
from a cleanup path without any warning (even at debug level).
man: add more details for IMPORT, PROGRAM and RUN keys
967de8faceaa83c11a1215515cb135d7a8c0c32c added a note that I found very hard
to understand. Reword it, and also describe how IMPORT and PROGRAM are different
from RUN.
There is no reason to consider this wrong. In fact one could argue that +=
is more appropriate, because we always add to options, and not replace previous
assignments. If we output a debug message, we implicitly ask people to "fix" this,
and we shouldn't.
Udev logs are full of messages about wrong operator type:
...
Reading rules file: /usr/lib/udev/rules.d/60-persistent-storage.rules
/usr/lib/udev/rules.d/60-persistent-storage.rules:30 IMPORT key takes '==' or '!=' operator, assuming '=='.
/usr/lib/udev/rules.d/60-persistent-storage.rules:30 IMPORT key takes '==' or '!=' operator, assuming '=='.
/usr/lib/udev/rules.d/60-persistent-storage.rules:30 IMPORT key takes '==' or '!=' operator, assuming '=='.
/usr/lib/udev/rules.d/60-persistent-storage.rules:30 IMPORT key takes '==' or '!=' operator, assuming '=='.
/usr/lib/udev/rules.d/60-persistent-storage.rules:30 IMPORT key takes '==' or '!=' operator, assuming '=='.
/usr/lib/udev/rules.d/60-persistent-storage.rules:30 IMPORT key takes '==' or '!=' operator, assuming '=='.
/usr/lib/udev/rules.d/60-persistent-storage.rules:54 IMPORT key takes '==' or '!=' operator, assuming '=='.
/usr/lib/udev/rules.d/60-persistent-storage.rules:57 IMPORT key takes '==' or '!=' operator, assuming '=='.
/usr/lib/udev/rules.d/60-persistent-storage.rules:60 IMPORT key takes '==' or '!=' operator, assuming '=='.
/usr/lib/udev/rules.d/60-persistent-storage.rules:63 IMPORT key takes '==' or '!=' operator, assuming '=='.
/usr/lib/udev/rules.d/60-persistent-storage.rules:66 IMPORT key takes '==' or '!=' operator, assuming '=='.
/usr/lib/udev/rules.d/60-persistent-storage.rules:67 IMPORT key takes '==' or '!=' operator, assuming '=='.
/usr/lib/udev/rules.d/60-persistent-storage.rules:93 IMPORT key takes '==' or '!=' operator, assuming '=='.
/usr/lib/udev/rules.d/60-persistent-storage.rules:107 IMPORT key takes '==' or '!=' operator, assuming '=='.
/usr/lib/udev/rules.d/60-persistent-storage.rules:110 IMPORT key takes '==' or '!=' operator, assuming '=='.
/usr/lib/udev/rules.d/60-persistent-storage.rules:113 IMPORT key takes '==' or '!=' operator, assuming '=='.
Reading rules file: /usr/lib/udev/rules.d/60-persistent-v4l.rules
/usr/lib/udev/rules.d/60-persistent-v4l.rules:7 IMPORT key takes '==' or '!=' operator, assuming '=='.
/usr/lib/udev/rules.d/60-persistent-v4l.rules:9 IMPORT key takes '==' or '!=' operator, assuming '=='.
/usr/lib/udev/rules.d/60-persistent-v4l.rules:16 IMPORT key takes '==' or '!=' operator, assuming '=='.
...
The warning was downgraded in f0beb6f816035e438d684cc52ae76fc4a44fc197, but I
think it should be removed altogether. IMPORT{program}="asdf" seems like an
obvious way to write this, and people don't expect to have to write "==".
So let's just allow any operator.
nspawn: mount os-release in two steps to make it read-only
The kernel interface requires setting up read-only bind-mounts in
two steps, the bind first and then a read-only remount.
Fix nspawn-mount, and cover this case in the integration test.
man: don't claim environment.d/ was about sessions
This only sets the environment for user *services*, it has no effect on
sessions, as those get an env block set up by whatever program sets them
up and not systemd.
network: dhcp4: do not assign new address before old one is not removed
If DHCP4 client lost a lease, and then soon acquire new lease, then
the removal of the old address may not be completed. If that happens,
and the new and old addresses are the same, then the new address will be
considered as a foreign address. Such a situation can occur when the
DHCP4 server is restarted.
This makes networkd wait for the removal of the old address when a new
lease is acquired.
This also makes the link in configuring state when renewing address.
network: do not make link in configured state when no address is assigned
When DHCP6 and RA are enabled, and RA does not provide any addresses,
then link may become configured state even if no address is assigned,
due to the time-lag between RA completion and DHCP reply.
This makes if DHCP is explicitly enabled, then link must have at least
one valid address to be in the configured state.
timer: Adjust calendar timers based on monotonic timer instead of realtime
When the RTC time at boot is off in the future by a few days, OnCalendar=
timers will be scheduled based on the time at boot. But if the time has been
adjusted since boot, the timers will end up scheduled way in the future, which
may cause them not to fire as shortly or often as expected.
Update the logic so that the time will be adjusted based on monotonic time.
We do that by calculating the adjusted manager startup realtime from the
monotonic time stored at that time, by comparing that time with the realtime
and monotonic time of the current time.
Added a test case to validate this works as expected. The test case creates a
QEMU virtual machine with the clock 3 days in the future. Then we adjust the
clock back 3 days, and test creating a timer with an OnCalendar= for every 15
minutes. We also check the manager startup timestamp from both `systemd-analyze
dump` and from D-Bus.
Test output without the corresponding code changes that fix the issue:
Timer elapse outside of the expected 20 minute window.
next_elapsed=1594686119
now=1594426921
time_delta=259198
With the code changes in, the test passes as expected.