UEFI Block I/O Protocol has `Media->IoAlign` field dictating the minimum
alignment for I/O buffer. It's quite surprising this has been lingering
here unnoticed for years, seems like most UEFI implementations have
small or no alignment requirements. U-Boot is not the case here, and
requires at least 512 byte alignment, hence attempt to read GPT
partition table fail and in effect systemd-boot can not find XBOOTLDR
partition.
These patches allow to boot from XBOOTLDR partition on U-Boot - tested
with latest systemd revision and U-Boot master
(`8de6e8f8a076d2c9b6d38d8563db135c167077ec`) on x64 and ARM32, of which
both are failing without the patch.
Also fixes Bitlocker probing logic, which is the only other place where
raw block I/O is used, however this is untested.
While looking at oomd behaviour in production I noticed that I always
get garbage cgroup paths for the Killed event. Looking more closely, I
noticed that while the signature is (string cgroup, string reason), we
currently erroneously pass the `OomdCGroupContext*` pointer itself as
the first argument to sd_bus_emit_signal(), rather than the ctx->path
string it contains.
The in-memory layout on affected machines in my case is:
struct OomdCGroupContext {
unsigned n_ref;
/* padding */
char *path;
/* ... */
}
...which explains the control characters, since they're garbage from
parsing n_ref, the path pointer, and later fields. At runtime, sd-bus
treats ctx as `const char *` and reads struct bytes as string data,
resulting in garbage being sent.
Pass ctx->path correctly so listeners receive the valid cgroup path.
string_has_ansi_sequence() currently does this to look for ESC input:
t = memchr(s, 0x1B, ...)
So each iteration re-searches from the original start pointer. But if we
find an ESC byte that does *not* start a valid ANSI sequence (like "\x1B
", or an ESC at the end of the string), then ansi_sequence_length()
returns 0, and if that ESC is still in the search window, we will just
spin consuming 100% CPU forever.
Fix this by always advancing past rejected ESC bytes.
Using --first-parent --no-merges seems to exclude not just the merge
commits but all the commits from the merge as well. Let's use only
--no-merges to get just the commits without merges.
Building these over and over again is extremely wasteful. Let's just
build them once and not touch them again unless -ff is specified or
their cache is out-of-date, which is exactly what Incremental=relaxed
does.
This means mkosi.extra/ and such changes won't be picked up for these
anymore unless -ff is used, but that slight annoyance is totally
outweighed by the time saved building the images.
A more straightforward way to extend the default initrd rather than
using a subimage. This mainly allows us to take advantage of mkosi
automatically figuring out whether the initrd needs to be built or not,
speeding up builds when building directory images as the initrd can be
skipped in that case.
* d6ddc66acb Use python3.12 as interpreter in CentOS Stream 9 zipapp
* 89d876c86f tests: fix running pytest on undetected distro
* 61a47eeb1c centos: Fix EPEL repositories for RHEL 10
* e5aa19e2bc oci: allow user defined labels and annotations
* 1680fc5789 man: be more precise that the tools tree distribution is decided by the host distribution
* 7025b8e67d Support resizing output image
```
TEST-02-UNITTESTS.sh[4382]: [ 707.393188] test-cgroup-util[426]: Failed to open pidfd for pid 414: Invalid argument
TEST-02-UNITTESTS.sh[4382]: [ 707.393193] test-cgroup-util[426]: src/test/test-cgroup-util.c:249: Assertion failed: Expected "r = proc_dir_read_pidref(d, &pid)" to succeed, but got error: -22/EINVAL
```
The kernel can return EINVAL on pidfd_open() when the selected PID is
not a thread group leader. Don't fail the test, as we are iterating on
everything, so this can seldomly happen.
For some reason the VS Code parser thinks sd_json_variant is still 48 bytes,
so skip the assert when running in that parser too
Follow-up for 337712e777
The assert at the bottom was updated when the size changed, but
the comment wasn't:
assert_cc(sizeof(sd_json_variant) == 40U);
Follow-up for 337712e777
When sd_varlink_connect_url() gets an unknown URL we now
check if there is a `$LIBEXECDIR/varlink-bridges/$scheme`
binary and execute it (with the url as the first arguments).
This makes varlink more flexible as it provides a way to
dynamically add "bridges" in LIBEXECDIR/varlink-bridges/. This is
conceptually similar to the libvarlink `varlink --bridge` command
and allows to e.g. call varlink over http{,s} via e.g. the new
varlink-http-bridge.
With a running varlink-http-bridge [0] one can do:
```console
$ varlinkctl call http://localhost:8080/ws/sockets/io.systemd.Hostname \
io.systemd.Hostname.Describe {}
{
"Hostname" : "top",
...
```
Closes: https://github.com/systemd/systemd/issues/40640
[0] https://github.com/mvo5/varlink-http-bridge/pull/1
The two options are were not documented or ever used in the codebase.
Additionally, the parser expected an argumentless option, while the option
table declared a required argument. So I think this was added for debugging
and never excercised properly. Since there was no public documentation for
those, it's as if they never existed, so it should be fine to drop them.
The default image policy for the verity sig partition expects
the r/o flag to be set, but repart so far did not add it by
default if unset, like it does for the verity partition
It seems the device with modalias e.g. virtio:d00000013v, only appears
after the relevant module is loaded. So, we cannot use the string to
determine if we should load the module.
Fixes#40503.
We don't want to vacuum anything if we're just going to fail just
afterwards because a GPT partition label exceeds the maximum size
so let's compute the temporary paths for all transfers before we do
any vacuuming or acquiring.