IF YOU WOULD LIKE TO GET AN ACCOUNT, please write an
email to Administrator. User accounts are meant only to access repo
and report issues and/or generate pull requests.
This is a purpose-specific Git hosting for
BaseALT
projects. Thank you for your understanding!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
With a sufficiently large initrd, the tests take 25 s on my laptop.
Normally, they'd be quicker, but since we use what we find on the
system, we don't control this. Let's raise the timeout to reduce the
chances of a spurious failure.
pytest intentionally keeps around a limited number of the previous test
temporary directories [1]. This is generally OK, but in our tests that generate
initrds, we create a few very large files (both the initrd and kernel in a few
copies), which quickly adds up. I had a particularly large initrd (because of
some mkosi-initrd shenanigans), and I unded up with dozens of gigabytes of
temporary files from the tests. Let's just nuke the dirs where we write
kernel data.
[1] https://github.com/pytest-dev/pytest/issues/543
On Fedora systemd recently moved all of its configuration files to
/usr/lib/ [0], so make sure we account for this case as well.
[ 42.450325] testsuite-17.sh[800]: + mkdir -p /run/udev/rules.d
[ 42.466504] testsuite-17.sh[800]: + cp -f /etc/udev/udev.conf /etc/udev/udev.conf.bckp
[ 42.503348] testsuite-17.sh[802]: cp: cannot stat '/etc/udev/udev.conf': No such file or directory
[0] 29eb35530b
Since we restart systemd-udevd here a couple of times, we might hit the
rate limit in later tests:
[ 26.028355] testsuite-17.sh[2074]: + udevadm control -e
[ 26.028355] testsuite-17.sh[2074]: + udevadm control -l emerg
[ 26.126160] systemd[1]: systemd-udevd.service: Start request repeated too quickly.
[ 26.126213] systemd[1]: systemd-udevd.service: Failed with result 'start-limit-hit'.
[ 26.140310] systemd[1]: Failed to start systemd-udevd.service.
[ 26.140897] systemd[1]: systemd-udevd-control.socket: Failed with result 'service-start-limit-hit'.
[ 26.141286] systemd[1]: systemd-udevd-kernel.socket: Failed with result 'service-start-limit-hit'.
[ 26.142225] testsuite-17.sh[2074]: + udevadm control -l alert
[ 26.149206] udevadm[2088]: Failed to send request to set log level: No such file or directory
Follow-up to: 6ef512c0bb
It doesn't really make sense to go looking for these inside the
given root directory. While we should resolve specifiers and such
based on the given root directory, let's look up the image definitions
on the host system as there's a good chance they're coupled to the
repart version we're using so there's all kinds of chances for problems
if we use the definitions from the image we're building instead of those
from the host.
So far we created the target directory, and the source for bind mounts,
but not workdir/upperdir for overlays, so it has to be done separately
and strictly before the unit is started, which is annoying. Check the
options when creating directories, and if upper/work directories are
specified, create them.
For unit instances install_info_discover() returns path to the template,
which then generates confusing errors when passed to
do_unit_file_enable():
~# build/systemctl --root=/tmp/systemctl-test.N9ysbz reenable templ1@two.service
Unit name: templ1@two.service; p: /etc/systemd/system/templ1@.service
Removed "/tmp/systemctl-test.N9ysbz/etc/systemd/system/services.target.wants/templ1@two.service".
Failed to reenable templ1@.service, destination unit services.target is a non-template unit.
This can also be seen with a different reproducer using getty@.service
and a simple bind mount to / - there's no error this time, but it tries
to create a symlink for the default instance (from DefaultInstance=tty1),
which is also incorrect:
~# SYSTEMD_LOG_LEVEL=debug systemctl --root /mnt/bindroot/ reenable getty@test.service
Symlink /mnt/bindroot/etc/systemd/system/getty.target.wants/getty@tty1.service → /usr/lib/systemd/system/getty@.service already exists
Follow-up to: 29a7c59abbe
Resolves: #24740
If a unit is running in an image and wants to survive a soft-reboot,
then it can't be deactivated by the storage of the image going away.
Relax the dependency to a Wants=. Access to the image is not needed
when the unit is running anyway, so downgrade to Wants=.
The read-only bit is flipped after setting up all the mounts, so that
bind mounts can be added. Remove the early config, and add a unit
test.
Fixes https://github.com/systemd/systemd/issues/30372
The mkfs binary might unlink the path we give it and replace it with
a new file so let's make sure that our fd points to any new file rather
than the old deleted file.
Specifically this fixes erofs partition generation.
The `.mem_total` variable has `uint64_t` type, therefore, when multiplying the number
`20971512` by the number `1024` with the suffix `U`, we will not get the expected result of
`21,474,828,288`, since the number `20971512` without an explicit type indication has
`uint32_t` type.
First, multiplication will occur in accordance with the `uint32_t` type; this operation will
cause a **type overflow**, and only then will this result be assigned to a `uint64_t` type
variable.
It's worth adding the `UL` suffix to the number `20971512` to avoid **overflow**.
Found by Linux Verification Center (portal.linuxtesting.ru) with SVACE.
Author A. Slepykh.
When [Link] MTU= is specified in a .network file, we have no idea about
that what kind of interface will be configured with the .network file.
The maximum and minimum MTU size depend on the kind of interface.
So, we should not filter MTU eagerly in the parser.
Closes#30140.
CAN devices do not support IP layer.
Most of the functions below are never called for CAN devices, but
link_set_ipv6_mtu() may be called after setting interface MTU, and warn
about the failure.
For safety, let's unconditionally check if the interface is not a CAN
device.
We already highlight sections and "de-highlight" comments, so let's add
the last piece of the puzzle and highlight the configuration directives
to visually distinguish them from the values.
Closes: #13416
7e3607996a creates a symlink under /etc/ssh/sshd_config.d/ and with
current Rawhide RPM stuff the systemd RPM tries to take ownership of
that directory which conflicts with the openssh-server package. Let's
temporarily tweak the regex in split-files.py until this changes makes
it to Rawhide.
When --after-cursor=/--cursor-file= is used together with a journal
filter, we still skipped over the first matching entry even if it wasn't
the entry the cursor points at, thus missing one "valid" entry
completely. Let's fix this by checking if the entry cursor after seeking
matches the user provided cursor, and skip to the next entry only when
the cursors match.
Resolves: #30288
Currently the check doesn't take any settings from nspawn settings
files into account, so let's delay the check until after we've
loaded any settings file.
cryptsetup reads a bunch of credentials now but we don't pass import
those in any service units yet. Let's pass through all cryptsetup
prefixed credentials to the systemd-cryptsetup@root instance.
Request with Range header like 'entries=<cursor>:' (with a colon at the end,
invalid syntax per the doc), is now rejected with error 400 Bad Request.
fix#4883
When the same disk image is written to multiple storage units, for
example an external SD card and an internal eMMC, the symlinks in
/dev/disk/by-{label,uuid,partlabel,partuuid}/ are no longer unique, and
will point to the device that is probed last.
Adressing partitions via labels and UUIDs is nice to work with, and
depending on the use case, it might also be more robust than using the
symlinks in /dev/disk/by-path/ containing the partition number. Combine
the two approaches to create unique symlinks containing both the device
path as well as the respective UUIDs or labels, and throw in a symlink
using the devpath and the partition number for the sake of completeness.
For an exemplary GPT-partitioned disk at "platform-2198000.mmc" with a
partition containing an ext4 file system, this might create symlinks of
the following form:
/dev/disk/by-path/platform-2198000.mmc-part/by-partnum/1
/dev/disk/by-path/platform-2198000.mmc-part/by-partuuid/e5a75233-3b90-4aec-8075-b4dd7132b48d
/dev/disk/by-path/platform-2198000.mmc-part/by-partlabel/rootfs
/dev/disk/by-path/platform-2198000.mmc-part/by-uuid/b2c92f24-8215-4680-b931-f423aae5f1c9
/dev/disk/by-path/platform-2198000.mmc-part/by-label/rootfs
Signed-off-by: Roland Hieber <rhi@pengutronix.de>
While at it, rephrase the output a bit. Before this commit, if
the pid doesn't exist, we output something hard to interpret -
"Failed to get unit for ourselves".
