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!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
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>
The android bootloader is also split into two partitions, previously
that wasn't represented in the diagram.
Signed-off-by: Eric Curtin <ecurtin@redhat.com>
Remove the unofficial acronym RHIVOS from both the README and docs
files. The acronym is associated with Red Hat In-Vehicle Operating
System but isn't officially recognized.
Co-Authored-By: Felicia Kleinfelt <fkleinfe@redhat.com>
Signed-off-by: Eric Curtin <ecurtin@redhat.com>
This mimics the GitHub Pages environment so that you can build and serve
the site locally for testing. It requires webrick these days.
Signed-off-by: Eric Curtin <ecurtin@redhat.com>
We've long struggled with semantics for `/var`. Our stance of
"/var should start out empty and be managed by the OS" is a strict
one, that pushes things closer to the original systemd upstream
ideal of the "OS state is in /usr".
However...well, a few things. First, we had some legacy bits
here which were always populating the deployment `/var`. I don't
think we need that if systemd is in use, so detect if the tree
has `usr/lib/tmpfiles.d`, and don't create that stuff at
`ostree admin stateroot-init` time if so.
Building on that then, we have the stateroot `var` starting out
actually empty.
When we do a deployment, if the stateroot `var` is empty,
make a copy (reflink if possible of course) of the commit's `/var`
into it.
This matches the semantics that Docker created with volumes,
and this is sufficiently simple and easy to explain that I think
it's closer to the right thing to do.
Crucially...it's just really handy to have some pre-existing
directories in `/var` in container images, because Docker (and podman/kube/etc)
don't run systemd and hence don't run `tmpfiles.d` on startup.
I really hit on the fact that we need `/var/tmp` in our container
images by default for example.
So there's still some overlap here with e.g. `/usr/lib/tmpfiles.d/var.conf`
as shipped by systemd, but that's fine - they don't actually conflict
per se.
Android Bootloader is a standard of how Android devices should implement
their bootloaders, we also use it in CentOS Automotive Stream
Distribution for some ARM boards. Here is some documentation on how
ostree works with this.
Signed-off-by: Eric Curtin <ecurtin@redhat.com>
This drops the `ot-composefs` kernel commandline in favour
of a `[composefs]` section in the `prepare-rootfs.conf` file.
You can set `composefs.enabled` to `signed`, `yes`, `no` or `maybe`,
with `maybe` being the default.
You can also set `composefs.keypath` (or rely on the default
`/etc/ostree/initramfs-root-binding.key`) to point to ed25519 public
keys, one of which which the commit must be signed with, or boot
fails.
The ostree dracut module adds `/etc/ostree/initramfs-root-binding.key`
to the initrd if it exists.
NOTE: This drop the option to define a digest in the commandline.
However, that was currently unused
(i.e. ComposefsConfig.expected_digest was never read).
Additionally it very hard to actually store the composefs digest in
the initrd, as the initrd is typically part of the commit and thus the
composefs. It may be possible to handle this, but lets add it back
when we know exactly how that will work.
If requested, by specifying ot-composefs=signed=/path/to/pub.key then
the commit object is validated against the specified ed25519 public
key, and if valid, the composefs digest from the commit object is used
to ensure we boot the right digest.
Let's describe the state of things at a high level, independent
of the tracking issue which has a lot more detail (and hence noise).
This document keeps things at a high level and describes how to
enable things today.
Make a copy of `man/html` to `docs/man` and then configure Jekyll to
include it verbatim like the API docs. A link is added to the main index
and the necessary commands are added to the github docs workflow.
Make a copy of `apidoc/html` to `docs/reference` and then tell Jekyll to
include it verbatim. This will include the gtk-doc API docs on the
static site. A link is added to the main index.
A script is added to do the copy (a symlink won't do) and is setup to
run before Jekyll in the GitHub workflow. Ideally this would be a local
Jekyll plugin to make the process automatic, but the github-pages gem
doesn't allow that.
This mimics the GitHub Pages environment so that you can build and serve
the site locally for testing. It's will also be required later for using
Jekyll Actions[1] instead of the automated GitHub Pages flow.
1. https://github.com/marketplace/actions/jekyll-actions
This returns a 404 since the site is already generated from the docs
directory. Furthermore, the `CONTRIBUTING.md` markdown file isn't in the
generated site, just the HTML.
Instead, use jekyll's `link` tag to create the link. Unfortunately,
before jekyll 4.0 (github-pages uses 3.9), you have to prepend the base
URL.
