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
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.