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!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
I was hitting an error during sysroot loading while playing
with deployment staging, and it wasn't initially
clear which phase was causing it (a client-initated reload versus
one we do before or after deploying). Add some error prefixing.
Closes: #1355
Approved by: jlebon
Now that infrastructure for this has landed in libostree,
let's make it easy for people to opt-in to testing it. This is a distinct first
step for adding it as an update policy.
Closes: #1352
Approved by: jlebon
Since we unified the pkgcache repo in 7056e6b726
there's no longer a reason to perform two repository prunes.
Change things so that the first phase is regenerating all of the
refs (in a single libostree txn), then perform a single prune.
This is preparation for reworking how we do prunes, which is
going to be useful for staged deployments.
Closes: #1351
Approved by: jlebon
Right now, cached updates generated during "check" policy runs are
completely decoupled from upgrade operations. This can lead
to the surprising situation where the "Available update" is *older* than
a freshly deployed pending tree with `rpm-ostree upgrade`.
We should just generate a cached update after upgrade operations. This
is also prep for staged deployments, where we'll want to do this as
well.
Note that we write out the cached update here even if automatic updates
are turned off since it's essentially free. I've been thinking about
always displaying that information after an `rpm-ostree upgrade` in
`status`. Though not sure if we should keep it in a separate "Available
update" section, or somehow morph it as part of the pending deployment
output.
Closes: #1344
Approved by: cgwalters
Previously we merged: #1228 AKA 12dc565b00
My recollection is that was working on it the background, while doing
something else, and I clearly didn't get to the point of testing it "for real".
There are many interlocking issues here to make this work. For example,
the "remove RPM" logic needs special handling for the kernel, because
we also inject content into `/usr/lib/ostree-boot` and also generate
the initramfs, etc.
The architecture I chose is to have the core *detect* when a kernel
is changed, and also call into the kernel processing code when removing
a kernel package. But the logic for doing kernel reinstallation client-side
is best alongside the initramfs generation logic which already existed
in the sysroot upgrader.
I extended the test suite to cover what was failing before, and I
tested this interactively. But I'm uncertain about adding a test
for actually *booting* into the GA kernel as it's quite possible
some bits in userspace rely on a newer kernel. Fixing this properly
really wants some infrastructure to better "re-version" an existing
package without changing its content.
Closes: https://github.com/projectatomic/rpm-ostree/issues/1334Closes: #1346
Approved by: jlebon
Building on:
- 9cbec27d4c
- e7a42f70a9
I was looking at a rpm-ostree run that imports a variety of rpmmd-repos,
and information about the source repositories is really useful for determining
the up-to-dateness. We've been capturing this data for a while, it's
about time we started showing it somewhere.
This does make `status --verbose` notably more verbose, but eh, that
seems fine for now.
See also https://github.com/projectatomic/rpm-ostree/issues/774Closes: #1345
Approved by: jlebon
I was going to add a `StagedDeployment` property and
found the code here confusing in the way we were walking
the whole deployment list. Let's use the
`ostree_sysroot_query_deployments_for()` API for all
cases here. Then the special case is just:
"if no booted deployment, default == pending".
Also change the code style to declare-and-initialize.
Prep for staging deployments.
Closes: #1327
Approved by: jlebon
This fixes a small regression from #852 which prevented inactive
overrides to be reset. Which is funny, because that's exactly the most
likely time when you would want to reset an override.
Basically, the `!is_layered --> no overrides` doesn't make sense for
inactive overrides. I suspect most people worked around this by just
using `reset --all`.
Closes: #1323
Approved by: cgwalters
If the user never ran e.g. `rpm-ostree install`, then the cache dir will
not even exist yet. Let's make sure it's created before writing the
cached update into it.
Closes: #1324
Approved by: cgwalters
Enhance `rpmostree_sysroot_upgrader_deploy` to also return the newly
created deployment on success. Prep for more work.
Closes: #1324
Approved by: cgwalters
Add a new `Reload` method as a softer alternative to `ReloadConfig`.
We'll also make use of this on the client side to sync with the daemon.
Closes: #1311
Approved by: cgwalters
Follow-up to previous commit. Since we have so many concepts called
"sysroot" and "configs", let's be explicit with our naming here to be
sure we know what we're calling.
Closes: #1311
Approved by: cgwalters
In this PR: https://github.com/projectatomic/rpm-ostree/pull/1309
I was hitting race conditions running `ostree admin pin` then
`rpm-ostree cleanup` as it was possible that the daemon hadn't handled
the inotify on the sysroot and reloaded the deployment state before
the txn request came in.
Close this race by doing an implicit `reload` before starting a txn.
This is a pretty efficient operation because for the sysroot we're
just doing a `stat()` and comparing mtime.
Implementation wise, change the external API to drop the "did change"
boolean as nothing outside of the `sysroot.c` file used it.
A followup to this would be changing the `status` CLI to call a
(new) DBus API like `RequestReload` that at least did the sysroot
reload if the daemon was otherwise idle or so? And it'd be available
to unprivileged users.
Closes: #1311
Approved by: cgwalters
Moving to caching the GVariant to disk rather than during RPMOSTreeOS
reloads broke the legacy `DownloadUpdateRpmDiff` path because it relied
on the implied recalculations that occur on reloads to update
`CachedUpdate`.
This patch series was initially going to be about just migrating all the
legacy APIs to make use of the new metadata, which would have fixed this
properly. But we first need some real coverage in that aread, which is
very poor right now. I'd like to investigate integrating the Cockpit
tests (at least the ostree-specific parts) into our CI to remedy this.
Anyways, for now at least, let's fix Cockpit.
Closes: #1300Closes: #1303
Approved by: cgwalters
We would write to the journal when we initiated a new transaction as
well as when that transaction errored. This just completes the picture
by also writing when the transaction finished successfully. My ulterior
motive is to make testing easier.
Also make sure to print the method name, which is more telling than the
object path.
Closes: #1303
Approved by: cgwalters
This came up in a few places recently; it happens for RHEL in some
cases, and in general we don't want to completely fail the daemon
start if someone messes up their remote config.
Closes: https://github.com/projectatomic/rpm-ostree/issues/1301Closes: #1302
Approved by: jlebon
Implemented in libostree in https://github.com/ostreedev/ostree/pull/1464
Let's display it - wrapping the command will come later.
I also just noticed `rpmostree_syscore_filter_deployments()` at least is
going to have to learn about pinning; will need to improve the test suite
around this too.
Closes: #1292
Approved by: jlebon
Rather than recalculating `cached-update` as part of transaction
cleanups and RpmostreedOS internal reloads, write it directly to a file
from `deploy_transaction_execute`. This gives two major benefits:
1. Auto-updates now has virtually zero impact to daemon startup time.
2. We get to directly use the `DnfSack` created during metadata refresh
rather than reconstructing it later on. This greatly simplifies code.
This makes use of new APIs in libdnf to skip filelists and load
updateinfo metadata right from the start.
Closes: #1268
Approved by: cgwalters
Allow callers to pass flags directly to libdnf depending on their needs.
Make use of this in `refresh-md` at least so that we don't even bother
loading the rpmdb since we're just interested in downloading fresh bits.
Closes: #1268
Approved by: cgwalters
Not sure what I was thinking using "makecache" as the human-friendly
title for this transaction, when the well-known name is "refresh-md".
Let's just make these match.
Closes: #1284
Approved by: cgwalters
To reduce confusion in future versions of myself and other readers,
complete the suggested rename from "redirect-output" to "output-to-self"
to internal variable names as well.
Closes: #1283
Approved by: cgwalters
This renames the API functions in the core and origin, and also fixes up the
fact that we were still looking for `jigdo/` refs in the pruning code.
Closes: #1279
Approved by: jlebon
If one isn't actually booted in a deployment, we'd get `NULL` from
libostree. Check for it before trying to use it. Something something
Rust.
This will all go away soon with #1268, though this quick fix should
allow anyone hitting this to use FAHC RPMs to move forward.
Closes: #1282
Approved by: cgwalters
As mentioned during code review, it feels odd to have our automatic
service collect output under its name rather than the main daemon. It
shouldn't be thought of as a daemon with its own logs, it's really just
a trigger.
We change this here so that for automatic updates, output is redirected
to the daemon stdout, which of course goes to the journal. This should
make logs in case of errors more discoverable as well since
`rpm-ostreed` is the well-known name.
I drilled down the notion directly into `RpmostreedTransaction` since I
think it's a useful property that might be handy at a more general
level.
Closes: #1278
Approved by: cgwalters
Didn't hit this, but clearly we should check if there's even a
transaction to listen to before trying to connect a signal.
Closes: #1278
Approved by: cgwalters
This was superseded by `rpmostree_output_message`. This is prep for
being able to "silence" transactions and instead have all the output go
to the daemon.
Closes: #1277
Approved by: cgwalters
We're continuing an incremental renaming process; previously we changed
the most user-visible strings. Now we're doing some internal variables,
and notably the cached refs and the origin files - the latter set is
things that end up on disk.
This leaves the biggest items; renaming APIs, files, and tests.
Closes: #1276
Approved by: jlebon
Let's also make sure we refresh `RPMOSTreeOS` objects when configs
changed. Specifically, what they export to their D-Bus interfaces may be
dependent on daemon settings, as is the case with auto-updates.
We might want to decouple this into two separate signals in the future
(one for sysroot changes, and one for config changes), though given that
only `RPMOSTreeOS` listens for `UPDATED` right now, we can just get away
with a single one for the time being.
Closes: #1261
Approved by: cgwalters
I initially used `oneshot` for this since it felt like a better fit for
non-daemon services. But the only practical difference between the two
is that systemd will wait until we exit before running dependent
follow-up units.
I'd like to change this to `simple` because we can expect users to force
a trigger run using `systemctl start rpm-ostree-automatic`, which will
hang until completion in `oneshot` mode. And given that we're not part
of the boot process and no other unit depends on us, the distinction
makes no semantic difference to us.
Closes: #1261
Approved by: cgwalters
While playing with the freshly built v2018.2 Fedora packages on my
Atomic Workstation, I realized that we paid the auto-updates startup
cost even when it was disabled. I've had auto-updates on for so long, I
hadn't seen this pass by me. 🙈
The long-term fix here is caching the update to disk rather than
recalculating it on startup everytime (as suggested during review). Will
work on this as follow-up. Though for now, I'd like to get this smaller
patch in and backported to Fedora so only folks opting in to try it out
experience the >1s startup delay.
Closes: #1261
Approved by: cgwalters
What's happened up till now is supporting `rojig://` in the same way as
`ostree://`. However, part of the high level goal here is to reduce
the need for system administrators to understand ostree.
This patch set starts to introduce some of the ideas for client-side
changes as part of jigdo ♲📦:
https://github.com/projectatomic/rpm-ostree/issues/1081#issuecomment-348540604
Concretely, we start using `${repo}:${nevra}` instead of `rojig://`.
(v2): Keep `Version` (plus timestamp) as a split out field for maximum visual aid.
Also, let's be opinionated here and entirely drop the `Commit` checksum by
default. I believe the Cockpit guys were right here - versions are for humans.
The fact that we have a checksum is powerful; and we still show it with `status
-v`. The way I think of it is: the checksum shows we're really an image system.
But we don't need to show it by default.
Closes: #1240
Approved by: jlebon
Pick up security advisories when checking for pending updates and
include them in the `cached-update` property. On the client-side,
display them in the output of `status`.
This was part of the original vision for how useful a smart `check` mode
could be. It directly impacts how one manages their individual system
(e.g. when to reboot), and paves the way for integration into
higher-level apps that act at the cluster level.
Closes: #1249
Approved by: cgwalters
Fix logic to make sure we check if the refspec is of type `ostree://`
even when it's explicitly specified. Also fix `Deploy` in the case where
we didn't just `Download` the RPM diff by adding a new @checksum
parameter to the higher-level API.
Finally, add a basic test for the `GetCached*RpmDiff` APIs so we have at
least *some* coverage. This is also good prep for making sure we don't
break anything when we convert those APIs to use the more efficient
pkglist metadata. The tests completely ignore the `DownloadRpmDiff`
paths for now though.
Closes: #1250Closes: #1253
Approved by: cgwalters
This fleshes out an important piece of the story, showing that
we can support history versioning the same way that we did with
ostree.
Also it's very useful for testing; I'm going to extend the suite after this to
deploy the previous version, clean everything up, then upgrade and verify we
only download changed RPMs.
Closes: #1232
Approved by: jlebon
The way we import packages in jigdo mode is different from package layering; we
may only import a subset of files for example. In general, we need to treat
jigdo differently.
Related: https://github.com/projectatomic/rpm-ostree/issues/1197Closes: #1238
Approved by: jlebon
Typing `rpm-ostree upgrade` was quite verbose with layered packages, we'd see
the rpm-md repos twice. The better fix would be to pass the context/sack from
one stage to the other, but this is a quick simple fix to at least reduce
verbosity (and potentially avoid extra network requests).
Closes: #1241
Approved by: jlebon
This is an initial drop of support for:
`rpm-ostree rebase rojig://fahc:fedora-atomic-host`. We also
then support `rpm-ostree upgrade` from that.
There's a lot that could be improved here; the test coverage is relatively
minimal. A blocking issue there is having a realistic jigdo setup, and that's
going to require changing how we do testing. For now, this means that if we want
to e.g. change the format we'll have to temporarily disable this test, get the
format change in, update FAHC, then re-enable the test.
Closes: #1166
Approved by: jlebon
If we can't read the system state, that's an *external* problem with e.g. files
most likely, not a situation in which we should abort.
This came up while playing with `rojig://` where we seem to write
the origin file incorrectly.
Closes: #1166
Approved by: jlebon
There are types that we want to share between the daemon and the client
for deduplication. Those are, as expected, related to D-Bus things like
formats and enums. Let's create a new file for it rather than shove it
in `rpmostree-util.h`. As mentioned in the file, some of these probably
belong better directly in the public API.
Closes: #1147
Approved by: cgwalters
This patch introduces a new `AutomaticUpdatePolicy` configuration. This
was a long time coming for rpm-ostree, given that its update model makes
it extremely apt for such a feature.
The config supports a `check` mode, which should be very useful to
Atomic Workstation users, as well as a `reboot` mode, which could be
used in its present form in simple single node Atomic Host situations.
There is still a lot of work to be done, including integrating
advisories, and supporting a `deploy` mode. This feature hopefully will
be leveraged as well by higher-level projects like GNOME Software and
Cockpit.
Closes: #1147
Approved by: cgwalters
We don't want to print a warning if the setting is missing from the
config file. That's totally normal (e.g. the config we ship has all its
configs commented out). We *do* want to print a warning if the config is
provided, but it couldn't be parsed as a proper `uint64`.
Closes: #1215
Approved by: cgwalters
