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 backend always explicitly emitted a `/boot` - but if
the global `sysroot.bootprefix` is enabled, then we can rely
on the outer code doing it.
Luckily this was caught by the unit tests here failing when
enabling `sysroot.bootprefix` by default.
This generates the new format for whiteout markers which was added in
6.8 (and which will be backported to 6.7). Without this whiteouts
will not work anymore.
This is a slight format change, but will only affect ostree commits
that already were broken (i.e that had whiteouts), and since the
composefs code is still marked experimental I think it is fine to
do this without introducing another format version on the ostree
side.
Signed-off-by: Alexander Larsson <alexl@redhat.com>
Add new commands to pin the current, staged and previous deployment for
use in automation and scripting. Right now, it's difficult to pin the
current deployment without needing to look into the output of some other
tooling (like rpm-ostree) to get the index of each deployment. This
index also is not consistent - the current deployment could be 0 when
you first boot the system then 1 shortly after. This change makes it
easy to pin the current or future deployment.
Co-authored-by: Robert Sturla <robertsturla@outlook.com>
Signed-off-by: Eric Curtin <ecurtin@redhat.com>
Currently if run in a container image under systemd, we will
incorrectly synthesize a `var.mount` unit even if `ostree-prepare-root`
hasn't run.
The comment here said why we didn't do that before, but that's
for the really legacy embedded-only "ostree-prepare-root-static"
path, and even then I'm pretty sure it was wrong because
the generator here only runs in the *real* root, and we should
have `/run/ostree` at that point.
Otherwise, this test fails on Debian 12 (Linux 6.1) kernels if /var/tmp
is a tmpfs. Some autobuilders put the entire build chroot on a tmpfs,
to speed up builds.
Signed-off-by: Simon McVittie <smcv@debian.org>
It's a followup of commit e6a560b407.
We should also ignore sockets and fifos in the subdir of /etc.
Signed-off-by: Yuanhong Peng <yummypeng@linux.alibaba.com>
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.
