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!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
This effectively reverts ac1a919f ("boot: Add
ostree-finalize-staged.path").
A bug came in on the OCP side that demonstrates that the way things are
setup right now is racy. If a reboot is triggered quickly after staging
a deployment, the whole pipeline of:
- ostree-finalize-staged.path, which triggers
- ostree-finalize-staged.service, which triggers
- ostree-finalize-staged-hold.service,
may not fully have happened before systemd isolates to `reboot.target`
which will want to kill all pending jobs.
Just directly starting the systemd unit is less elegant but much more
explicit and gets rid of any possible race because it's directly part of
the staging operation.
Fixes: https://issues.redhat.com/browse/OCPBUGS-51150
Previously we were erroring out if xattrs were provided in
non-canonical (e.g. unsorted) form all the way down to just
the bare-user path. But for archive repos and dirmeta we
canonicalized.
Canonicalize bare-user xattrs on both read and write consistently
instead of erroring.
Signed-off-by: Colin Walters <walters@verbum.org>
I hit this in the rpm-ostree rechunker flow somehow
and with this change I now get:
`error: Generating commit from rootfs: Processing dir var: Writing content object: Incorrectly sorted xattr name (prev=user.Librepo.checksum.mtime, cur=security.selinux), index=2`
which is more useful, although I still need to figure out
and fix why that's happening (again?).
Signed-off-by: Colin Walters <walters@verbum.org>
This makes it possible to use pkg-config to link against libostree as
a static library. Unlike shared libraries, static libraries don't
encode their dependencies in the library file, so we have to
communicate them via pkg-config.
Let's quiet the output of libselinux by default, all we
get is the pointless "regex version mismatch" warnings.
This is what e.g. systemd does.
This is exposed via the library; our binary opts in,
then we expect higher level tools like e.g. bootc to
do this too.
Signed-off-by: Colin Walters <walters@verbum.org>
sys/prctl.h already provides prctl.h and adding both imports fails on
musl libc:
/usr/include/sys/prctl.h:88:8: error: redefinition of 'struct prctl_mm_map'
88 | struct prctl_mm_map {
| ^~~~~~~~~~~~
In file included from src/libotutil/ot-unix-utils.c:33:
/usr/include/linux/prctl.h:134:8: note: originally defined here
134 | struct prctl_mm_map {
| ^~~~~~~~~~~~
Fix issues in Dockerfile:
1. Update Fedora image to the latest version 41, otherwise docker build
fails with an error:
Step 1/7 : FROM registry.fedoraproject.org/fedora:28
manifest for registry.fedoraproject.org/fedora:28 not found: manifest unknown: manifest unknown
2. Force install python3-yaml package, as it's required for running some
tests. For example, tests/test-remote-headers.sh will fail without
it:
V=$($CMD_PREFIX ostree --version | \
python3 -c 'import sys, yaml; print(yaml.safe_load(sys.stdin)["libostree"]["Version"])')
Traceback (most recent call last):
File "<string>", line 1, in <module>
import sys, yaml; print(yaml.safe_load(sys.stdin)["libostree"]["Version"])
^^^^^^^^^^^^^^^^
ModuleNotFoundError: No module named 'yaml'
With these fixes `make check` executes successfully in a container:
============================================================================
Testsuite summary for libostree 2024.11
============================================================================
TOTAL: 935
PASS: 888
SKIP: 47
XFAIL: 0
FAIL: 0
XPASS: 0
ERROR: 0
Signed-off-by: Igor Opaniuk <igor.opaniuk@foundries.io>
Followup to 9a0acd7249
Basically our composefs enablement flag has long had a tension between
trying to do two things:
- Enable generating the composefs blob (at deployment time)
- Enable at runtime in prepare-root
And we've hit issues in "ratcheting" enabling composefs
across upgrades because of this.
This change builds on the previous one, and now it's really
simple to talk about:
- If composefs is enabled at build time, we *always*
generate a composefs blob at deplyment time
- Configuring the prepare-root config now mostly
only affects the runtime state.
There is one detail though: in order to handle the
verity requirement at deploy time, we do still parse
the config then.
But for the basic "is composefs enabled at all at runtime"
that is now fully keyed off the config, not the build time
or (worse) whether the deployment happened to have a composefs
blob.
For users who want composefs on, they need to do so in the base
image configuration.
Signed-off-by: Colin Walters <walters@verbum.org>
We have drift again here because we're using an old clang-format
in CI, and some things have landed that it didn't catch.
And update clang-format to ubuntu-24.04 so we are running
against something more modern.
Signed-off-by: Colin Walters <walters@verbum.org>
Adds a new `--kexec` flag to `ostree admin upgrade` which will cause
the deployment to be loaded into kexec after the upgrade completes.
It is particularly useful in conjunction with the `--reboot` flag to
perform a reboot into the new deployment without waiting for the
(often slow) firmware initialization to take place. (And in my case,
allows me to avoid a normal reboot, which can be unreliable on my
hardware).
After an image has been loaded (using the `kexec_file_load` syscall),
the `systemctl-reboot` command (which is called when the existing
`-r` flag is included) will trigger a kexec on the loaded image
rather than a normal reboot. From `systemctl(1)`:
If a new kernel has been loaded via kexec --load, a kexec will be
performed instead of a reboot, unless "SYSTEMCTL_SKIP_AUTO_KEXEC=1"
has been set. If a new root file system has been set up on
"/run/nextroot/", a soft-reboot will be performed instead of a
reboot, unless "SYSTEMCTL_SKIP_AUTO_SOFT_REBOOT=1" has been set.
A good in-depth technical explanation of kexec can be found here:
https://web.archive.org/web/20090505132901/http://www.ibm.com/developerworks/linux/library/l-kexec.html
My implementation uses the `kexec_file_load` syscall rather than the
older `kexec_load` syscall, which allows the kernel to verify the
signatures of the new kernel. It is supported on Linux 3.17 and
newer. I assume this probably won't be an issue, but if it is, it's
not that hard to put a preprocessor directive around the kexec stuff
to disable it for older kernels. Even RHEL is new enough now to
not be an issue :)
Closes: #435
It's all quite confusing having to reason about both the pre-composefs
ostree and the composefs version. But hopefully soon we more firmly
leave behind that first legacy.
Signed-off-by: Colin Walters <walters@verbum.org>
