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!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
The `Journal::open` API has been deprecated in favour of the new
`OpenOptions` builder pattern.
We could dedupe this a bit more, though the mock journal in the history
code makes it trickier and there's little value in mocking the builder
pattern too.
Those got moved to GitHub from readthedocs.io, meaning links pointing
to specific pages return a 404, so this fixes that along with
skipping the redirect for the links that just point to the main page.
We have no business accessing `/var/roothome` or `/var/home`. In general
the ostree design clearly avoids touching those, but since systemd offers
us easy tools to toggle on protection, let's use them. In the future
it'd be nice to do something like using `DynamicUser=yes` for the main service,
and have a system `rpm-ostreed-transaction.service` that runs privileged
but as a subprocess.
Now always based on an overlayfs:
f2773c1b55
This fixes a whole swath of problems with the previous design,
including the danger in replacing `/usr/lib/ostree-boot` which
broke booting for some people.
Further, we don't need to push a rollback deployment; the livefs
changes are always transient. So now we store livefs state
in `/run` instead of in the origin file.
Since we're doing a rewrite, it's now in Rust for much more safety.
We also always work in terms of incremental diffs between commits;
the previous huge hammer of swapping `/usr` was way too dangerous.
The libdnf plugins are not really relevant for us (the only in-tree one
is for RHSM). Let's tell libdnf to not even bother trying to load them
in.
Prompted by the fact that libdnf tries to load the plugins from the
bundled path which doesn't exist:
```
libdnf-WARNING **: 13:49:33.207: Can't read plugin directory
"/usr/libexec/rpm-ostree/lib64/libdnf/plugins/": No such file or
directory
```
In test contexts, this warning causes a `SIGABRT`.
This effectively reverts commit: c8113bde32
We never ended up using it; instead the `rdcore` bits from
`coreos-installer` have the rootfs reprovisioning logic.
This allows us to fix RHCOS builds with coreos-assembler
after e76b270198
That broke change detection.
We need to explicitly provide the previous commit. This is
very similar to `--parent`, and arguably we should
have made `--parent` have change detection semantics too
at the time.
See https://github.com/coreos/rpm-ostree/pull/2206#issuecomment-721372634
The commit 7f579a55d3fb7ec1cb9f74f8ec6bc36675df2ccc broke hashing
of overlay commits; this is a super evil bug because it causes us
to silently do the wrong thing.
The cause here is the GLib bindings don't (AFAICS) support getting
a `&mut` for a GLib boxed value.
Move all of the treefile checksum code into one place - this is
far saner. The reason I didn't do this before is that it
will cause a spurious rebuild when one updates rpm-ostree, but...eh.
Particularly in places like the lockfile code where we were iterating
on a list of packages, validating UTF-8 and `memcpy()`ing strings
from C is...well, unnecessary.
I don't think there's any actual real performance concerns right
now but let's use this as a best practice because the patterns
we establish *will* be copy+pasted or at least used as inspiration
for other places where performance might matter.
I happened to scroll past this code while doing something
else and noticed what we were doing here was silly - no need
to re-validate UTF-8 etc when serde can hand us a `String` directly.
Clippy reports this as an error; I think in practice Linux
doesn't return short writes for regular files, but it's still
a good idea to do the right thing here.
This command allows users to cheaply inject configuration files in the
initramfs stage without having to regenerate the whole initramfs (or
even a new OSTree commit). This will be useful for configuring services
involved in bringing up the root block device.
```
$ echo 'hello world' > /etc/foobar
$ rpm-ostree ex initramfs-etc --track /etc/foobar
Staging deployment... done
Run "systemctl reboot" to start a reboot
$ rpm-ostree status
State: idle
Deployments:
ostree://fedora:fedora/x86_64/coreos/testing-devel
Version: 32.20200716.dev.1 (2020-07-16T02:47:29Z)
Commit: 9a817d75bef81b955179be6e602d1e6ae350645b6323231a62ba2ee6e5b9644b
GPGSignature: (unsigned)
InitramfsEtc: /etc/foobar
● ostree://fedora:fedora/x86_64/coreos/testing-devel
Version: 32.20200716.dev.1 (2020-07-16T02:47:29Z)
Commit: 9a817d75bef81b955179be6e602d1e6ae350645b6323231a62ba2ee6e5b9644b
GPGSignature: (unsigned)
$ reboot
(boot into rd.break)
sh-5.0# cat /etc/foobar
hello world
```
See the libostree side of this at:
https://github.com/ostreedev/ostree/pull/2155
Lots more discussions in:
https://github.com/coreos/fedora-coreos-tracker/issues/94Closes: #1930
Let's just use the GLib translation bits rather than rolling our own;
this applies primarily to `ffi_new_string()`.
However, I think in most cases performance here doesn't
matter enough to have an even more special case that avoids duplicating
the string. Let's remove the `ffi_view_str()` optimization too
in favor of consistently using GLib translation.
In the future perhaps we should argue for adding a `from_glib_str_unchecked()`
to the upstream GLib bindings.
This avoids us leaking all of the Rust symbols as public
into our shared library.
Came up in team chat since one person tried to copy just `/usr/bin/rpm-ostree`
from the dev container into a target and got a linker crash; but
really we want to avoid all the duplicated symbols entirely.
(And we should investigate cross-language LTO because that's the
only way to get full savings)
This starts bridging parts of the daemon syscore logic to Rust
plumbing, moving the livefs detection logic over there as a first
consumer. That was the simplest logic available for wiring, and
mostly meant as a sanity check.
It's tempting to flip the default, but let's encourage
people to adapt to the `modules` version now.
Plus infrastructure to add deprecation warnings here
will come in handy in the future.
