This reverts commit 56377438ba. Dropping
of the option currently doesn't disable anything, it just moves the
file. I don't think we gain anything by moving the file and actually
this causes problems [1], so let's just return to status quo ante.
[1] file /etc/init.d conflicts between attempted installs of systemd-259.999+69+g6ceb76bfc-2548.1.x86_64 and chkconfig-1.33-3.fc44.x86_64
[skip changelog]
Neither dbus nor pam are required in the initrd so
let's make both recommended dependencies instead
of required dependencies so that we can build
initrds without either of them getting pulled in.
The shell expansion we use to determine the top-level directory will
get expanded even if we don't execute %prep, so add a %_build_in_place
check to make sure we don't try to search for the top-level directory
if --build-in-place is set.
Upstream is moving towards making a lot more libraries dlopen() style
dependencies. Let's make sure to add these as Requires to corresponding
packages so they still get pulled in.
2ace9416e8 broke packit as the fallback
url wasn't listed first anymore. Make sure the fallback URL is listed
first again as clearly documented just above the conditionals.
systemd-networkd-resolve-hook.socket will be introduced by
https://github.com/systemd/systemd/pull/39293 but we need the spec
to handle the socket for the upgrade/downgrade test to pass so adding
it early behind the upstream bcond.
We use our own macros. They get pulled into the buildroot in Fedora
builds, but we shouldn't rely on this. In OBS builds, they are not
pulled in and the build fails.
- This is the first (large) batch of fixes after v258:
- fixes for boot loader and early boot code
- fixes for systemd itself, systemd-udevd, systemd-logind,
systemd-machined, and library code
- unprivileged operation in systemd-machined is disabled for now
- lots of documentation and shell-completion fixes
- includes an hwdb update
... (rhbz#2397579)
In https://bugzilla.redhat.com/show_bug.cgi?id=2397579 users are doing
a partial upgrade (seemingly) and that fails because of a file conflict.
Add Conflicts to prevent such partial upgrades.
An admin can create users in this directory instead of /etc/passwd. As
the .user file can contain hashed password, only root should be able to
read the files.
The upstream PR was closed with the intent to force the SELinux
policy to be updated instead. While we're waiting for that to happen,
include the patch here.
The RPM recipe files for SUSE and Fedora conflict and cannot be
both unpacked at the same time (e.g.: triggers.systemd, systemd.spec,
etc). The tarballs creation are unconditional. This means the same
project build cannot build for both Fedora and SUSE.
All other distros can co-habitate in the same project, so that a single
repository checkout, single trigger, single everything is used.
By storing the RPM recipe files in a separate directory it means they
don't conflict anymore, and they are moved in place in the right recipe
at the right time.
This allows building fedora/suse/centos/debian/ubuntu/arch from a
single project.
[skip changelog]
In the light of the recent discussion about dropping i686 packages, let's stop
building our docs there. This reduces the amount of tools needed in the mock
root.
Unfortunately we need to move the man page out of the noarch ukify subpackage,
because it needs to be the same on all architectures where it is built.
When testing build reproducibility, we got the following result:
+ rpmdiff cache/rpms/systemd-257.6-1.fc43/systemd-257.6-1.fc43.x86_64.rpm \
cache/build/systemd-257.6-1.fc43/rebuild/systemd-257.6-1.fc43.x86_64.rpm
......V..F. /etc/xdg/systemd/user
This is because we'd apply %ghost to a symlink to a directory, if the directory
stat reported 0 blocks. It seems that this depends on the filesystem type or
something and didn't pop up in previous rebuilds.
The first chunk is a noop to increase clarity.
The resulting difference from this patch in the file list:
$ diff -u systemd-257.6-build/systemd-257.6/.file-list-main{.0,}
-%config(noreplace) %ghost /etc/xdg/systemd/user
+%config(noreplace) /etc/xdg/systemd/user
When downgrading to package versions before 257.3-6 we have this error:
Error: Transaction test error:
file /usr/bin/systemd-sysusers from install of systemd-257-9.el10.x86_64 conflicts
with file from package systemd-sysusers-258~devel-20250416115850.el10.x86_64
Add Conflicts on systemd-sysusers subpackage to allow downgrades
across version 257.3-6.
- Fix for local information disclosure in systemd-coredump (CVE-2025-4598)
- Fixes for systemd itself, run0, systemd-networkd, "secure" pager,
man pages, shell completions, sd-boot, sd-varlink
- Hardware database update
This breaks suspend on my machine as of Linux 6.14, furthermore both
linked issues in rhbz#2321268 are closed and fixed in Linux upstream.
This reverts commit 6162965002.
Running from the source tarball implies running with unpatched tests,
whereas the same files from the systemd-tests package (which now contains
the mkosi and integration test files) will be patched.
[skip changelog]
Both work and if we do full sha we can retrieve the full sha from the
source filename in the source rpm later on which is useful for various
use cases.
[skip changelog]
Using the source tree of the spec can still lead to conflicts if a
mkosi/ directory exists there (which is the case in the hyperscale
systemd spec repo), so let's check out mkosi in /var/tmp to ensure
we don't conflict.
https://github.com/systemd/systemd/pull/36954 will move all the mkosi
configuration in the systemd repository into a mkosi/ subdirectory. This
means we have to put mkosi.local.conf in that subdirectory as well, so check
if the mkosi/ directory exists and put mkosi.local.conf in there if it exists.
The mkosi/ directory will conflict with our checkout of mkosi so we move that
checkout one level up. Additionally, we can't use .. anymore as the package
directory as that only works when mkosi.local.conf is in the top level directory
of the repository so we use an absolute path instead.
In OBS, noarch packages are shared between all architectures and
independent architectures can be rebuilt automatically without all
the other architectures getting rebuilt. This can result in the noarch
packages being newer than the archful packages for some architectures,
which means our current strict deps from the noarch packages on the
archful packages can't be satisfied.
To address this problem, let's relax the dependencies from the noarch
packages on the archful packages for OBS builds. Let's only do this for
OBS builds because this isn't an issue on Fedora as it's impossible to
build a package for only some of the architectures.
Noticed in https://bugzilla.redhat.com/show_bug.cgi?id=2348669#c25.
Most of those units listed don't have an [Install] section, and of those that
have, almost all were disabled by default. This might be something to fix, e.g.
we might want to enable systemd-udev-load-credentials.service, this is
something to consider. But it's clearer if we list all the units that those
packages ship. In priciple somebody might ship a preset to enable them.
Anyway, the impact of this change is much smaller than might seem at first.
But systemd-network-generator.service has an [Install] section and is preset
to true, so not listing it in the scriptlets was a visible bug.
There's the additional caveat that systemd-network-generator.service is coowned
by two packages. The current system does not have a way of handling this
properly, because unit enablement is tied to the package install state. Let's
just call the scriptlet for this unit twice for now. I think that's not going
to cause any real problem.
I noticed that systemd-sysusers creates accounts with /usr/bin/nologin.
On merged systems is fine, but would not work for systems where
/usr/sbin is still a separate directory and /usr/bin/nologin does not
exist. This problem occurs because the meson configuration script discovers
the location using $PATH, which on recent builds results in /usr/bin always.
Just specify all the paths so that we don't depend on the presence and
order of paths in $PATH.
If we download the main branch from github by defining %branch, the
source tarball will be named main.tar.gz, so let's make the tarball
pattern more generic to match.
Primarily, this allows us to get rid of dist-git-source which makes
the fmf stuff reusable for CentOS Stream in gitlab which we'd like to
make use of in the systemd backport in the Hyperscale SIG.
Also in general making the integration touch points with Fedora CI
and the other systems as small as possible seems like a good thing.
And in non-Fedora builds, undo the neutering of sysusers macros.
Downstreams like CentosStream did not go through the same changes
as Fedora but they may use packages built from the rawhide branch.
We had a bunch of Obsolets on self. This is useful when a subpackage
is split out to make it optional, and we want to install both the
original subpackage and the subpackage on ugprades. If both new
subpackages have Obsoletes on the old name, dnf will install both. But
we don't need to keep this infinitely, it's mostly useful for the
duration of a single stable release.
Apparatenly, those Obsoletes cause problems with downgrades.
The most recently added case is for the split of systemd-sysusers. But
we have an alternative mechanism in place: systemd Requires
/usr/bin/systemd-sysusers, and this path is provided by systemd-sysusers
and systemd-standalone-sysusers, with a bias towards systemd-sysusers.
So we should be able to drop the self-Obsoletes without a change in
functionality.
Also, drop some old Provides where 'dnf repoquery' indicates it is not
used by anything. Actually, only 'timedatex'. All the other ones are
used by one spec or another.
We don't need 1.5.0 to avoid the libbpf crash, the latest libbpf 1.4
patch release (1.4.7) also has the necessary fixes, so relax the
requirement a little to allow builds on Fedora 41 to succeed.
In CI builds we have %version that it smaller than 257.3-4 when the split
happened, and this causes problems when the packages are installed:
Failed to resolve the transaction:
Problem: package
systemd-sysusers-257-1.20250225060108317145.pr36507.1659.g4635c37946.fc43.x86_64
from @commandline
obsoletes
systemd < 257.3-4 provided by
systemd-257-1.20250225060108317145.pr36507.1659.g4635c37946.fc43.x86_64
from @commandline
- conflicting requests
I'm not sure if we even need the self-Obsoletes. We have a Requires and
Recommends in the main systemd package that will cause on of the providers of
/usr/bin/systemd-sysusers to be installed, and the non-standalone version is
preferred. But it's possible that if recommends are disabled, the
non-standalone package could be installed for some reason. So let's keep the
self-Obsoletes for now.
Another caveat is that it's not clear if v-string comparisons require %[] as a
wrapper. Some chat in #fedora-devel suggested that that's the case, but things
seem to work without it.
None of the systemd git tags have tildes in them, so there's no need
to use version_no_tilde for these.
This is another change to make packit work as the archive it sets up
for us based on the systemd upstream packit config file does have a
tilde in its name which then makes %prep fail as we transform the tilde
to a hyphen and then fail to find the systemd source directory.
"""
+ /usr/lib/rpm/rpmuncompress -x /builddir/build/SOURCES/systemd-258~devel.tar.gz
+ STATUS=0
+ '[' 0 -ne 0 ']'
+ cd systemd-258-devel
/var/tmp/rpm-tmp.gw7KSw: line 42: cd: systemd-258-devel: No such file or directory
"""
Previously, /usr/bin/systemd-sysusers was provided by both systemd and
systemd-standalone-sysusers, creating a file conflict, and the packages
declared Conflicts. This changed when systemd-sysusers was split out to a
separate subpackage. So we don't need the Conflicts and can allow a "cross
installation" of systemd-sysusers-standalone and and the other "normal"
systemd subpackages.
This should solve https://bugzilla.redhat.com/show_bug.cgi?id=2344322 without
requiring changes in the container definitions. (Though those changes probably
should be made anyway. If we end up installing systemd, we probably want to use
shared systemd-sysusers, to avoid wasting space.)
... (rhbz#2344322)
rpm-libs has Requires:/usr/bin/systemd-sysusers.
We split split out /usr/bin/systemd-sysusers (the normal version) to a
subpackage, and the shared library
/usr/lib64/systemd/libsystemd-shared-257.2-14.fc42.so to a second subpackage.
(In preparation for maybe making further splits later.)
systemd-sysusers+libsystemd-shared.so is 4.8MB, but libsystemd-shared.so also
pulls in a bunch of libraries. We'll find out what the actual change in
installation footprint (compared to systemd-standalone-sysusers) really is when
we build some images with the new split.
- systemd-ac-power is moved to systemd-udev
- portablectl and importctl are moved to systemd-container (rhbz#2345551)
ac-power clearly is only useful for real hardware. portablectl
and importctl are niche tools that don't need to be in the main package
(even though they could theoretically be used not for containers).
We are doing self-signing, so don't tag the EFI binaries as if
they were Fedora's, since they are not. Set upstream-specific
tags, that are the same for all distros built on OBS..
[skip changelog]
Let's add a tmt plan to read the upstream fmf metadata which contains
a single test to run the upstream integration tests.
To make this work, we also add a downstream patch with some fmf test
script fixes that landed after 257.2 was released.
We request virtualization support so we can run qemu based integration
tests in qemu with KVM.
On OBS the https://github.com/openSUSE/pesign-obs-integration
package is the way to get binaries signed. Build depend on it,
and call its hook.
Also rename and change the description and provides of the package,
given it is signed.
[skip changelog]
In the past, we used patch numbers to skip some patches in upstream CI
builds. The upstream bcond is now used for this instead, so we can
drop the numbering to make it easier to add an remove patches.
[skip changelog]
The test fails because of the same reason as the installability test,
it tries to install every subpackage which fails because the standalone
subpackages conflict with all the other packages.
Given there's no owner for the test, nobody looks at or seems interested
in the results, STI itself will likely be deprecated soon
(https://fedoraproject.org/wiki/Changes/DeprecateSTI) and systemd's
upstream integration tests will soon support checking for AVC denials
(https://github.com/systemd/systemd/pull/35921), let's remove the STI test.
- Fixes for assertion crashes and memory access issues in pid1 and
systemd-machined, and other fixes for systemd-repart, systemd-resolved,
systemd-stdio-bridge, systemctl, journalctl, sd-device, hibernation,
and the hardware database.
The version substitution system is not able to fully subst
the current Version field due to the inline use of macros, so you end up with like:
257-123-gabcd257.1
instead of:
257-123-gabcd
I.e., the hard-coded 257.1 gets appended to the OBS-specified version.
If it was simply hardcoded as 257.1 it would work, but the inline
macros throw it off.
[skip changelog]
OBS does not support files with names starting with a dot.
https://fedoraproject.org/wiki/How_to_filter_libabigail_reports does
not make it really clear if the file can renamed. (The first part of
the paragraph implies a positive answer, the second is unclear.)
Let's see how this goes.
Let's use the %upstream macro to gate patches which are backports of
upstream instead of relying on patch numbers. We'll build with %upstream
defined in packit so that patches which should not be applied on upstream
builds are skipped.
Building with %upstream doesn't necessarily imply we want a developer
build, so let's always build in release mode. If needed
%meson_extra_configure_options can be used to override this and build
in developer mode after all.
From the 257 release notes:
* The --purge switch of systemd-tmpfiles (which was added in v256) has
been reworked: it will now only apply to tmpfiles.d/ lines marked
with the new "$" flag. This is an incompatible change, and means any
tmpfiles.d/ files which shall be used together with --purge need to
be updated accordingly. This change has been made to make it harder
to accidentally delete too many files when using --purge incorrectly.
The feature is now sufficiently hard to misuse that we can drop the patch.
- A bunch of small fixes in various components: systemd itself, systemd-cryptenroll,
sd-varlink, sd-boot, documentation, tests
- Includes an update of the hardware database
The build is slow anyway, so the difference shouldn't matter. But more
tests is better. The build logs show that slow tests were disabled.
Inspired by https://github.com/systemd/systemd/issues/34471.
Our mkosi.conf.d/10-centos-fedora/mkosi.prepare script tries to install
the soft dependencies too.
The build fails in centos 9 and 10:
Error: Unable to find a match: qemu-device-display-virtio-gpu
qemu-device-display-virtio-vga
[skip changelog]
... (rhbz#2328723)
The files systemd-networkd-generator generates are read by udev (.link files)
and by networkd (.netdev, .netdev files). We can't move it to systemd-networkd
subpackage only, because that would potentially break the corner case of people
having systemd-udev installed and using the generator, but not systemd-networkd.
And there is no dependency from systemd-networkd to systemd-udev. I think this
is correct, because networkd can be used in containers without udev. But the
generator is not useful without either of those two daemons, so let's move
it to make the core package a bit lighter.
Anything we put in a %postun script needs two releases of the rpm
before it is invoked. The reason for using %postun to restart services
is because it runs after the old version has been removed so we can be
sure all remaining dropins and such files from the old version have been
removed. %posttrans gives us the same guarantee but the %posttrans of the
new version will run on install and upgrade which means the changes will
be applied immediately instead of having to release twice before the changes
take effect.
We define the systemd_posttrans_with_restart macro in the spec because we
can't use the upstream one as we ship it ourselves.
This drastically simplifier reexecs of user managers by using
systemctl reload to do a user manager reexec. This means we don't
need systemd-run, a pam session or systemd-stdio-bridge anymore to
do a user manager reexec and all job tracking is handled by pid 1
instead of bash.
Even on non-uefi architectures, ukify can be used to build UKIs for
UEFI images. For example, mkosi can use it to build UKIs on s390x.
To enable this use case, let's always build ukify, but with a conditional
dependency on systemd-boot only on arches that support UEFI.
We still want the Fedora systemd-user pam config when building with
--noprep so let's install the pam config file using a regular source
instead of patching the one provided by systemd.
rpm will imply --noprep when using --build-in-place in rpm 4.20 and
we're switching the mkosi rpm builds to use --noprep as well on older
rpm versions. This means we don't need to gate out patch applications
anymore with the %upstream macro.
rpmautospec doesn't like the merge: "unresolvable merge".
To avoid the issue, re-add the changelog file. Also, let's drop the
stuff that is only specific to EPEL, since this branch is primarily
for rawhide.
We had a *lot* of breakage caused by this change internally so let's
make the spec a little more conservative by only applying the shorter
shutdown timer for Fedora builds.
meson on CentOS Stream 9 is too old to properly handle symlinks
when installing test data so the systemd meson build script uses
rsync instead. Let's add the requisite build requires to make that
work.
For our nightly systemd build for the CentOS Hyperscale build it
would be very useful to download sources straight from git main on
github so let's allow defining the "branch" macro to do just that.
In a minimal installation, we pull in coreutils via dependencies.
coreutils-single is much smaller, so bias the resolved towards that.
$ sudo dnf5 install --releasever=rawhide --installroot=/var/tmp/inst1 --use-host-config \
/var/lib/mock/fedora-rawhide-x86_64/result/systemd-standalone-{repart,shutdown,sysusers,tmpfiles}-256.2-5*rpm
After this operation 57 MiB will be used (install 57 MiB, remove 0 B).
$ sudo dnf5 install --releasever=rawhide --installroot=/var/tmp/inst1 --use-host-config \
/var/lib/mock/fedora-rawhide-x86_64/result/systemd-standalone-{repart,shutdown,sysusers,tmpfiles}-256.2-6*rpm
After this operation 41 MiB will be used (install 41 MiB, remove 0 B).
For the CentOS Stream Hyperscale SIG we backport a newer version of
dracut and still want the Conflicts to apply so let's conditionalize
the check on the %upstream macro since we only need it for upstream
builds anyway.
Make sure on centos stream 10 we also conflict with dracut 060-2
and that on centos stream 9 so that the spec can still be used to
build systemd rpms for centos stream 9 upstream in systemd CI that
can be installed on centos stream 9.
(dracut is pulled in as a required dependency of kernel-core so we
can't just not install it on centos stream 9 unfortunately).
Let's make sure we use the vmlinux.h from kernel-devel or none at
all. This makes sure the systemd BPF programs are built against a
known version of vmlinux.h and we don't depend on /sys being available
to generate vmlinux.h ourselves.
Use rpmdev-vercmp to select vmlinux.h from the latest kernel.
This reverts commit a76669ee22.
People create /usr-only images by making an installation and only picking
up /usr from it. In that case, the snippet is needed to re-recreate /home
on the rootfs.
In systemd upstream CI, we only have the rawhide branch, because we import
dist-git via git submodule. But we want to build systemd on F40 too from this
branch, so conditionally ressurect the patch to make that work. This partially
reverts 69d6e44695.
[skip changelog]
I think this is a bug in rpmautospec. The release tag is always generated
as "1". Before this is investigated and fixed, just set it manually.
[skip changelog]
There were a bunch of other commits incl. bugfixes that mean that it'd
make sense to update to the latest snapshot, but I chose not to do that to
avoid introducing new issues. We'll get -rc2 soon enough anyway.
`systemd-ukify` requires `/usr/lib/systemd/boot/efi/{addonx64,linuxx64}.efi.stub` to work properly, e.g.
```
Traceback (most recent call last):
File "/usr/bin/ukify", line 1660, in <module>
main()
File "/usr/bin/ukify", line 1648, in main
check_inputs(opts)
File "/usr/bin/ukify", line 390, in check_inputs
value.open().close()
File "/usr/lib64/python3.9/pathlib.py", line 1252, in open
return io.open(self, mode, buffering, encoding, errors, newline,
File "/usr/lib64/python3.9/pathlib.py", line 1120, in _opener
return self._accessor.open(self, flags, mode)
FileNotFoundError: [Errno 2] No such file or directory: '/usr/lib/systemd/boot/efi/addonx64.efi.stub'
```
`/usr/lib/systemd/boot/efi/{addonx64,linuxx64}.efi.stub` are now contained in `systemd-boot-unsigned` sub-package so adding a dependency on it seems like the easiest solution.
Originally reported by: Vitaly Kuznetsov <vkuznets@redhat.com> in https://issues.redhat.com/browse/RHEL-33990
Signed-off-by: Jan Macku <jamacku@redhat.com>
I think this is a bug in rpmautospec. The release tag is always generated
as "1". Before this is investigated and fixed, just set it manually.
[skip changelog]
https://github.com/systemd/systemd/issues/32508#issuecomment-2079991745
> The new systemd package does the reexec in %postun, but the old one does it in
> %post. So if we install the new one, we don't do any reexec (since %postun
> doesn't run in this case), but once we remove the old one we also don't do any
> reexec, because in this case there's no reexec in %postun:
> # dnf upgrade --rpmverbosity=debug ./*.rpm |& tee log.txt
> ...
> : %postun(systemd-255.5-1.fc41.x86_64): scriptlet start
> D: %postun(systemd-255.5-1.fc41.x86_64): execv(/bin/sh) pid 2649
> D: Plugin: calling hook scriptlet_fork_post in selinux plugin
> D: setexecfilecon: (/bin/sh, rpm_script_t)
> + '[' 1 -eq 1 ']'
> + '[' -w /var ']'
> + journalctl --update-catalog
> + systemd-tmpfiles --create
- Many different small fixes: systemd itself, systemd-networkd,
systemd-journal-remote, compilation fixes for newer kernels and
clang, systemd-homed, systemd-resolved, ukify, systemd-tmpfiles,
various other.
It was removed upstream in 711169905e75617eabf3934273aa37dac02c6458,
except for one call in test/test-functions, but we don't run those
during package build.
[skip changelog]
Most systemd tools run from scriptlets need libsystemd-shared-X.so (from
systemd package), which contains version and release in it's name.
Therefore, the same version of systemd package must be already installed
when they run.
Resolves: #2282821
When backporting the latest changes to CentOS Hyperscale reviewers
were confused by using %version and %release to define "Version" and
"Release" which are supposed to specify the values for %version and
%release. Let's use different macros to make it more clear that these
are supposed to be set by users building the rpm and add a comment
to explain why we do this.
Let's allow overriding the version and release by specifying the
corresponding macros on the rpmbuild command line. This allows us
to specify a custom version and release when doing upstream builds.
When building in upstream mode, the release doesn't really have any
meaning so let's stop passing it as part of the version-tag and
shared-library-tag arguments.
This also makes it possible to make the release a timestamp so that
each package built from upstream is guaranteed to be newer. If we
pass the release to meson via version-tag and shared-library-tag and
the release changes every build, we end up having constant rebuilds
of various targets in meson that depend on the version.
The second argument now specifies the version tag version so let's
adapt. Because the script now supports running without any arguments
at all, let's just do that.
The output now also doesn't use any hyphens anymore so we get rid
of the sed transformation as well;
Currently, the inplace macro only influences whether we use
tools/meson-vcs-tag.sh to figure out the version instead of using
the predefined one. But doing an inplace build shouldn't really
affect the version, since it's possible to do an inplace builds that's
not a git main upstream build, so the two concepts are disjoint.
Instead, let's replace the "inplace" macro with an "upstream" macro
to indicate that we're building from systemd git upstream. Aside from
influencing the version, this also disables various patches and adds
a libarchive dependency that was added upstream recently but isn't in
an official release yet.
There's a bug in dnf5 where it always downloads filelists metadata
even for file dependencies that are in the "allowed" paths, such as
/usr/bin/getfacl. Let's use the package names for now to avoid
downloading the filelists metadata unnecessarily.
See https://bugzilla.redhat.com/show_bug.cgi?id=2263771
/usr/bin/systemd-repart is in systemd-udev, so this Conflicts/Provides
combo was misplaced. (For the Conflicts, this is actually not a real
issue, because systemd-udev Requires systemd, so transitively, the
conflicting packages could not be installed. But for Provides, the
issue is real, because systemd by itself does _not_ provide the
binary.)
This was noticed by rpmdeplint CI job:
Undeclared file conflicts:
systemd-standalone-repart-255.3-1.fc40.x86_64 provides /usr/bin/systemd-repart which is also provided by systemd-udev-255.2-2.fc40.x86_64
- A bunch of various fixes for memory and behaviour, in many different
components (bootctl, systemd, udev, systemd-networkd, systemd-homed,
systemd-logind, systemd-resolve, systemd-repart, systemd-analyze,
systemd-dissect, systemd-boot, pam modules, systemd-storagetm,
systemd-journal-remote, kernel-install)
- Improved detection of virtualization (Google Compute Engine, Apple Virt)
- Updates for shell completions and docs
- An update for hardware database
Our config files in /etc/ were marked as %config(noreplace). This means that the
would not be replaced on upgraded if local modifications have been made. But
when we moved them to /usr/lib, they would be be renamed to .rpmsave, if they
had local modifications. This is not what I expected, but what rpm apparently
does. So we need to add them as %ghost to prevent the removal. This is probably
for the better anyway.
This is a bit of a mess: sshd can only load configuration from
/etc/ssh/sshd_config.d, and that directory is declared as non-world-readable.
This is in violation of the packaging guidelines which say that packaged files
must be world-readable, and also makes very little sense, since those files
are part of the package payload.
If we create the directory with different permissions, and list it in %files,
installation will fail. If we don't list it in %files, and the user doesn't have
openssh-server installed, they will have an unowned directory. Another option
would be to depend on owner of this directory, i.e. openssh-server, but we don't
want to have that dependency. So let's copy the %files line from openssh-server
and figure out what to do if it changes in openssh-server again.
... (e.g. /etc/systemd/system.conf → /usr/lib/systemd/systemd.conf).
Both config file locations were already supported, and the files
installed in /etc/ were "empty" (i.e. they had only comments and section
headers). The move does not change the configuration, but just makes
/etc more empty by default. See
6495361c7d for more
discussion and details.
We would fail later anyway, because rpm refuses %files with an empty filelist
file. But this is much later, after %check, so let's fail already in %install.
[skip changelog]
The idea was that it's nicer to keep that config in .spec where it's subject
to syntax highlighting. split-files.py was supposed to a stand-alone program.
But in practice this split is confusing, because file rules are listed in two
places and we need to modify split-files.py quite often. This will be easier if
everything is in one file.
[skip changelog]
The LICENSE.LGPL2.1 file is installed into the same systemd license
directory for both the base systemd and -libs. Because the base
systemd requires the -libs sub package it's a duplicate and will
always be there, it shouldn't cause an issue but it seems in some
cases the duplication into the same directory causes issues with
ostree so remove it from the base systemd package as it will always
be there due to the hard dep on the -libs subpackage.
... (rhbz#2240828)
We currently have grubby-8.40-72.fc39 and sdubby-1.0-3.fc39.
systemd had 'Conflicts: grubby < 8.40-72', which is satisfied by grubby.
But sdubby has 'Provides: grubby' (with no version), which prevented
installation:
$ sudo rpm -i ./sdubby-1.0-3.fc39.noarch.rpm
error: Failed dependencies:
grubby < 8.40-72 conflicts with (installed) systemd-udev-254.2-7.fc39.x86_64
The rpm docs don't actually say what the meaning of the 'if' is:
is it only satisfied by actual package names, or also by Provides. But
experiments suggest that Provides are not used. The rich dependency seems
to avoid the issue.
This reverts commit 8eea43e714.
Fedora already ships 'disable systemd-boot-update.service' in
/usr/lib/systemd/system-preset/90-default.preset, so we don't need
this.
[skip changelog]
The macro expansions would only work when compiled with a recent version of
systemd. We don't want to create a dependency loop like this, let's just expand
the string manually.
Also backport the patch adding %systemd_postun_with_reload and
%systemd_user_postun_with_reload so a FPC documentation change can be filed.
Let's make sure we clean up after ourselves. We have to remove
the generated timeout user config file, the file list files and the
generated .lang file.
... (rhbz#2217997)
systemd-homed.service and systemd-portabled.service are in
systemd-udev but the scriptlet was attached to main subpackage, so it
wouldn't work because the unit file wasn't installed yet when it was
invoked. systemd-pstore.service and remote-cryptsetup.target were
forgotten, so they wouldn't get enabled on installation.
Rpm >= 4.19 has native sysusers integration and generates similar
user() and group() provides but encodes additional information into
them, information that is required for the rpm integration to work.
Besides additional data, one noteworthy difference in the rpm generated
provides is there are no provides generated for m(ember) directives.
This is because users and groups possibly created by that directive are
a too implicit for dependency resolution and install ordering purposes
in the case where the user/group is actually owned by some other package.
Admittedly I don't know what I'm doing here, but this should make
systemd-oomd kill things less often, which seems like the direction we
want to move towards, so let's try it.
https://pagure.io/fedora-workstation/issue/358
... (rhbz#2104141)
In the first version, I wanted to use POSIX quotes with $''. But that required
'printf %q', which brings in a dependency on coreutils.
Following mcr0mmand's suggestion, ${foo@Q} is used instead, which should work
equivalently, and does not require anything new.
Tested with 'sysusers.generate-pre.sh /usr/lib/sysusers.d/*conf'. The output is
the same before and after, apart from the dovecot user with a quote.
... (rhbz#2177722)
Oomd was killing a login session (user-*.slice/session-*.scope).
Quoting https://bugzilla.redhat.com/show_bug.cgi?id=2177722#c21:
> In F37 and prior the config was killing based on swap and pressure
> on user-*.slice/user@.service. In 7665e1796f
> it was changed to pressure only on system.slice and all slices under
> user.slice. The relevant point here is that this change now includes
> user-*.slice/session-*.scope which is the critical session bits
> you're seeing killed here.
>
> That session scope should be omitted. The config that I intended
> with the initial PR was for all slices under
> user.slice/user-*.slice/user@.service to be monitored, not for all
> slices under user.slice.
With the file removed:
$ oomctl | rg Path | sort
Path: /system.slice
Path: /user.slice/user-1000.slice/user@1000.service/app.slice
Path: /user.slice/user-1000.slice/user@1000.service/session.slice
See https://github.com/systemd/systemd/pull/26641.
This will allow upstream pull request (and the main branch after the pull
request has been merged) to be built with the new code. This doesn't do
anything for official rpm builds until the new code is part of the sources.
[skip changelog]
... (rhbz#2164594)
The socket exists and is enabled in the initrd. After switch-root, the system
goes into an infinite loop trying to stop the socket while incoming audit
messages trigger start jobs for the socket. This is a bug in the transaction
logic, that'll need to be fixed separately.
We need to preset the socket after the upgrade so that it remains enabled
by default. This should fix the boot issue, though it's not a complete fix,
because we actually want to allow people to disable the socket.
On initial install, the socket is covered by preset-all and gets enabled.
gcc has a new warning which caught a bug of int/enum mismatches.
And we would crash on some architectures when built with -D_FORTIFY_SOURCE=3
because of our malloc_usable_size() use.
This should resolve the build failure in F38 mass build.
- Fixes a few different issues (systemd-timesyncd connectivity problems, broken
emoji output on the console, crashes in pid1 unit dependency logic)
- CVE-2022-4415: systemd: coredump not respecting fs.suid_dumpable kernel
setting
As requested in https://github.com/rhinstaller/anaconda/pull/4368#discussion_r1043839809,
so that it's easier to depend on the appropriate package. Once we have the
signed version built, this provides might be dropped. But let's add it at least
for now so that there's a stable name to depend on.
While at it, let's drop ? from %{_isa}. Systemd is always archful.
This file changes rarely, but it does every one in a while. And since we have an
independent copy, we forget to adjust it. We have had already two bugs because
of this. I submitted a PR upstream to include pam_namespace (because that makes
sense for all distros), so the diff between upstream and us now is just the
inclusion of system-auth (which is not upstreamable).
Effectively, the only difference right now is that 'pam_keyinit force revoke'
is included. It was added upstream with the comment:
We want that systemd --user gets its own keyring as usual, even if the
barebones PAM snippet we ship upstream is used. If we don't do this we get
the basic keyring systemd --system sets up for us.
4047e4fb7b got things very wrong.
The trick with "[ $1 -eq 1 ]" doesn't work for transaction triggers
because the argument is not provided by rpm. We need to use a state
file to propagate the information from %post to %posttrans.
... (for details see https://raw.githubusercontent.com/systemd/systemd/v252-rc1/NEWS)
systemd-pcrphase and systemd-measure and initrd-* units are moved to systemd-udev.
systemd-udev should be part of the initrd, and those tools don't make much sense
in systems without hardware (i.e. containers). (systemd-measure could possibly be
useful, but we can always move it back if there's a good reason.)
This tweaks the sysusers.d handling logic so that 'm' entries are
now translated to a series of groupadd + useradd + usermod call.
The last usermod call is the notable change, effectively affecting
the list of secondary groups now.
- Remove swap policy. Default amount of swap (8GB?) is a lot lower than
what we use internally with the swap policy. Which frequently leads to
GNOME getting killed
(e.g. https://bugzilla.redhat.com/show_bug.cgi?id=1941170, and other
BZs not linked here). Internally we use 0.5x-1x size of physical memory
for swap via swapfiles (this will be documented in systemd upstream).
In simple cases of using more memory than is available (but without
memory pressure), the Kernel OOM killer can handle killing the
offending process.
- Expand the memory pressure policy to system.slice, user-.slice, and
all user owned slices. Support for ManagedOOM*= on user services was
added in https://github.com/systemd/systemd/pull/20690 which allows
us to be more fine grained on the pressure monitoring at the user
level. In addition to the system.slice and user-.slice PSI monitoring
this should result in a better systemd-oomd experience for desktop
systems.
Instead, add systemd-pam to pungi-fedora's multilib whitelist:
https://pagure.io/pungi-fedora/pull-request/1113
This should help with flatpak runtime packaging so that we can avoid
having to ship systemd-pam in the flatpak container.
https://pagure.io/releng/issue/10952: rpmdev-bumpspec apparently does
not like the way the Release field was conditionalized.
But since the switch to rpmautospec this isn't important, since the
v-r string will be generated by rpmautospec. I went over the changelog
and manually inserted tags for the old builds.
Unfortunately there's another issue, rpmautospec cannot deal with
%include: https://pagure.io/fedora-infra/rpmautospec/pull-request/267
Numbers for the latest builds are adjusted to match what koji lists.
Now that the tmpfiles snippet is a separate file shipped as part
of the networkd package, we can ship the sysusers snippet as a part
of the networkd package as well.
It turns out that with the Obsoletes, dnf will just install the normal
systemd package if systemd-standalone-* is requested. The commit message
for b36512ad8f which added this says I tested
with local package builds (where it works), but not when going through the
full repo with all packages.
I'm adding the Provides instead, so that it's possible to request on or
the other more easily.
I asked on fedora-devel@, and the lone reply was from Matthew Miller
who tried it once when it was introduced and hasn't used it since.
Dropping this removes the last dependency on libgcrypt and libgpg-error
in libsystemd, significantly reducing our installation footprint.
Right now libmicrohttpd is still linked to libgcrypt, so
libsystemd-journal-remote subpackage will pull libgcrypt in.
When -Dversion-tag was initially added in edaa157918,
I used "v" without any comment. But upstream does not use "v", so we have
versions which don't compare directly:
$ build/systemctl --version|head -n1
systemd 251 (251-66-g7e46a5c+)
$ systemctl --version|head -n1
systemd 251 (v251-1.fc37)
And in 3c4f9413a7, when -Dshared-lib-tag= was
introduced, %{version} was replaced by %{version_no_tilde}, again without any
specific comment. For the shared-lib-tag, it makes sense to use _no_tilde,
because it's enough to have non-conflicting file names, and we don't compare
the tags. I guess I wanted both uses to be consistent. But if we substitute
the tilde, we can't do proper comparisons.
I noticed the following issue: with sd-boot installed from git and a
package, upgrades wouldn't work:
Comparing versions: "systemd-boot v251-1.fc37" < "systemd-boot 251-rc1-390-g3603f15
Skipping "/boot/efi/EFI/systemd/systemd-bootx64.efi", since newer boot loader version in place already.
The two changes should make those comparisons work properly in most
cases.
I tested this with 'sudo dnf --installroot=…', with both
systemd+system-udev installed in one transaction, and in two separate
transactions. Users are created as expected in both cases.
$ rpm -qlv systemd |grep -v 'root root'
-rw-rw-r-- 1 root utmp 0 Jan 22 03:38 /run/utmp
-rw-rw---- 1 root utmp 0 Jan 22 03:38 /var/log/btmp
-rw-rw-r-- 1 root utmp 0 Jan 22 03:38 /var/log/lastlog
-rw-rw-r-- 1 root utmp 0 Jan 22 03:38 /var/log/wtmp
drwxr-sr-x 2 root systemd- 0 Jan 22 03:38 /var/log/journal
During installation rpm would log an error that systemd-journal group
is unknown. We create all our users by calling sysusers in the %post
scriptlet, but that is too late. To avoid the warning we could either
add a %pre scriptlet, but that'd require adding a dependency on
shadow-utils for groupadd, since we can't use our own tools before we
are installed. Let's instead create the directory owned by root.root,
and change the group afterwards. The group ownership is for file
ownership, and in the worst case (we don't assign the group or set
mode +s), unprivileged users will not be able to read the logs.
We also use 'utmp' group, but that is provided by setup.rpm and is not
an issue.
https://bugzilla.redhat.com/show_bug.cgi?id=2018913#c24
For https://fedoraproject.org/wiki/Changes/RenameNobodyUser a scriptlet
was introduced with prevents nss-systemd from synthesizing entries for nobody.
Let's remove the scriptlet: very few people upgrade from such old systems,
and even if they do, having a duplicate entry for nobody is annoying
but hardly a big problem.
(The other side of this, support in nss-systemd remains in place.)
This allows deps on the tools used in the scriptlet to be dropped from -libs.
While at it, also drop noop ldconfig scriptlets.
Related to: https://fedoraproject.org/wiki/Changes/Make_Authselect_Mandatory
Both systemd and resolved nss modules are now enabled by default in
authselect. Users are now expected to use authselect to configure
the system and packages should no longer support non-authselect
configurations.
Resolves: rhbz#2023743
This reverts commit 2afe364ac4.
Unfortunately the build failed on dependencies:
DEBUG util.py:444: Error:
DEBUG util.py:444: Problem: package authselect-libs-1.3.0-1.fc36.x86_64 conflicts with glibc < 2.34.9000-27 provided by glibc-2.34.9000-26.fc36.x86_64
DEBUG util.py:444: - package util-linux-2.37.2-1.fc36.x86_64 requires /etc/pam.d/system-auth, but none of the providers can be installed
DEBUG util.py:444: - package gawk-5.1.1-1.fc36.x86_64 requires libm.so.6()(64bit), but none of the providers can be installed
DEBUG util.py:444: - package gawk-5.1.1-1.fc36.x86_64 requires libm.so.6(GLIBC_2.2.5)(64bit), but none of the providers can be installed
DEBUG util.py:444: - package gawk-5.1.1-1.fc36.x86_64 requires libm.so.6(GLIBC_2.29)(64bit), but none of the providers can be installed
DEBUG util.py:444: - package gawk-5.1.1-1.fc36.x86_64 requires rtld(GNU_HASH), but none of the providers can be installed
DEBUG util.py:444: - package gawk-5.1.1-1.fc36.x86_64 requires libc.so.6(GLIBC_2.34)(64bit), but none of the providers can be installed
DEBUG util.py:444: - conflicting requests
I need to build the package again in rawhide, so this needs to be reverted
for now.
Related to: https://fedoraproject.org/wiki/Changes/Make_Authselect_Mandatory
Both systemd and resolved nss modules are now enabled by default in
authselect. Users are now expected to use authselect to configure
the system and packages should no longer support non-authselect
configurations.
Resolves: rhbz#2023743
This adds support for parsing static UIDs and GIDs from sysusers.d
fragments, and automatically forwarding them to the generated
'Provides' entries.
It will allow inspecting users/groups with static IDs directly
from package metadata:
```
$ rpm --query --provides --package gdm-41.0-3.fc36.x86_64.rpm
[...]
group(gdm) = 42
user(gdm) = 42
```
If /etc/resolv.conf pointed to systemd-resolved stub configuration, it
is obvious it would stop working. Compensate it by deleting the link, it
would be created again on installation. Try to pass ownership to NM,
which also provides similar file. Keep it missing otherwise, might be
created by unknown tool on reboot.
Signed-off-by: Petr Menšík <pemensik@redhat.com>
Move systemd-resolved daemon and related tools to its own subpackage.
Keep only nss-resolve in systemd, the service itself is moved to
subpackage. It has quite different functionality than systemd package
and deserves own package.
Still recommend resolved from main package
Keep backward compatibility and still recommend systemd-resolved. Allow
removal, but would be installed by default.
This allows a fairly big dependency chain to be pruned in the future,
now other packages pull in setup:
/usr/bin/groupadd → shadow-utils → setup.
It seems we don't need the setup rpm for anything in minimal installations.
There should be no functional change. Testing will be prudent.
systemd-rpm-macros is small, but it pulls in bash and is always one more package.
It is only useful if the rpm building utilities are there, so let's conditionalize
on that.
This is in preparation for https://src.fedoraproject.org/rpms/systemd/pull-request/52,
splitting out systemd-resolved subpackage. The new package should
be pulled in by comps, but this would create a "flag day", because
the systemd-resolved name is currently unknown. So let's add the
virtual Provides now. Even if the package is never split out, it doesn't
cause any harm.
systemd-cryptsetup and systemd-veritysetup link with libcryptsetup, so
this dependency is already in Requires. (Well, not in bootstrap mode,
but I'm pretty sure we don't want to publish rpms built in bootstrap
mode, so it shouldn't matter.)
/etc/rc.d/init.d/README was marked as %config(noreplace), which seems
to be a clear bug. But this primarily affects new README files in
all the .d directories.
There isn't really a one size fits all policy since pressure can change
a lot based on whether you have flash or spinning disks (and your swap
configuration as well). But let's be a bit more conservative here.
From a branding perspective, having the fallback hostname be "fedora" for an OS that is not Fedora Linux is incorrect. Go back to using "localhost" in those cases.
This reverts commit db19323db2.
Paths are adjusted. The condition is inverted to actually check the
right thing.
The test is moved before build to make it easier to see. Meson does
the .in substitutions immediately after configuration, so this should
be easier to see.
All scriptlets to disable services upon final package removal are
removed. Removing rpm from a running system is not allowed by dnf and
would generally result in mayhem. Trying to clean up our enablement
symlinks is not useful. Nobody tests this and it almost certainly was
incomplete.
Only do 'journalctl --update-catalog' if /var is writeable, and remove
suppression of errors from 'journalctl --update-catalog'. It shouldn't
fail, and it it does, we should figure out why.
On upgrades, execute 'journalctl --update-catalog' and
'systemd-tmpfiles --create' in %postun, not %post. This way we won't
look at possibly-about-to-be-removed configuration.
Restart various services upon upgrade: systemd-timedated.service
systemd-timesyncd.service systemd-portabled.service
systemd-homed.service systemd-hostnamed.service
systemd-journald.service systemd-localed.service systemd-userdbd.service.
Not doing this was a bug.
user@.service and systemd-logind.service will need special handling
and are not done in this patch.
Changes for https://fedoraproject.org/wiki/Changes/EnableSystemdOomd.
Backports primarily PR #18361, #18444, and #18401 (#18401 is not merged
at the time of writing this commit) + some minor PRs to handle conflicts.
Creates systemd-oomd-defaults subpackage to install unit drop-ins that
will configure systemd-oomd to monitor and act.
This patch enables support of the following options in
/etc/crypttab:
- no-read-workqueue
- no-write-workqueue
This patch corresponds to the upstream pull request that has been
merged and will be in systemd 248:
https://github.com/systemd/systemd/pull/18062/
Sadly, this does not work.
It seems NM queries resolved for the local IP address and gets "linux"
and sets that as the transient hostname. Resolved has a "fallback hostname"
(that will now again be "fedora"), but it also has a fallback fallback hostname
that is "linux" that it used in reverse dns queries and such. NM gets
the "linux" name and tells hostnamed to use that as the transient hostname.
I don't think this is an improvement, since "linux" is a problematic
as "fedora". So let's revert this for now to avoid pointless churn,
until we figure out a real solution.
Unset fallback-hostname as plenty of applications expected localhost
to mean "default hostname" without ever standardising it (#1892235)
This reverts commit 6eb8bcde28.
DNS questions (which necessarilly include IP addresses) are personally
indentifying information in the sense of GDPR
(https://gdpr.eu/eu-gdpr-personal-data/ explicitly lists IP address as
PII). Sending those packets to Google or Cloudflare is "forwarding"
this PII to them. GDPR says that information which is not enough to
identify individuals still needs to be protected because it may be
combined with other information or processed with improved technology
later. So even though the information in DNS alone it not very big, it
may be interpreted as protected information in various scenarios.
When Fedora is installed by an end-user, they must have the reasonable
expectation that Fedora will contant Fedora servers for updates and
status checks and such. But the case of DNS packets is different,
because the dns servers are not under our control. While most of the
time the information leak through DNS is negligible, we can't rule out
scenarios where it could be considered more important.
Another thing to consider is that ISP and other local internet access
mechanisms are probably worse overall for privacy compared to google and
cloudflare dns servers. Nevertheless, they are more obvious to users and
fit better in the regulatory framework, because there are local laws
that govern them and implicitic or explicit agreements for their use.
Whereas US-based servers are foreign and are covered by different rules.
The fallback DNS servers don't matter most of the time because
NetworkManager will include the servers from a DHCP lease. So
hopefully users will not see any effect from the change done in this
patch. Right now I think it is better to avoid the legal and privacy
risk. If it turns out this change causes noticable problems, we might
want to reconsider. In particular we could use the fallback servers
only in containers and such which are not "personal" machines and there
is no particular person attached to them.
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/3C4KESHIMZDB6XCFO4EOBEDV4Q2AVVQ5/
I think we could provide a default dns server list more reasonably if
there was some kind of privacy policy published by Fedora and users
could at least learn about those defaults. Sadly, we don't have any
relevant privacy policy (https://pagure.io/Fedora-Council/tickets/issue/53).
There were some things left in the main package that should have
been in the sub package (including networkd.conf). This is an attempt
to make the list of files in the networkd package more correct.
It explicitly tries to leave sytemd-network-generator and the network
targets in the main package.
This way, if one wants to opt-out of resolved, installing a preset
that disables the service is enough. Previously that would only disable
the service, but a dangling symlink would be created.
I'm not entirely sure if this is the right form...
Is Conflicts? useful when we have Obsoletes?
Seem to work OK. I tested:
dnf --installroot=... install x86_64/systemd-standalone-sysusers-246.6-2.fc34.x86_64.rpm x86_64/systemd-standalone-tmpfiles-246.6-2.fc34.x86_64.rpm
→ succeeds with a new installation
→ fails if the installroot already had systemd installed
dnf --installroot=... install x86_64/systemd{,-libs,-pam}-246.6-2.fc34.x86_64.rpm noarch/systemd-noarch-246.6-2.fc34.noarch.rpm
→ uninstalls the two standalone packages
These packages include binaries that link to a static version of
libsystemd-shared, so they don't depend on the systemd-libs package at
runtime.
These packages are intended to expose systemd-tmpfiles and systemd-sysusers
to non-systemd systems, such as container images.
Note that static linking only pulls in the small subset of functions from
libsystemd-shared that are actually used by the binaries, so the total size of
a statically linked binary is much smaller than the sum of the shared binary
with the shared library. The resulting binaries on an x86_64 build have 272KB
(tmpfiles) and 180KB (sysusers).
This commit relies on the -Dstandalone-binaries=true build configuration that
was pushed upstream in PR 16061 and released in systemd v246.
We need to disable it by default in resolved so that it doesn't fight
with avahi for the port when both are started up in parallel.
I also moved nss-files before nss-resolve. This is unfortunate because
resolved cached files and with the move, the file will be re-read on each
query. Nevertheless, we want nss-files to have higher priority than nss-mdns
to honour local config. Fortunately, only some people put lots of entries
in /etc/hosts, so the inefficiency incurred by this isn't important for
most users.
nss-myhostname is moved after nss-files, following the change in
upstream recommendations.
error: line 639: Trigger fired by the same package is already defined in spec file: %post libs
It's not clear what rpm is complaining about here, but the two %triggerun's
for the same package seem to be the most likely offender.
I wanted to avoid applying to preset reset twice, alas.
The default line is
> hosts: files dns myhostname
Some people might insert mymachines, most likely as:
> hosts: mymachines files dns myhostname
The scriptlet for nss-mdns inserts mdns before dns:
> hosts: ... files mdns4_minimal [NOTFOUND=return] dns ...
The scriptlet replaces 'files dns myhostname' with
> resolve [!UNAVAIL=return] myhostname files dns
This follows the upstream recommendation. myhostname is ordered earlier
because
a) it's more trustworthy than files or especially dns
b) resolve synthetizes the same answers as myhostname, so it doesn't
make much sense to have myhostname at any other place than directly
after resolve, so that if resolve is not available, we get answers for
the names that myhostname is able to synthesize with the same priority.
See https://fedoraproject.org/wiki/Changes/systemd-resolved.
From time to time there's systemd update with new features which could break an
SELinux enabled system. In order to minimize possible damage on composes we need
to be sure that a system can boot with new systemd and it doesn't generate any
AVC denial.
This test reboots a machine and collects AVC, USER_AVC and SELINUX_ERR audit
messages into avc.log file which is propagated as test artifact.
The acl package is not present in the buildroots when building
in bootstrap mode, but test-acl-util needs /usr/bin/getfacl.
Thus it should be an explicit build-time dependency.
writev(2</dev/pts/0>, [{iov_base="mnt ids of /proc/filesystems are 700, 725", iov_len=41}, {iov_base="\n", iov_len=1}], 2mnt ids of /proc/filesystems are 700, 725
) = 42
writev(2</dev/pts/0>, [{iov_base="the other path for mnt id 725 is /proc", iov_len=38}, {iov_base="\n", iov_len=1}], 2the other path for mnt id 725 is /proc
) = 39
writev(2</dev/pts/0>, [{iov_base="Assertion 'path_equal(p, t)' failed at src/test/test-mountpoint-util.c:94, function test_mnt_id(). Aborting.", iov_len=108}, {iov_base="\n", iov_len=1}], 2Assertion 'path_equal(p, t)' failed at src/test/test-mountpoint-util.c:94, function test_mnt_id(). Aborting.
