```
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.
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.
Prior to this commit, the behaviour looked like this:
| Keypress | Result |
| -------- | ------------ |
| Up | KEY_PAGEUP |
| Down | KEY_PAGEDOWN |
| Left | KEY_LEFT |
| Right | KEY_RIGHT |
| Fn+Up | KEY_UP |
| Fn+Down | KEY_DOWN |
| Fn+Left | KEY_HOME |
| Fn+Right | KEY_END |
This commit would fix it so that PGUP/PGDN would also require the Fn
key so that the arrow keys behave identically depending on whether Fn
was pressed.
Presumably after a BIOS update, HP seems to have fixed the order. This
now means this commit is now behaving exactly as the table above.
Revert the commit to restore the intended behaviour:
| Keypress | Result |
| -------- | ------------ |
| Up | KEY_UP |
| Down | KEY_DOWN |
| Left | KEY_LEFT |
| Right | KEY_RIGHT |
| Fn+Up | KEY_PAGEUP |
| Fn+Down | KEY_PAGEDOWN |
| Fn+Left | KEY_HOME |
| Fn+Right | KEY_END |
This reverts commit 4fd7c712dc.
Signed-off-by: Han Sol Jin <hansol@hansol.ca>
Currently, if we're copying a file, we won't copy the owner UID/GID
from the source. If we're copying a directory, we will copy the owner
UID/GID from the source. Let's give users a bit more control over this
behavior by introducing --copy-ownership= which will default to the
current behavior but allows users to explicitly enable/disable copying
of ownership.
Let's check for CAP_SYS_ADMIN instead of root for these, and make
unmounting more graceful if we can't access the backing loop device
because of permission issues. This allows mounting and unmounting images
from an unprvileged mount namespace. The actual files in the image will
end up owned by nobody:nobody because we'll be in an unprivileged user
namespace, but assuming the directory permissions are not too strict, this
still allows interacting with the image in useful ways.
These actions interact with the host. The former needs privileges to
write into the image, the latter needs privileges to write on the host.
Neither will have the privileges required if the image is attached under
a private userns, hence, don't use one.
Luca Boccassi
Yu Watanabe
Michael Vogt
Daan De Meyer
Zbigniew Jędrzejewski-Szmek
Mike Yuan
Carlos Peón Costa
Daan De Meyer
Zbigniew Jędrzejewski-Szmek
Yaping Li
Luca Boccassi
Baurzhan Muftakhidinov
Han Sol Jin
David Santamaría Rogado
Tabis Kabis
Lennart Poettering
Betacentury