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!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
The newest kconfig enabling DB-verified dm-verity images is queued
for 6.11:
https://patchwork.kernel.org/project/dm-devel/patch/20240617220037.594792-1-luca.boccassi@gmail.com/
(cherry picked from commit a79b6dc0706dd5fe76ec56b3308b402c133ead23)
(cherry picked from commit c32f71aa1420b05711fa0593ddcffbeb76f272ab)
(cherry picked from commit d34f0dec5327ab9c2fc6da3135c640aa5ba473b1)
(cherry picked from commit 03d97a42c3b3a0a4c695479c2b95340b2a2c1d32)
If the io.systemd.DynamicUser or io.systemd.Machine files exist,
but nothing is listening on them, the nss-systemd module returns
ECONNREFUSED and systemd-sysusers fails to creat the user/group.
This is problematic when ran by packaging scripts, as the package
assumes that after this has run, the user/group exist and can
be used. adduser does not fail in the same situation.
Change sysusers to print a loud warning but otherwise continue
when NSS returns an error.
(cherry picked from commit fc9938d6f8e7081df5420bf88bf98f683b1391c0)
(cherry picked from commit abba1e6bc29b7e07354ca23906c6f485ba245a1a)
(cherry picked from commit 0f518750a44dc4b2987ecc0cea4b3d848ac46ee9)
(cherry picked from commit dffa62c85fb644c649f68b2c8f02b1d8440d2a9d)
The XDG base dir spec adopted ~/.local/state/ as a thing a while back,
and we updated our docs in b4d6bc63e602048188896110a585aa7de1c70c9b, but
forgot to to update the table at the bottom to fully reflect the update.
Fix that.
(cherry picked from commit 72a6296b16a75d4e26eec972f2999e69c9967b9d)
(cherry picked from commit df1ed3fbe2d03e9c1d0eed7d836c5aa541f4fb52)
(cherry picked from commit 15352fa22315cd76582ae33a63d065c808b9e958)
(cherry picked from commit 083380e814ac5dc773a849315702d0707088aa8b)
We need to enable this otherwise systemd-oomd.service fails to start.
Fixes:
ConditionControlGroupController=memory was not met
(cherry picked from commit aa329b89223a79793cde8288b1bc6e93db174938)
(cherry picked from commit a50e6c5709f5fde269e6522bc6e6992180705fb1)
(cherry picked from commit 1817431dbeb762adec771169626808ecfcbd8f86)
(cherry picked from commit 25bd5f43f90c127d59bb484f20d17ccc9db66d9f)
We calculate the amount of uncompressed data we can write by taking the limits
into account and halving it to ensure there's room for switching to compression
on the fly when storing cores on a tmpfs (eg: due read-only rootfs).
But the logic is flawed, as taking into account the size of the tmpfs storage
was applied after the halving, so in practice when an uncompressed core file
was larger than the tmpfs, we fill it and then fail.
Rearrange the logic so that the halving is done after taking into account
the tmpfs size.
(cherry picked from commit e6b2508275aac2951aedfc842735d8ebc29850bb)
(cherry picked from commit a946258e9df627c675d13b2041ae186babf269dc)
(cherry picked from commit 3dacca114bde3a216605ab51d2f5203c4a6b9707)
(cherry picked from commit 523f91c0bb2b5f509fa2aa0c22c8ba0734498780)
(cherry picked from commit 17ef81a764995dfd0f43daf34dcf2ab04806e760)
(cherry picked from commit 0a97db87893e706011f0ed7e522a42fcd3767ac4)
(cherry picked from commit 3ced17fb98e225fd2e93937f82e043d41d39de93)
(cherry picked from commit 21184a6a827c13542245e4056872bbdc5120e586)
/etc/systemd/journald.conf.d drop-in dir already exists on SUSE.
(cherry picked from commit 56a894e888002f44f3463b3188f9d5abdcca4bb0)
(cherry picked from commit 10b7e0a0afc31dc6a3cc30fca3a276449a60ec7d)
(cherry picked from commit d0b9feab0158b57a3eff7becf9d35d07cb8cb20b)
(cherry picked from commit 58ff4df09596b725f7a654e427832e7d3829eec2)
Needed for resolving the "localhost" hostname.
(cherry picked from commit a09825ce9fb3bd315f35654b6e6ee4f92c675cde)
(cherry picked from commit 4f7d6885a12c0e5e27a9d29f9ef09fb2fa53d6ef)
(cherry picked from commit 58205cfea853a049f79e47ca336c320c881328d8)
(cherry picked from commit a5735d3653287ebea8e4dbdfa36b13b13ee06ec3)
cpu.pressure 'full' is undefined for system-wide checks since 5.13 but still reported with values set to 0 for backwards compatibility. Made changes to reflect this for system-wide checks so that the conditional comparison is not made against the 0 value and instead fall back to 'some'.
https://www.kernel.org/doc/html/latest/accounting/psi.html
(cherry picked from commit 98b1ecc9175a8bb241292f6f441a754b6759dd97)
(cherry picked from commit c2f74defaad3c2d0eb114d3f5aeded07890d9989)
(cherry picked from commit a28883e2d666ae17361c2f268041d9696e2dfe6b)
(cherry picked from commit f6b35b802ca236151296d3d155a6bb0e4200ad1f)
Currently, we only follow merged units for unit_load_dropin() call.
But if the unit is an alias, we should always perform operations
on the "canonical" unit.
(cherry picked from commit 740cd1e0f2ae5cc1a10d2111d63cc4e975761091)
(cherry picked from commit 86d47d63b01c1910f8f186668948f0dc7b80db37)
(cherry picked from commit 82871b071b960e31c59fb397a5a68b32fc4bf617)
(cherry picked from commit 81f515d64f464e9f62a62f31bf26cd8555eef9dd)
The DNS_PACKET_RCODE() function works out the full RCODE by taking the
first octet from the OPT record TTL field and bitwise-OR-ing this with
the basic RCODE from the packet header. This results in RCODE values
being lower than they should be.
For example, if the first TTL octet is 0x7a and the basic RCODE is 3,
this function currently returns `0x7a | 3` = 123, rather than 0x7a3 =
1955.
The first TTL octet is supposed to form the upper 8 bits of a 12-bit
value, whereas the current implementation constraints the value to 8
bits and results in mis-interpreted RCODEs.
This fixes things by shifting the TTL 20 places instead of 24 and
masking off the low nibble that comes from the upper bits of the version
octet.
Note that dns_packet_append_opt() correctly converts the input RCODE
into the high octet of the OPT TTL field; this problem only affects
parsing of incoming packets.
(cherry picked from commit c40f3714c9a4d1f2bcd308625c9c835892e3d41c)
(cherry picked from commit 7ee60a86140ebe3e60858ef3c4e749dcd2e7fd21)
(cherry picked from commit c572f1ed2b7565263007b26a10872fb047526d73)
(cherry picked from commit 7a9d6fd9b6564b0bf54b62cb05242964a9763f9e)
Whereas RFC 1035 says the TTL field takes the "positive values of a
signed 32 bit number", and RFC 2181 says "Implementations should treat
TTL values received with the most significant bit set as if the entire
value received was zero,", the dns_packet_read_rr() function sets
rr->ttl to zero if the MSB is set.
However, EDNS(0) as specified in RFC 6891 repurposes the TTL field's 4
octets to store other information, c.f.:
+0 (MSB) +1 (LSB)
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
0: | EXTENDED-RCODE | VERSION |
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
2: | DO| Z |
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
The first octet extends the usual 4-bit RCODE from the packet header by
providing an additional 8 bits of space, extending the RCODE to 12 bits.
But, our handling of the TTL field means that the high bit in the first
octet is not actually usable, since setting it will mean these 4 octets
are replaced with 0. This may have the effect of making us believe a
server does not support DNSSEC when it actually set the DO bit in its
OPT record.
Here we change things so that the TTL is only set to zero for record
types other than OPT.
(cherry picked from commit 131787979c700becaf6ec24a810658d1313587cc)
(cherry picked from commit 6ead24fcac878b3623408ecb1a05d07f29c4c04c)
(cherry picked from commit 964b184f8e4272b5f18c96e611268c522e67a715)
(cherry picked from commit ad876e65c4c9d8f7da552cfe899f0ff246b5b2a9)
When running the test on aarch64 the symlinks look as follows:
"""
[root@H ~]# ls /dev/disk/by-path
platform-4010000000.pcie-pci-0000:00:04.0-scsi-0:0:0:0 platform-4010000000.pcie-pci-0000:00:04.0-scsi-0:0:0:0-part1 platform-4010000000.pcie-pci-0000:00:05.0-nvme-16
platform-4010000000.pcie-pci-0000:00:04.0-scsi-0:0:0:0-part platform-4010000000.pcie-pci-0000:00:04.0-scsi-0:0:0:0-part2 platform-4010000000.pcie-pci-0000:00:05.0-nvme-17
"""
So let's make the PCI patterns a little more generic so they match
both the x86 and the aarch64 paths.
(cherry picked from commit 72d121b60174b825bf1390958eb1b55f34c5ff5b)
(cherry picked from commit dc0167b674bc6b555c25f374719c818bc6ad1416)
(cherry picked from commit d34128a1f1a2fe0148e95fbe76157895a7b951af)
(cherry picked from commit 466a9d3e700a1cecacd54ff60732c931396e666d)
We would say how *sources* are licensed, but actually most user care about the
resulting binaries. So say how the *binaries* are licensed. I used the word
"effectively" because the permissive licenses don't set any requirements on the
binaries, so the license of sources is a complex mix, but the resulting
binaries have a simple effective license.
Also, make it clear that the GPLv2 license applies to udev programs, but not
the shared library. Based on private correspondence, there's some confusion
about this.
(cherry picked from commit bd7236912f373e0a06a1b0395000ec67d96767af)
(cherry picked from commit fb747bd8cdcbeb55f9ef3c62289fff8ff5a25b68)
(cherry picked from commit e22e239cd9d60fd41d197ea39d41c1413d5c9cc6)
(cherry picked from commit 6aa191405e874aace5b7ed54055edaae6e11fc7a)
I expect the test output to be the second argument, so we're diffing "expected"
and "output", not the other way around.
I noticed this when working on https://github.com/systemd/systemd/pull/33081.
(cherry picked from commit 6bb3ea655d08c0602c99ccd2a580ba102fd19114)
(cherry picked from commit 9663bb74100dd79c1e4e9c6b2377ea1b817ddee5)
(cherry picked from commit 5469bc61185163119bec209612e0a72381ba232c)
(cherry picked from commit b8b652d11f2c49be5a841fe61c28e038ea1ea04a)
They very much can be with the new mount API.
(cherry picked from commit 36e48f22af102843b6cceeda5a2292e57434d2ee)
(cherry picked from commit 99cb4bdbbb15f3812de7f0fd161f91335000790d)
(cherry picked from commit 98a4c8009b655b74ccdbe3664ca9191d40cf3343)
(cherry picked from commit a7828d53dd2bbf7e03683429754ac173e6f5966d)
The kernel's sched_setattr interface allows for more control over a processes
scheduling attributes as the previously used sched_setscheduler interface.
Using sched_setattr is also the prerequisite for support of utilization
clamping (UCLAMP [1], see #26705) and allows to set sched_runtime. The latter,
sched_runtime, will probably become a relevant scheduling parameter of the
EEVDF scheduler [2, 3], and therefore will not only apply to processes
scheduled via SCHED_DEADLINE, but also for processes scheduled via
SCHED_OTHER/SCHED_BATCH (i.e., most processes).
1: https://docs.kernel.org/next/scheduler/sched-util-clamp.html
2: https://lwn.net/Articles/969062/
3: https://lwn.net/ml/linux-kernel/20240405110010.934104715@infradead.org/
(cherry picked from commit 016e9d8d08ce66f5e81b42e0a0db398afc17336a)
(cherry picked from commit fb7ec285c98d9eeaa69d1efda3e450e6f7207e57)
(cherry picked from commit 02e50f7a4b53e56b051889b982fa43118c577493)
(cherry picked from commit fc96019babd5658b140ea2f45bfda5fd101434c7)
Just a tiny change to fix an eyesore in cryptsetup luksDump display :)
(cherry picked from commit 0828c6a2bf9aa40a6cf5fcb3d5650130c483ac8a)
(cherry picked from commit 5911f1ec2568805fc820aa96560988f13a11e45e)
(cherry picked from commit eaf934f01f3e1d1aa9794d1f464340ffd15710a5)
(cherry picked from commit 0c3f3684c1874a0a8a0b80f20fdd781660856469)
File offsets in UEFI are 64bit on all archs, hence let's use that typo
too, and not create artificial confusion around types.
(cherry picked from commit 9573ab8f5a1e2dfdb3542aa647868ff73ced7dd2)
(cherry picked from commit 57661f4ea9b3f13b7395ad594f20c0bae14b6e27)
(cherry picked from commit 155475b474072e52294784d30a962dfecd0f5d14)
(cherry picked from commit 2d73752c404d549829200a585376fe9048131653)
description_good and description_bad are mixed up. Disabling CAP_BPF results in the inability to load BPF, not the other way around.
(cherry picked from commit 1750e30d237e6d9cdebc6b546d0a26342828dbd1)
(cherry picked from commit 8e775590f1b25d399fdffa0279a2e244d7afff23)
(cherry picked from commit f685b22f073b8d56c5c5fcbb87037e8322386e29)
(cherry picked from commit d18ad2b053d3e540983be40c45e46798bb0a993e)
(cherry picked from commit b9c5d812d5132ea1d6a7146be80d41ae2ccb288e)
(cherry picked from commit 0b909bf685c661027d1fdc59abcab77c06d62406)
(cherry picked from commit 8966f222cd56cb4dbc323b665513334cedf397da)
(cherry picked from commit 870457a7e552a60ce6e71a4357494ca04686ea50)
(cherry picked from commit 163bb43ceaa1e5bdcda27c4417339b3af9cf28af)
(cherry picked from commit 3e435e970d157271b2378400cbc9c84610d38f06)
(cherry picked from commit b3bc7b8a586171f58ca8a0ba100ebc43ae23079b)
(cherry picked from commit 6e37495d22bd136939e540dd6a8e595f48ad7a2c)
(cherry picked from commit 051d462b42fe6c27824046c15cd3c84fa5afe05b)
(cherry picked from commit 90b5cb35e9901947fca63d82e69b74b2df959258)
(cherry picked from commit 130358d6def563aeb8897a7d9eb8f860f162f7a3)
(cherry picked from commit b54581e10d771b967806d512b4a3d4da164aaff1)
While tracing a LUKS code path in homework, I've noticed that we don't
erase buffers when doing unbase64 or unhex on JSON variants, even if the
variant is marked as sensitive.
(cherry picked from commit 80313c55770ef0e2174fe5750680e426278416cb)
(cherry picked from commit cce7df4079c2ac48c6a6be85785332c6764522b9)
(cherry picked from commit 2dee0040d0c555fbca4312da8ad2378a18757322)
If the ceck for the ACPI TPM2 table did not work we currently check if
the EFI TPM table exists to check if the firmware supports TPM2.
Specifically we check if
/sys/kernel/security/tpm0/binary_bios_measurements exists. But that's
not enough, since that also exists on TPM1.2 systems. Hence, let's also
check /sys/class/tpm/tpm0/tpm_version_major which should exist under
similar conditions and tells us the kernel's idea of the TPM version in
use.
I originally intended to read the signature of the
/sys/kernel/security/tpm0/binary_bios_measurements contents for this,
but this is not ideal since that file has tight access mode, and our TPM
availability check would thus not work anymore if invoked unpriv.
Follow-up for 4b3391158197e9158cc754e56bbeaf94e2fd8395
Fixes: #33077
(cherry picked from commit aeaac9a2899a11194d6f808ba70cd48d1253b7a3)
(cherry picked from commit b2046c36d5324e90ff7ef0e41c9f71b10df12176)
(cherry picked from commit a55bb49c09a2171385bda7cb3a2a2e80f7b4b087)
See https://github.com/torvalds/linux/blob/v6.10-rc1/include/uapi/linux/loop.h
Fixes a bug in b3fe33ff52ece458a5b990a4a68d59aef7cae10b.
(cherry picked from commit eb6d3a5917f5c92c2d4706217aa5a77a7d6dccb7)
(cherry picked from commit b097677ec0bdae17ae3f5eec62313934daf73385)
(cherry picked from commit f224a9d5819c297850c7e46735a770cdd0be09b6)
(cherry picked from commit a81f5ffd40081441dafc678fe83d185436dde35a)
(cherry picked from commit f8f669fd69bf15f386308ef8f4cbbbd5a7ad69cd)
(cherry picked from commit 759ddfd51882b9dbc9d19d61259f683a76574657)
(cherry picked from commit c353e02b292a4f03722ecf1fe5c16054077b2952)
If a symlink is leftover, still allow cleaning it up via 'disable'. This
happens when a unit is stopped and removed, but not disabled, and a reload
has already happened. At that point, cleaning up the old symlinks becomes
impossible through the APIs, and needs to be done manually. Always allow
cleaning up symlinks, if they exist, by only erroring out if there is an
OOM.
Follow-up for f31f10a6207efc9ae9e0b1f73975b5b610914017
(cherry picked from commit 5163c9b1e56293b1bb2803420613c5b374570892)
(cherry picked from commit c26e56d08f30a2946dfa1d03781c63bfa9f56c1d)
(cherry picked from commit 44c08e66f8e99c57e49f90ebf0ce4f153cee1627)
(cherry picked from commit 8c9fcb57ae7b75475e3d99c0f409f0adc3f97806)
Follow-up for 45b1017488cef2a5bacdf82028ce900a311c9a1c
(cherry picked from commit 9f5d8c3da4f505346bd1edfae907a2abcdbdc578)
(cherry picked from commit f7d55cc801611781fbff2817f2fd4a16ec96ca85)
(cherry picked from commit 8ead2545bf86bd0fe00b344506e071390ffaa99f)
(cherry picked from commit 8f280216e052c9b9937ba77fad6659fb727535d9)
Historically, systemd-tmpfiles was designed to manager temporary
files, but nowadays it has become a generic tool for managing
all kinds of files. To avoid user confusion, let's remove "temporary"
from the tool's description.
As discussed in #33349
(cherry picked from commit b5c8cc0a3b8e4e2fea0539d6420a76b524ea5735)
(cherry picked from commit 1a0e6961cfaed42bda542e111738c136f7b4d73f)
(cherry picked from commit c752efdfbac84cd62ddc54fc6ff7c58361f7f998)
(cherry picked from commit 269fb21700909aa43e3afdde31410304a8192bbb)
This check introduced in 91adc4db33f6 is intended to spare us from
encountering broken resolver behavior we don't want to deal with.
However if we aren't validating we more than likely don't know the state
of the upstream resolver's support for dnssec. Let's let clients try
these queries if they want.
This brings the behavior of sd-resolved in-line with previouly stated
change in the meaning of DNSSEC=no, which now means "don't validate"
rather than "don't validate, because the upstream resolver is declared to
be dnssec-unaware".
Fixes: 9c47b334445a ("resolved: enable DNS proxy mode if client wants DNSSEC")
(cherry picked from commit 364c948707afa097f6ad177b61c2b51a86c0089a)
(cherry picked from commit ba031f1fe86e36d7adc0340b047de32399c98bf7)
(cherry picked from commit 5299397e49536dae7903bc4f5bf11d375146261d)
(cherry picked from commit a3a035e238ce1c5764b1ba036b6957581cd3c653)
This allows us to reserve a bunch of capacity ahead of time,
improving the performance of hwdb significantly thanks to not
having to reallocate so many times.
Before:
```
$ sudo time valgrind --leak-check=full ./systemd-hwdb update
==113297== Memcheck, a memory error detector
==113297== Copyright (C) 2002-2024, and GNU GPL'd, by Julian Seward et al.
==113297== Using Valgrind-3.23.0 and LibVEX; rerun with -h for copyright info
==113297== Command: ./systemd-hwdb update
==113297==
==113297==
==113297== HEAP SUMMARY:
==113297== in use at exit: 0 bytes in 0 blocks
==113297== total heap usage: 1,412,640 allocs, 1,412,640 frees, 117,920,009,195 bytes allocated
==113297==
==113297== All heap blocks were freed -- no leaks are possible
==113297==
==113297== For lists of detected and suppressed errors, rerun with: -s
==113297== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)
132.44user 21.15system 2:35.61elapsed 98%CPU (0avgtext+0avgdata 228560maxresident)k
0inputs+25296outputs (0major+6886930minor)pagefaults 0swaps
```
After:
```
$ sudo time valgrind --leak-check=full ./systemd-hwdb update
==112572== Memcheck, a memory error detector
==112572== Copyright (C) 2002-2024, and GNU GPL'd, by Julian Seward et al.
==112572== Using Valgrind-3.23.0 and LibVEX; rerun with -h for copyright info
==112572== Command: ./systemd-hwdb update
==112572==
==112572==
==112572== HEAP SUMMARY:
==112572== in use at exit: 0 bytes in 0 blocks
==112572== total heap usage: 1,320,113 allocs, 1,320,113 frees, 70,614,501 bytes allocated
==112572==
==112572== All heap blocks were freed -- no leaks are possible
==112572==
==112572== For lists of detected and suppressed errors, rerun with: -s
==112572== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)
21.94user 0.19system 0:22.23elapsed 99%CPU (0avgtext+0avgdata 229876maxresident)k
0inputs+25264outputs (0major+57275minor)pagefaults 0swaps
```
Co-authored-by: Yu Watanabe <watanabe.yu+github@gmail.com>
(cherry picked from commit 621b10fe2c3203c537996e84c7c89b0ff994ad93)
(cherry picked from commit 514ef0f93b76cbe0ba6b4de07a7b21fd0c2b7bae)
(cherry picked from commit aa0dd89d3faebce3b051f1c63bb234ea8777dd60)
(cherry picked from commit 43ee651ec50ec5ed3ab594c9e7cf89f7385a5bc0)
As per the suggestion in https://github.com/systemd/systemd/issues/33242.
This reduces the number of /dev/ttySXX device units generated in
mkosi from 32 to 4.
(cherry picked from commit dc38f9addd04c34d1fd743efc407bdebb3573d05)
(cherry picked from commit a3d94332a2b5128697373d3093c1cfa56649ec61)
(cherry picked from commit 639124214e0f5fb767716d0b2b7ee7a0c75a5c4a)
(cherry picked from commit 1a8549f4cd788b7e783f265049e9e84c4b4b988d)
I do not think this is necessary, but all other places in
libsystemd-network we clear buffer before receive. Without this,
Coverity warns about use-of-uninitialized-values.
Let's silence Coverity.
Closes CID#1469721.
(cherry picked from commit 40f9fa0af4c3094d93e833e62f7e301cd453da62)
(cherry picked from commit 0d573787ea1610ba57a359cf437841f62b186e77)
(cherry picked from commit aa93c07b3a5701f13163b190ee4e6ffd4de32eb5)
(cherry picked from commit 74e844ac1ff90772006dbf9b3f9fd1048cf3a9ae)
Denials from AppArmor are raised as EACCES, so EPERM is not enough. Do
the same check as PrivateNetwork above.
Fixes https://github.com/systemd/systemd/issues/31037
Related to 06384eb3c5044f632f50304a0210a402460f1189
(cherry picked from commit cafe40ec8201db31c6d3519474ef40a72541d511)
(cherry picked from commit e4817103d0f32a3492608f14da6628d5c9b83197)
(cherry picked from commit da9a6a54369f9f4e700cbc5babca54d91d2ba24e)
Follow-up for 677430b3c7fcd1b352eb66f19b8746741459b91a
(cherry picked from commit d8f5a310227e7c74548b7f6ca9aafd39af6a621f)
(cherry picked from commit 632b4934a0a0d0c048d94a3baab4668b58577a03)
(cherry picked from commit 10e36dbd66eb96e8b1bc8e71b48c8b2a8c7635c5)
With b9684a71fc (v5.19),
we cannot check partition scanning is enabled for a loopback block device
without checking the attribute.
(cherry picked from commit bab8c851daaa2a4ed9febb7cc958f701ee024151)
(cherry picked from commit ae7a07b9ff9066f549ea5ae95be5201d581ea0e8)
(cherry picked from commit e2fe7d88c2de31fa9d5f864448f55dab37a17ed2)
With 430cc5d3ab,
the value of GENHD_FL_NO_PART, previously named as GENHD_FL_NO_PART_SCAN,
is changed from 0x0200 to 0x0004. So, we need to check both flags.
(cherry picked from commit f0c2668c9934682a3b4ed5c228c05e26bb0ba1dc)
(cherry picked from commit 49b0f0ed08ec50d0ca9d19de657493800b72420b)
(cherry picked from commit 7f19a3449b09069e1b89e7ae9ee960ef2255d7a6)
See also: https://lore.kernel.org/r/20240502130033.1958492-3-hch@lst.de
(cherry picked from commit 100bed702b73414161d57adff71e07329c1016ac)
(cherry picked from commit 41fb19e778913273d904f3b75b545bb77da9d1f7)
(cherry picked from commit 6426323afa0d1cd56236c577b70383a3ab498604)
So, we need to try to read timezone several times.
Also, on failure, show journal of timedated instead of hostnamed,
as the timezone is handled by timedated.
Hopefully fixes#33007.
(cherry picked from commit 1ef586af237e685c32676e381a5ce8d4918f9225)
(cherry picked from commit 91d31ca3bcf929346ec872d387cd33030d4e1570)
(cherry picked from commit 8b86adabd4fe1deb8bf2cb6c51a683eb6581a2af)
Before:
/etc/kernel/install.conf:6: Unknown key name 'asdf' in section '(null)', ignoring.
After:
/etc/kernel/install.conf:6: Unknown key 'asdf', ignoring.
Also make the message a bit better.
(cherry picked from commit 600a7405a9a7cdf2d6a7e669df4fa6025924ba82)
(cherry picked from commit a2f32b99f354c3fc2d4e9b49c26f64357f5a0887)
(cherry picked from commit 1d83c17dd1779c6b867e33a244aea056e95e5f9b)
When running in LXC with AppArmor we'll most likely get an error when creating
a network namespace due to a kernel regression in < v6.2 affecting AppArmor,
resulting in denials. Like other tests, avoid failing in case of permission
issues and handle it gracefully.
(cherry picked from commit 6ab21f20bd982bc1a9ece47dcffa1137a76cc48a)
(cherry picked from commit ff354605fc440100c2f6aac16a6cce79cf59eef8)
(cherry picked from commit c3aa100a5466ca5c6a27a8e67d01774e88eec11e)
On running cryptsetup, udevd detects two inotify events for the
underlying device. Running the test on enough fast host, the expected
symlinks based on UUID and disk label are created by the second event.
During processing a uevent for a device, udevd disables the inotify
watch for the device. If the test runs on slow system, the second
inotify event may comes during a udev worker processing the synthesized
uevent triggered by the first inotify event. Hence, no synthesized
uevent for the second inotify event will be generated, and the expected
symlinks will be never created.
To prevent the issue, we need to lock the device during cryptsetup
command is running.
Fixes#32913.
(cherry picked from commit be43c9b0295120e508de1afd739af6fb7603186a)
(cherry picked from commit 640dbad3e75b0c67ed1f6c1afd02ceb313a0d8c8)
(cherry picked from commit b88915b23d9f072703557a283f88803c0898f717)
Fixes https://github.com/systemd/systemd/issues/32680#issuecomment-2120974685.
===
May 21 02:45:08 TEST-74-AUX-UTILS.sh[2475]: + mountpoint /tmp/tmp.eaRV7lSbX2/mnt
May 21 02:45:08 TEST-74-AUX-UTILS.sh[2476]: /tmp/tmp.eaRV7lSbX2/mnt is not a mountpoint
May 21 02:45:08 TEST-74-AUX-UTILS.sh[2449]: + systemd-mount /dev/loop0 /tmp/tmp.eaRV7lSbX2/mnt
May 21 02:45:08 systemd-mount[2477]: Failed to start transient mount unit: Unit tmp-tmp.eaRV7lSbX2-mnt.mount was already loaded or has a fragment file.
===
(cherry picked from commit 4a8ca3c6d595598f64cf532fad2c98ef7481f6a4)
(cherry picked from commit 1a6a2d8f2476f2468ac96bd973bbc890eaa9f996)
(cherry picked from commit 861affe4cf36bd93561aa5fa48bce1c19ae29bf0)
(cherry picked from commit d73a47d259be795958c8aa5b65b002f3d7338b6e)
(cherry picked from commit ce25cf6df1c6f86eabb4f35fae13a3c932096eb9)
(cherry picked from commit d1e36e6a35576dc6b328ecac4e12177bf2851ae7)
Follow-up for ade0789fabbf01b95bf54d32f8cab1217a753f03
The change in behavior was partly intentional, as I think
if both --wait and --pty are used, manually disconnecting
from PTY forwarder should not result in systemd-run exiting
with "Finished with ..." log. But we should check for
--wait here.
Closes#32953
(cherry picked from commit 2b4a691c32aadbc45491c8b243ec3cf7ed910f55)
(cherry picked from commit 46561305cba2fcb64726616e88c7b33b2f23c988)
(cherry picked from commit 4e89a4180e51f0c36c6938df858a424f6362cb3b)
(cherry picked from commit d735753256c1e0f3e9a4efaab17ba9ee47650403)
(cherry picked from commit 867b5a72582ae91e63f3181d707977de583559af)
(cherry picked from commit 7f1f029b13e2fb113b10666cde2754e295626c8d)
