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 change gives an error when --arg is specified on its own.
Previously, if adding --arg without --enable, no changes occur and
only the initramfs regeneration status is printed. Since --arg only
takes effect when used with --enable, this should also give an error
(or let the user know in some way).
Closes: #1548
Approved by: jlebon
Previously, after enabling initramfs regeneration, the initramfs
command would indicate that initramfs regeneratin is disabled,
suggesting that the initramfs had not actually been enabled. This
happened because the initramfs regeneration status for the current
deployment was printed; initramfs regeneration is only enabled for a
pending deployment.
This change prints the regeneration for the pending deployment,
rather than the current, when no options are given to the initramfs
command.
Fixes: #1526Closes: #1548
Approved by: jlebon
It's possible to run the `vmcheck` tests against an existing host that
has `rpm-ostree` already present. We don't overlay the built binaries
in this situation, so we should not check for the presence of the
overlay in the commit meta.
Closes: #1555
Approved by: cgwalters
This removes the logic around supporting opting out of the staging
feature. We don't want to support multiple configurations here, and at
this point, staging should be considered stable.
Closes: #1546
Approved by: cgwalters
Accumulate the list of requested packages that were not found and error
out with the full list rather than failing early. This fixes a small UX
papercut in certain situations.
Closes: #1540Closes: #1541
Approved by: cgwalters
Since `/tmp` might be on tmpfs, so we'd lose it on reboot. But we have
tests that need it to persist across reboots.
Closes: #1531
Approved by: miabbott
It's possible to run the `vmcheck` tests against an existing VM which
may not have any existing `/etc/yum.repos.d` directory. Since the
tests are providing their own repo files, we should be able to run
them in this uncommon configuration.
Closes: #1530
Approved by: jlebon
This teaches the client to fetch packages from URLs directly so that one
doesn't have to `curl` first and then install. Supported anywhere
package filenames are allowed (notably: `install` and
`override replace`).
One neat things about this is that we download the file into an
`O_TMPFILE` and then pass on ownership of that fd directly to the
daemon. So at no point are the packages actually laying visible on the
system. (Assuming the filesystem supports `O_TMPFILE` that is).
This adds direct linking to libcurl and openssl, two libraries which we
were already pulling in indirectly.
Closes: #1508
Approved by: cgwalters
We've put a lot of work into staged deployments, it's time
to pull the trigger and turn them on by default. This is
a key step for enabling `stage` mode automatic updates by
default in e.g. Fedora CoreOS/Silverblue.
We add a new `--disable-staged` build-time option to flip
things back.
Closes: #1430
Approved by: jlebon
Staging fixes the `/etc` bug for livefs. There's actually more
we could do here around taking advantage of staging for livefs;
for example, I think once the livefs is complete, we could just delete
the staged deployment. And then we don't need to render on the next
boot the live status, etc.
Anyways, all that can come in the future. This is prep for
enabling staging by default.
Closes: #1430
Approved by: jlebon
Fix `--booted` was printing an extra line after `Deployments:`. While
we're there, also update the section name to `BootedDeployment:` in that
case to be more correct. (We're not printing all the deployments, only
the booted deployment.)
Closes: #1503
Approved by: cgwalters
And don't mention "replace" in the error texts.
This is (now) known broken with kernel updates; making that not
dangerous isn't going to be easy. I debated entirely removing it
but for now let's just make it harder to use.
Ref: https://github.com/projectatomic/rpm-ostree/issues/1495Closes: #1497
Approved by: jlebon
This is analogous to `upgrade --upgrade-unchanged-exit-77`, but for
`install`/`uninstall`. This way, one can determine whether the command
truly had an effect on the default deployment or not.
Since this works by comparing against the previous default deployment,
this works correctly even if we already had a pending deployment at the
beginning of the transaction.
Closes: #1478
Approved by: cgwalters
Add a new `install/uninstall --idempotent` option to make it easier to
interact with the CLI through scripts. E.g. one doesn't have to check
first if a request has already been installed/uninstalled.
Closes: #1467Closes: #1478
Approved by: cgwalters
This makes it easier for scripts to determine whether there is a pending
deployment instead of using `--json/--jsonpath`.
Closes: #1478
Approved by: cgwalters
The `cached-update` variant would mark a bunch of RPMs as upgraded even
if they didn't actually change. The issue turned out to be we were doing
the diff all wrong in the staged deployment case. I'm not sure what I
was thinking in #1344, but essentially, we were marking all layered RPMs
in the staged deployment as updates instead of only marking those
layered RPMs which were actually changed EVR.
We just simplify the approach here by directly doing a pkglist diff
between the booted and staged deployments and consuming that. That's
really all there is to it! Reduces the code quite a bit too.
Closes: #1446Closes: #1455
Approved by: cgwalters
We're looking to embed an ostree commit inside a container image,
to make it easier to transport around with other images.
Conceptually here the host system is tracking a container (just
like for rojig we're tracking an RPM). This is the first step
towards making that support nicer; tooling can do
`rebase --custom-origin-url oscontainer://quay.io/exampleos@sha256:...`
and have that show up in `rpm-ostree status`.
There are two values, one intended to be machine readable (like
the `ostree://` and `rojig://` and one for humans which we
display when an admin types `rpm-ostree upgrade`.
This builds on prior work in
27bd7b97bb from #1396 .
Closes: #1406
Approved by: jlebon
This test was hard to adapt for staging. I did the obvious change
of just rebooting after most of the `kargs` invocations, but much
later in the suite there was a test that compared vs the "pristine"
kargs. Supporting that would be a bit hard...I briefly thought
about pinning etc. but it gets so messy to do in both staged and not-staged
defaults. So I just deleted those bits.
Closes: #1453
Approved by: jlebon
Noticed this while looking at the logs for #1432.
Because --check and --preview exit with rc=77 when there are no updates,
we would actually stop early on in the test and marking it as SKIPPED.
Fix this by making sure we explicitly check for the $rc we expected when
using those switches.
I also added a final grep pass to make it easy to inspect whether we
skipped any tests. I was about to do this nicely in `multitest.py`
instead, though it may not be of this world much longer, so meh...
Closes: #1450
Approved by: cgwalters
First, split it into its own section; it's important enough to merit it.
Second, explicitly reference the systemd timer/service units. For
example, a question I often have is "when is the next run" and of course
you can get that rpm `systemctl status rpm-ostreed-automatic.timer` but
you have to know that, and the reminder helps.
(I briefly looked at implementing the `Trigger` line from `systemctl status`
but it's not entirely trivial...tempting to just fork off a `systemctl status | grep `)
Prep for unifying this text with the message we print when one does
`rpm-ostree upgrade` when auto-updates are enabled.
Closes: #1432
Approved by: jlebon
First the pinning tests would try to pin a staged deployment,
and some of the later tests here depend on a subtle way on the
state of the system. It's tempting to do a `reset` before each one
and reboot but this makes things work.
There's some additional assertions here as I went through and
was debugging.
Prep for making staging the default.
Closes: #1438
Approved by: jlebon
Add a new `reset` command that makes it easy to blow away all
customizations: overlays, overrides, and initramfs. One can use flags to
only reset some of the customizations.
I placed this under `ex` out of conservatism. It's a pretty simple
command with simple behaviour, though the features it relies on
(no-layering, no-initramfs) are brand new. We can move it out of there
in a release or two?
Closes: #1387Closes: #1419
Approved by: cgwalters
It's been in experimental for a while now, and we've had good feedback
that it's working. With #1392 fixed, it seems in a good position to
declare stable and commit to that API. This also helps empty out `ex` a
bit.
Closes: #1428
Approved by: cgwalters
We added the `no-layering` option, but made it conflicting with
`--install`. This loosens that requirement so that one can do e.g.
rpm-ostree uninstall --all -install foobar
to essentially remove all layered packages and then add back `foobar`.
Prep for `reset` command.
Closes: #1424
Approved by: cgwalters
Kernel arguments added from `rpm-ostree ex kargs` can be lost
after doing multiple deploy related operations (e.g upgrade, install etc).
The root cause of that is because when doing the deployment
(ostree_sysroot_deploy_tree), the kernel arguments from the
pending deployment were never passed in.
This commit adds logic to pass in kernel arguments from pending deployment
to fix the above mentioned problem
Closes: https://github.com/projectatomic/rpm-ostree/issues/1392Closes: #1420
Approved by: cgwalters
This is one part of #1387 and is prep for a single higher level command
that makes it easier to remove all customizations (layering *and*
overrides).
Closes: #1408
Approved by: cgwalters
Doing `override reset --all` may be a no-op if there are no overrides
currently applied. But we were trying to always print the tree diff
under the assumption that all override invocations have to result in a
new deployment.
Fix this by using the same default deployment check that `upgrade` does
before printing.
Closes: #1407
Approved by: cgwalters
This fixes a painful UX issue where one must use the full NEVRA when
uninstalling a locally layered RPM. Now, one can specify either the
NEVRA or the package name only. Though we still try to interpret the
request first as a NEVRA or a capability.
Closes: #1386Closes: #1400
Approved by: cgwalters
There are a few scenarios today where one might deliver content
to a machine via an external transport. For example, take the
scenario of a single server updated via USB drive. While we
can provide a refspec...what should the remote be? (This gets
into ostree collections). There's nothing really that can
happen when typing `rpm-ostree upgrade` unless the USB stick
is plugged in. That type of scenario should be emphasized
by pinning the commit - the machine is updated via an external
script.
Another case: we're experimenting embedding OSTree commits inside OCI
containers. Here again since rpm-ostree can't understand how to
pull content from containers, it's saner to drop the refspec
bits, and pin to a commit.
Further enhancements will follow to make the admin experience more
obvious.
Closes: #1396
Approved by: jlebon
For now all this switch does is turn off the scary warning. We also
tweak the warning to make it clear that this will be required in a
future release.
Closes: #1378
Approved by: cgwalters
I was honestly surprised to see this test was running all this time for
CentOS. As cool as it is, this test is really more meant for Fedora.
Closes: #1382
Approved by: jlebon
We were trying to test that doing `override remove` on a layered package
errored out. But the test was bogus since `foo` is a base package here.
Let's just use a brand new package that will actually be layered.
Closes: #1382
Approved by: jlebon
Just part of the continuing breakdown of our testsuites into smaller
pieces for more efficient allocation.
Will add a test case to the `layering-basic-2.sh` in a follow-up commit.
Closes: #1382
Approved by: jlebon
With the new support for pinning deployments, we need to also update
rpm-ostree to clean up the transient state as is now done in the ostree
sysroot upgrader.
This addresses that issue as well as tries to be a little cleaner in how
we clean up other transient state. Notably, we add a new helper function
to `RpmOstreeOrigin` to do this for us and use it in the upgrader. In
other cases, we do want this transient information since it allows us to
describe the deployment.
Closes: https://github.com/ostreedev/ostree/issues/1595Closes: #1372
Approved by: cgwalters
This makes the logs a bit more useful, but the ultimate goal
here is to write the originating client `id` to the cached update
data, so users know that e.g. `gnome-software` triggered it.
Closes: #1368
Approved by: jlebon
Following up to https://github.com/projectatomic/rpm-ostree/pull/1352
AKA 506910d930
which added an experimental flag to globally enable deployment
staging, let's add an `ex-stage` automatic update policy.
I chose to create a new `test-autoupdate-stage.sh` and rename
the previous one to `test-autoupdate-check.sh` in going with
the previous theme of smaller test files; it's
way faster to iterate on new tests when it's a new file. And adding
staging at the top would have been weird.
This was all quite straightforward, just plumbing through lots
of layers.
Closes: #1321
Approved by: jlebon
The common case is having layered packages and no overrides; seeing
`Applying 8 overlays` then `Building filesystem [0/8]` is redundant.
Tweak the progress to avoid the double message. Also change the terminology
to clarify that each item is a package.
Also update libglnx to pull in progress bar newline fix.
Update submodule: libglnx
Closes: #1363
Approved by: jlebon
Follow-up from #1344.
In the case where a cached update is created from an `upgrade` operation
(and soon, "stage" auto-update policy runs), we can just print the diff
and advisory info together with the pending deployment. This makes the
output look much more natural.
Closes: #1350
Approved by: cgwalters
This now works after https://github.com/ostreedev/ostree/pull/1570
However, I was hitting an issue with the temp httpd running the
tests serially, let's split them up.
Really the only sane thing is to run each of these tests in a fresh
VM; we'll do the VM-in-container pattern here hopefully soon.
Closes: #1355
Approved by: jlebon
