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!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
A core underlying primitive in the C library is the ability
to arbitrarily reorder bootloader entries.
Let's expose the basic functionality here with the ability to pick
an arbitrarily deployment for the next boot.
Closes: https://github.com/ostreedev/ostree/issues/2965
Today on anything using readonly sysroot `os-init` fails, because
we don't create a mount namespace if the `UNLOCKED` flag is specified
because we assume it's a readonly operation.
Since technically this is a mutation, let's just lock the sysroot
and use the tested path.
In preparation for support for a transient `/etc`:
https://github.com/ostreedev/ostree/issues/2868
particularly in combination with composefs.
Basically it's just much more elegant if we can directly mount
an overlayfs on the *empty* `etc` directory, using `usr/etc` as
the lower.
In the composefs case, we'd have to mount the composefs overlayfs
itself writable (and call `mkdir`) *just* so we can make that
empty `etc` directory which is ugly.
Let's verify that things work with that off, as they should.
Previously:
cb73129483
"deploy: Add a 5s max timeout on global filesystem sync()"
But we may still have problems even with that, see
https://issues.redhat.com/browse/OCPBUGS-15917
where it might be that even a thread doesn't work because
we're locked in the kernel.
I just noticed that this was another constant string duplicated
between prepare-root.c and libostree-1.so, and I went to make
it a common `#define` in libotcore.la.
But then I thought "it's ugly to have this directory mixed into
the deployment namespace" because in some theoretical world
it could also be in the ostree commit, which would cause weird
behavior.
I think this is transient state that is better in `/run`, so move
it there.
Passing the private key via a direct command line argument
is just a bad idea because it's highly likely to get logged
or appear in `ps`.
Spotted in review of work for composefs signatures.
Particularly for the signature case, having this metadata
acts as a reliable "proof of execution" of the signature verification
code (as opposed to parsing a log file or so).
Besides that, this is also just a stronger check for "we're using
composefs" instead of checking for "overlayfs on /".
- Was using the wrong metadata key
- We were missing setting the canonical commit args which assigns
e.g. owner uid 0, which is important for reproducibility
- Use the new --print-hex to make things easier to read
See https://github.com/ostreedev/ostree/issues/1593
Basically this makes it easier for people packaging, as the trivial-httpd
is only for tests, and this way the binary will live with the tests.
Also at this point nothing should depend on `ostree trivial-httpd`.
I think this just accidentally was never enabled.
While looking at the code, add a sleep here to be resilient to
filesystems with only second mtime granularity.
I am not sure why this is failing on older Debian systems,
but I'm wildly guessing that something being done in `libtest.sh`
is setting up automake in a way that we need. This is done
in other tests.
Or maybe it's the missing `$CMD_PREFIX`? Let's see...
I think there's never been a real race condition here. Instead
the problem is:
- We have a timeout on the lock, after which we error out (30s)
- This test actually *lowers* the timeout
Looking through the failures for test-concurrency what I see
is
`error: Locking repo exclusive failed: Resource temporarily unavailable`
which is us hitting the timeout.
Hardcoded timeouts are just going to be subject to race conditions.
I understand not wanting to block forever in some cases, but any
arbitrary timeout is just going to get hit in real world conditions
too.
Anyways for now, stop shooting ourselves in the foot and at least
keep the timeout at the default.
Closes: https://github.com/ostreedev/ostree/issues/2038
The `f_bfree` member of the `statvfs` struct is documented as the
"number of free blocks". However, different filesystems have different
interpretations of this. E.g. on XFS, this is truly the number of blocks
free for allocating data. On ext4 however, it includes blocks that
are actually reserved by the filesystem and cannot be used for file
data. (Note this is separate from the distinction between `f_bfree` and
`f_bavail` which isn't relevant to us here since we're privileged.)
If a kernel and initrd is sized just right so that it's still within the
`f_bfree` limit but above what we can actually allocate, the early prune
code won't kick in since it'll think that there is enough space. So we
end up hitting `ENOSPC` when we actually copy the files in.
Rework the early prune code to instead use `fallocate` which guarantees
us that a file of a certain size can fit on the filesystem. `fallocate`
requires filesystem support, but all the filesystems we care about for
the bootfs support it (including even FAT).
(There's technically a TOCTOU race here that existed also with the
`statvfs` code where free space could change between when we check
and when we copy. Ideally we'd be able to pass down that fd to the
copying bits, but anyway in practice the bootfs is pretty much owned by
libostree and one doesn't expect concurrent writes during a finalization
operation.)
I've deprecated sh-inline; in the end I think it is better
to minimize the amount of bash code we have. xshell solves
the core convenience problem of taking local variables and mapping
them to command arguments.
A full port would be nontrivial; this just starts the ball
rolling.
During the early design of FCOS and RHCOS, we chose a value of 384M
for the boot partition. This turned out to be too small: some arches
other than x86_64 have larger initrds, kernel binaries, or additional
artifacts (like device tree blobs). We'll likely bump the boot partition
size in the future, but we don't want to abandon all the nodes deployed
with the current size.[[1]]
Because stale entries in `/boot` are cleaned up after new entries are
written, there is a window in the update process during which the bootfs
temporarily must host all the `(kernel, initrd)` pairs for the union of
current and new deployments.
This patch determines if the bootfs is capable of holding all the
pairs. If it can't but it could hold all the pairs from just the new
deployments, the outgoing deployments (e.g. rollbacks) are deleted
*before* new deployments are written. This is done by updating the
bootloader in two steps to maintain atomicity.
Since this is a lot of new logic in an important section of the
code, this feature is gated for now behind an environment variable
(`OSTREE_ENABLE_AUTO_EARLY_PRUNE`). Once we gain more experience with
it, we can consider turning it on by default.
This strategy increases the fallibility of the update system since one
would no longer be able to rollback to the previous deployment if a bug
is present in the bootloader update logic after auto-pruning (see [[2]]
and following). This is however mitigated by the fact that the heuristic
is opportunistic: the rollback is pruned *only if* it's the only way for
the system to update.
[1]: https://github.com/coreos/fedora-coreos-tracker/issues/1247
[2]: https://github.com/ostreedev/ostree/issues/2670#issuecomment-1179341883Closes: #2670
When hacking and testing locally with `cosa build-fast` and `kola run`,
I prefer to leave testing framework stuff within the work directory
rather than installed in my pet container. Add a `localinstall` target
for this which puts the tests in `tests/kola`. Then a simple `kola run`
will pick it up.
AFAICT, I don't see how `runkola.sh` or the Makefile in `tests/kolainst`
can create files in `tests/kola` since it's geared towards installing
under `/usr`.
g_steal_fd() exists in GLib since 2.70, and libglnx has a backport for
older GLib versions, equivalent to the libglnx-specific glnx_steal_fd().
Signed-off-by: Simon McVittie <smcv@collabora.com>
XFS now seems to want filesystems larger than 300MB, so switch
to ext4. Also use `20MiB` so we align to 512b sectors to squash
a `losetup` warning.
Also tweak some of the numbers to still work.
