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!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
In the OSTree model, executables go in `/usr`, state in `/var` and
configuration in `/etc`. Software that lives in `/opt` however messes
this up because it often mixes code *and* state, making it harder to
manage.
More generally, it's sometimes useful to have the OSTree commit contain
code under a certain path, but still allow that path to be writable by
software and the sysadmin at runtime (`/usr/local` is another instance).
Add the concept of state overlays. A state overlay is an overlayfs
mount whose upper directory, which contains unmanaged state, is carried
forward on top of a lower directory, containing OSTree-managed files.
In the example of `/usr/local`, OSTree commits can ship content there,
all while allowing users to e.g. add scripts in `/usr/local/bin` when
booted into that commit.
Some reconciliation logic is executed whenever the base is updated so
that newer files in the base are never shadowed by a copied up version
in the upper directory. This matches RPM semantics when upgrading
packages whose files may have been modified.
For ease of integration, this is exposed as a systemd template unit which
any downstream distro/user can enable. The instance name is the mountpath
in escaped systemd path notation (e.g.
`ostree-state-overlay@usr-local.service`).
See discussions in https://github.com/ostreedev/ostree/issues/3113 for
more details.
This is a tool to check if we are booted as default or not, just a
rename before it becomes widely used. We also shortened the '-h' output
for this.
Signed-off-by: Eric Curtin <ecurtin@redhat.com>
Generally in ostree based systems you would expect to boot into
deployment 0, in rollback conditions triggered by greenboot-related
rollbacks this might not be the case. This is a tool to detect this.
Signed-off-by: Eric Curtin <ecurtin@redhat.com>
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>
Prep for changing this service to perform state computations
such as "is this boot the default, or did we get rolled back"
that can be used by higher level tools.
If OSTREE_DISABLE_GPGME is not built in set remote to NULL.
The ostree_repo_signature_verify_commit_data path is irrelevant in the
no gpg case anyway. Having this set as NULL ensures an error gets
thrown early.
Signed-off-by: Eric Curtin <ecurtin@redhat.com>
The default `ostree admin status` tries to do signature
verification, but doesn't error out if that fails.
However, an extremely longstanding bug here is that we passed
the "osname" aka stateroot instead of the remote name. This
happens to work for e.g. Fedora Silverblue today, where they
are the same. It doesn't work on FCOS (remote = fedora, stateroot = fedora-coreos).
There are a few things the estimator doesn't account for, e.g. writing
the new BLS entries. Rather than trying to perfect it (since I think we
should change approach entirely -- see previous commit message), just
add a 1M margin to the space check.
When we estimate how much space a new bootcsum dir will use, we
weren't accounting for the space overhead from files not using the
last filesystem block completely. This doesn't matter much if counting
a few files, but e.g. on FCOS aarch64, we include lots of small
devicetree blobs in the bootfs. That loss can add up to enough for the
`fallocate()` check to pass but copying still hitting `ENOSPC` later on.
I think a better fix here is to change approach entirely and instead
refactor `install_deployment_kernel()` so that we can call just the
copying bits of it as part of the early prune logic. We'll get a more
accurate assessment and it's not lost work since we won't need to
recopy later on. Also this would not require having to keep in sync the
estimator and the install bits.
That said, this is blocking FCOS releases, so I went with a more tactical
fix for now.
Fixes: https://github.com/coreos/fedora-coreos-tracker/issues/1637
There's a test case for `ostree admin unlock --hotfix` that
runs in FCOS, not here; it breaks when enabling composefs.
The reason is because the composefs is mounted readonly, and
we tried to remount it writable. Instead of trying to remount
the rootfs writable at this point forcibly, honor the
*real* sysroot readonly state flag from the underlying FS before
we mounted the composefs.
Note that in FCOS derivatives we always have the root mounted
writable via `rw` on the kernel cmdline and this is the default
general expectation now with ostree usage.
If you don't have rw in the kernel cmdline or have ro in it, often you
hit this issue. This is just to be really explicit about that in the
error messages so people can check.
Signed-off-by: Eric Curtin <ecurtin@redhat.com>
To aid debugging issues like https://github.com/coreos/fedora-coreos-tracker/issues/1637
If we're hitting this path where we think we have enough space,
let's log what we calculated here to aid in diagnosing why we
may later fail with ENOSPC.
Closes: https://github.com/ostreedev/ostree/issues/3113
It'd greatly improve compatibility with things like RPMs that install
in `/opt` if we supported a full "original docker" style model where
`/` is a transient overlayfs. We'd still keep our semantics for `/etc`
and `/var` by default, but e.g. we'd stop recommending
`/opt` ➡️ `/var/opt`, in this model,
so `/opt` would be on the overlayfs.
Note this all aligns with composefs, where we'd actually be making
`/` a *read-only* overlayfs by default; it'd be really nice of course
to *implement* this by just making the composefs overlayfs writable,
but I am not sure we can hard require composefs for this right now.
So this change adds support for `root.transient = true`
in `/usr/lib/ostree/prepare-root.conf`.
The major downside is that people could be surprised if files they
write to e.g. `/opt` don't persist across upgrades. But, that's
already again how it works since Docker started.
Note as part of the implementation of this, we need to add a whole
new "backing" directory distinct from the deployment directories.
(Tangentially related to this, it's tempting to switch to always
using a *read-only* overlay mount by default.
