Let's utilize the full power of Packit and run some tests with the just
built RPMs. This makes use of the Fedora infrastructure provided by
the Testing Farm project [0][1].
With the current configuration, the `tests` job runs tests from the
Fedora tests repository [2] in a very similar fashion like Ubuntu CI
does, just with different metadata all around it. ATTOW there are only
two tests, which are wrappers around unit tests and integration tests;
the latter one currently runs only nspawn-based tests, since there's no
KVM on the test VMs, and, for now, I'd like to see how well the infra is
going to manage our upstream traffic and how stable the whole thing is
end up being before increasing the work load.
[0] https://docs.testing-farm.io/Testing%20Farm/0.1/index.html
[1] https://packit.dev/docs/configuration/upstream/tests
[2] https://src.fedoraproject.org/tests/systemd
I'm pretty sure this is not the only case, but it's the one I recently
noticed. Even though we call ddebug() from a function, that function is
called before ddebug() is defined, resulting in the same issue as if we
called just ddebug() in its place, i.e.:
..//test-functions: line 276: ddebug: command not found
This footgun should at least be documented, if there's not going
to be a shortcut setting to establish the async `journalctl
--follow` equivalent.
Fixes: https://github.com/systemd/systemd/issues/2815
This fixes a regression introduced by
42551ea7e9.
In the shell script version, plugin failures are propagated to the
caller. But after the commit, failures in plugins are logged, but never
propagated as the exit code of the execution.
Fixes#30087.
This will bring in the fix for rawhide/tumbleweed builds (new libsolv
capable of handling zstd). If all goes well it will migrate to jammy
proper in a week and it can be reverted
On kernel 5.10.178, when a squashfs file is stored on an EXT4 filesystem
backed by a dm-crypt volume, dissecting fails:
$ SYSTEMD_LOG_LEVEL=debug systemd-dissect /var/foo/bar.raw
Opened '/var/foo/bar.raw' in O_RDONLY access mode, with O_DIRECT enabled.
Couldn't find any partition table to derive sector size of.
loop2: Acquired exclusive lock.
Could not enable direct IO mode, proceeding in buffered IO mode.
Successfully acquired /dev/loop2, devno=7:2, nr=2, diskseq=87
Opened /dev/loop2 (fd=3, whole_block_devnum=7:2, diskseq=87).
Name: bar.raw
Size: 67.2M
Sec. Size: 512
Arch.: n/a
Successfully forked off '(sd-dissect)' as PID 4110.
Mounting /proc/self/fd/3 (squashfs) on /tmp/dissect-Zk3K5F (MS_RDONLY|MS_NODEV "")...
Failed to mount /proc/self/fd/3 (type squashfs) on /tmp/dissect-Zk3K5F (MS_RDONLY|MS_NODEV ""): Input/output error
Failed to mount dissected image: Input/output error
Failed to read /etc/hostname of image: No such file or directory
/etc/machine-id file of image is empty.
Failed to read has-init-system boolean: Input/output error
(sd-dissect) failed with exit status 1.
Failed to acquire image metadata: Input/output error
The kernel shows I/O errors:
kernel: blk_update_request: I/O error, dev loop2, sector 0 op 0x0:(READ) flags 0x800 phys_seg 1 prio class 0
kernel: SQUASHFS error: Failed to read block 0x0: -5
kernel: unable to read squashfs_super_block
This is independent of a particular filesystem and can be reproduced
reliably in my setup, starting from freshly formatted disks.
Instead of continuing when O_DIRECT fails, start over the setup
process without the flag, including opening a new FD, to make the
kernel happy.
According to org.freedesktop.login1:
> If "na" is returned, the operation is not available because
> hardware, kernel, or drivers do not support it. If "yes" is
> returned, the operation is supported and the user may execute
> the operation without further authentication. If "no" is returned,
> the operation is available but the user is not allowed to execute
> the operation.
Therefore, we should return "no" if sleep is explicitly disabled,
otherwise we return "na".