Now, gateway for routes to DNS or NTP servers should be correctly picked,
hence it is not necessary to adjust the gateway address in
dhcp4_request_route_auto() again.
Also, similar for classless static routes, let's always honor
gateway address specified in (non-classless) static routes.
network/dhcp4: always find suitable gateway for destination address
And if not found, refuse to configure the route.
If a DHCP server provides classless static or static routes, then we
should use the gateway for accessing a node in the range specified in
the route. E.g. if a DHCP server provides the default gateway is
192.168.0.1, and classless static route for 8.0.0.0/8 with gateway
192.168.0.2, then we should access 8.8.8.8 through 192.168.0.2 rather
than 192.168.0.1, but should use 192.168.0.1 for 9.9.9.9.
network/dhcp4: introduce dhcp4_get_router() helper function
Previously, we use the first router address, and if it is null, we
ignore the address. Now, we use the first non-null address. That is, if
the first router address is null, but the second is not, then we use the
second one.
That should not cause functional change in most cases, except for the case
when a DHCP server provides such spurious reply.
This is mostly for refactoring and preparation for later commits.
In it's latest release, agetty will support reading the agetty.autologin
and login.noauth credentials, so let's make sure we import those in our
getty units so they're available to agetty to read.
+ apt-get -y install clang-15 lldb-15 lld-15 clangd-15
Reading package lists...
Building dependency tree...
Reading state information...
Some packages could not be installed. This may mean that you have
requested an impossible situation or if you are using the unstable
distribution that some required packages have not yet been created
or been moved out of Incoming.
The following information may help to resolve the situation:
The following packages have unmet dependencies:
python3-lldb-14 : Conflicts: python3-lldb-x.y
python3-lldb-15 : Conflicts: python3-lldb-x.y
E: Error, pkgProblemResolver::Resolve generated breaks, this may be caused by held packages.
sleep: don't init /sys/power/resume if 'resume=' option is missing and EFI is disabled
Otherwise in such case a first `systemctl hibernate` would fail but would still
initialize /sys/power/resume fooling a second `systemctl hibernate` into
believing that 'resume=' is correctly set and can be used by the resume process
to find the swap device to resume from.
Workaround for CI issue, the sd-stub we build is overwritten in the final
image as the package gets pulled there, install it in the base to
work around it for now
fstab-generator: add a flag to accept entry for "/" in initrd
When both prefix_sysroot and accept_root is true, the entry for "/" will
be accepted and converted to "/sysroot/".
Why? If the entry is read from the main system's fstab, then we already
mounted /sysroot/, hence it is not and should not re-add the .mount unit
for /sysroot/. However, if we want to specify the root mount through the
kernel command line or credential, without this change, we need to
specify the same entry in the two options. E.g.
===
systemd.mount-extra=/dev/sda1:/:auto:defaults
rd.systemd.mount-extra=/dev/sda1:/sysroot:auto:defaults
===
That's inconvenient. Of course, we can dedup that by using traditional
options, but cannot when defined in credential.
This makes the behavior consistent with the way we already do for
fstab and command line options.
In initrd, entries read from fstab.extra are mounted under /sysroot.
fstab-generator: add rd.systemd.mount-extra= and friends
Previously, mounts specified in systemd.mount-extra= are equally handled
both in initrd and the main system. So, the mounts for the main system
are also mounted in initrd.
This introduces rd.systemd.mount-extra=, which specifies mounts in initrd.
Then, mounts specified in systemd.mount-extra= are still mounted both in
initrd and the main system, but prefixed with /sysroot/ when running in
initrd.
If /usr mount is picked from the main system's fstab file (prefix_sysroot
is true, and the path is prefixed as /sysroot/usr), then previously it
was installed in the wrong target unit.
mkosi: add drop-in to make emergency.service shut down the system
When the mkosi CI fails to boot, it just sits there waiting at the emergency
console until the job times out. Add a drop-in for emergency.service in the
CI configuration so that instead it exists immediately.
Currently, if an fstab entry for /boot/ exists, we'll skip to try /efi/
instead. However, if it's already using the same device as the discovered
one, we should not duplicate the mount.
pam: lower warning about closing sd-bus after fork
There is some issue in our code that triggers this warning constantly,
but it's nothing users can solve, so downgrade to debug level until
we can figure out the original issue (which is a permission denied
error on ReleaseSession D-Bus method call).
Related to https://github.com/systemd/systemd/issues/28514
udev: set ID_PATH properties for all pci, usb, and platform devices
Before c43ff248f94266cfc93e300a2d3d163ed805e55b, the following line in
60-drm.rules also sets ID_PATH for all pci, usb, and platform devices:
===
ACTION!="remove", SUBSYSTEM=="drm", SUBSYSTEMS=="pci|usb|platform", IMPORT{builtin}="path_id"
===
Unfortunately, some existing rules rely on the unexpected behavior.
To keep the backward compatibility, let's set ID_PATH for them.
Traceback (most recent call last):
File "/<<PKGBUILDDIR>>/obj-arm-linux-gnueabihf/src/kernel-install/60-ukify.install", line 223, in <module>
main()
File "/<<PKGBUILDDIR>>/obj-arm-linux-gnueabihf/src/kernel-install/60-ukify.install", line 219, in main
call_ukify(opts)
File "/<<PKGBUILDDIR>>/obj-arm-linux-gnueabihf/src/kernel-install/60-ukify.install", line 205, in call_ukify
ukify['finalize_options'](opts2)
File "/<<PKGBUILDDIR>>/obj-arm-linux-gnueabihf/ukify", line 1423, in finalize_options
opts.efi_arch = guess_efi_arch()
^^^^^^^^^^^^^^^^
File "/<<PKGBUILDDIR>>/obj-arm-linux-gnueabihf/ukify", line 78, in guess_efi_arch
raise ValueError(f'Unsupported architecture {arch}')
ValueError: Unsupported architecture armv7l
The new meson option 'default-keymap' means that by default there's always
a keymap to configure, so vconsole-setup fails. Allow to set
-Ddefault-keymap="" to disable it and skip gracefully again.
test: check if we correctly propagate /run mounts during switch root
Since 7c764d4 we bind mount certain directories during switch root
instead of moving the mount directly, and for /run we do this without
MS_REC. This, unfortunately, leaves all mounts under /run behind
in the old root, which breaks certain use cases.
The commit intended to fix a race reported at #28009. However,
unfortunately, it does not fix the root of the race, and reveals
the race in more simple setups. See reports in #28358.
Dan Streetman [Fri, 21 Jul 2023 15:23:22 +0000 (11:23 -0400)]
tpm2: instead of adjusting authValue trailing 0(s), trim them as required by tpm spec
To keep compatibility with any existing object authValues with trailing 0's,
change tpm2_get_pin_auth() to trim trailing 0's, which is what the TPM
implementation will do. This should retain compatibility with any existing
authValues that contain trailing 0's.
Note that any existing authValues with trailing 0's are unlikely to have worked
in the way that systemd uses them in object sealing, which is as a bind key for
the encryption (and policy) session. However, it is better to be compatible
with the TPM spec (and implementations) even if previously created objects that
are affected may not have worked.
fd-util: do not call statx() twice when it does not provide mount ID
Previously, in path_is_root_at(), if statx() does not provide mount ID,
path_get_mnt_id_at() was called, but it also calls statx(). Let's avoid
the second trial.
When newer glibc is used, but kernel does not support statx(), then
glibc try to fallback with fstatat(). That's quite similar to our
implementation, but the supported flags are different, and if
unsupported flags are specified, it returns EINVAL.
* We don't support filesystems smaller than 300MB anymore. Tiny
* filesystems have never been XFS' design target. This limit has been
* carefully calculated to prevent formatting with a log smaller than
* the "realistic" size.
*
* If the realistic log size is 64MB, there are four AGs, and the log
* AG should be at least 1/8 free after formatting, this gives us:
*
* 64MB * (8 / 7) * 4 = 293MB
So let's accommodate and bump the minimal XFS filesystem size to 300M.
Previously, if the priority is same, devlinks are always replaced by
newer events. The commit 331aa7aa15ee5dd12b369b276f575d521435eb52 changes
that to keep the existing devlink. That should not change any behavior
when the devices that request the same symlink do not have any
dependency, e.g. when /dev/sda1 and /dev/adb1 request the same
/dev/disk/by-label symlink, as there are no guarantee that which device
is processed first.
However, when devices has dependency, e.g. /dev/sda and /dev/sda1
request the same /dev/disk/by-label symlink, previously the symlink
always pointed to the partition, as the partition is always processed
later. But, 331aa7aa15ee5dd12b369b276f575d521435eb52 makes the symlink
point to the whole disk.
The change by 331aa7aa15ee5dd12b369b276f575d521435eb52 is crucial to
improve performance of devlink handling, especially when a system has
large number of disks with same label or so. Hence, cannot and should
not be reverted.
So, let's workaround the case, as such situation should happen only when
the disk is a hybrind ISO image, I guess.
When an explicit sector size is set by the user it is also necessary to set the
sector size of any loopback devices. If the sector size is not set for loopback
devices then it can cause file system creation to fail or run into odd issues.
run: disable --expand-environment by default for --scope
The intention was to have this option enabled by default everywhere,
but unfortunately at least one case was found where it breaks
compatibility of a program using systemd-run --scopes and expecting
variables not to be expanded:
Restore backward compatibility and make the option disabled by default
when --scope is used, and enabled by default for other types.
In case --expand-environment is not specified and a '$' character is
detected, print a warning to nudge users toward specifying the
parameter as needed. In the future we can then flip the default.
This fixes the test failure when invoked by a user.
===
Running ./systemd-tmpfiles --user on 'f /tmp/test-systemd-tmpfiles.1foag_ur/test-content.n_9r_xhm/arg - - - - %S'
expect: '/home/watanabe/.config'
actual: '/home/watanabe/.local/state'
Traceback (most recent call last):
File "/home/watanabe/git/systemd/test/test-systemd-tmpfiles.py", line 233, in <module>
test_valid_specifiers(user=True)
File "/home/watanabe/git/systemd/test/test-systemd-tmpfiles.py", line 135, in test_valid_specifiers
test_content('f {} - - - - %S',
File "/home/watanabe/git/systemd/test/test-systemd-tmpfiles.py", line 88, in test_content
assert content == expected
^^^^^^^^^^^^^^^^^^^
AssertionError
===
Template names can be learned from the filesystem, so there isn't a need
to parse the output of systemctl list-unit-files in this case. This
should accelerate the completion of some verbs like enable.
The existing caching policy isn't very sensible for this cache. We could
write a different policy, but I don't think there is much value in
caching these values, as in my experience the command used to generate
them is quick.
In the first stanza, despite the comment, the pattern given would
consider the cache invalid if it was more than 1 hour old.
The second stanza was also incorrect, since the output of `systemctl
--all` is not unit file paths, but unit names. When they were being
tested against the cachefile mtime, the test would always fail becuase
of the nonexistant file (hopefully).
In fact it's not very useful to test if the unit files have newer mtime
in this case anyway, since we are only caching their names. Also,
`systemctl --all` is an unfortunately slow operation to be used in
testing for the cache validity — we want this operation to at least be
faster than rebuilding the cache.
I've rewritten this stanza with my best guess at its original intent. It
now checks against the mtime of the parent directories in the search
path, which should be updated and cause the cache to rebuild when we
add, remove, or rename any unit files.
The previous definition was not quite appropriate for the library code
because it relied on the message domain set by textdomain() invocation
which is not necessarily the same message domain defined in
GETTEXT_PACKAGE macro.
The only code that uses _() so far is located in pam_systemd_home.c.
kernel-install: silently ignore unexpected arguments for 'remove' command
The shell script version of kernel-install silently ignored unexpected
arguments, but C version refused that. Unfortunately, Fedora's kernel
script specifies kernel file even for 'remove' command. Let's accept
extra arguments and silently ignore them to keep backward compatibility.
This fixes regression introduced in 5a0c810462 with which all requests
for link properties ended up with EINVAL as we kept hitting
the signature_is_single() assert in sd_bus_get_property().
core: copy the host's os-release for /run/host/os-release
Currently for portable services we automatically add a bind mount
os-release -> /run/host/os-release. This becomes problematic for the
soft-reboot case, as it's likely that portable services will be configured
to survive it, and thus would forever keep a reference to the old host's
os-release, which would be a problem because it becomes outdated, and also
it stops the old rootfs from being garbage collected.
Create a copy when the manager starts under /run/systemd/propagate instead,
and bind mount that for all services using RootDirectory=/RootImage=, so
that on soft-reboot the content gets updated (without creating a new file,
so the existing bind mounts will see the new content too).
This expands the /run/host/os-release protocol to more services, but I
think that's a nice thing to have too.
As mentioned in the NEWS entry, it seems to see very little use, but adds
complexity in our code. It was added mainly with the goal of making it easier
for people using grub2 to modify their boot configuration, but grub2 is gaining
support for BLS snippets. On the systemd side, we now have credentials. So
let's deprecate this, and if there's no outcry, remove it in a few releases.
Petr Menšík [Sat, 15 Jul 2023 02:11:25 +0000 (04:11 +0200)]
Include in manual what DNSSEC=no means in detail
https://www.rfc-editor.org/rfc/rfc4035.html#section-3.2.1 says
security-aware recursive name server MUST set DO bit when sending
requests. systemd-resolved does not do that by design. State it more
clearly in manual page. Unlike other implementations it disables not
only validation as it stated, but complete DNSSEC awareness.
analyze: don't warn about version spec compliant versions
This commits adds version_is_valid_versionspec and uses it in
analyze-compare-version.c.
version_is_valid_versionspec differs from version_is_valid in that it acepts
empty strings and since valid characters in a version spec version are all
ASCII letters and digits as well as "-.~^", but ",_+" allowed by
version_is_valid are not.
Also give a more specific warning message on invalid characters.
projects / thirdparty / systemd.git / log
