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!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
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
We weren't checking for an error from `dup()`, and further it shouldn't
be necessary. This is the best I could come up with, though it's
obviously not pretty.
Closes: #1444
Approved by: jlebon
It is actually really nice that there's One Canonical Style, even
if I sometimes don't like some details of what rustfmt does.
Closes: #1444
Approved by: jlebon
Further prep for adding more code here. The `lib.rs` then is the
collection of glue functions; perhaps in some ideal future it could
be generated even.
Closes: #1444
Approved by: jlebon
It makes more sense to have the include live next to the associated
code, just like we do with C, even though the `cargo build` doesn't
touch it.
Closes: #1444
Approved by: jlebon
Use the new API introduced in
9131d8a4cc
which helps avoid relying on the magical deployment refs. I thought
this would help with a livefs+staging issue, but it doesn't. But we might
as well do it, it's adding another level of safety.
Closes: #1439
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
Follow up to #1434. I was testing this inside my test VM, which didn't
have a rollback deployment (i.e. it was just the staged deployment and
the booted deployment). Testing the upcoming release on my real system
showed that this wasn't correctly fixed.
Closes: #1437
Approved by: cgwalters
It doesn't make sense to rollback a staged deployment. Give a hint
instead to use `cleanup -p` if needed. Otherwise, we dump core later on
in libostree.
This is technically a breaking change once staged deployments become the
default. However, I think it makes sense overall. We'll have to make
some noise about it.
Closes: #1434
Approved by: cgwalters
A new update might not have any package changes at all. In which case,
we shouldn't even try to print the diff, otherwise we'll fail on trying
to lookup the `upgraded` key. We did this check already from
`rpmostree_print_cached_update`, but not from `print_one_deployment`
(when printing the diff as part of the pending deployment), so we'd
error out on no-diff upgrades.
Let's just inline a check in the function directly instead of wrapping
every call site.
Closes: #1431
Approved by: cgwalters
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
Follow-up improvement after
https://github.com/openshift/os/pull/135
This should ensure it survives systemd's preset run on firstboot.
Although honestly...what we should *really* do is check whether
the `default.target` symlink target exists, and if not reset it
to `multi-user.target` so no one would have to care, but that'd
be conceptually separate from this, so I may do it later.
Closes: #1427
Approved by: jlebon
We actually want systemd's `ConditionFirstBoot` to fire. The
primary rationale here is that we're adopting Ignition for Fedora CoreOS,
and having `ConditionFirstBoot=` function will help a lot, as the idea
is it only runs once.
However, I discovered that this breaks the `units` directive for example,
as systemd blows away all the unit state in `/etc`. The correct thing
to do from the start is to use presets. We could add an implementation of
`units` which works with this on and instead writes a preset file but...eh.
My plan is to at some point introduce an "epoch" and flip various defaults,
this one, `tmp-is-dir`, the passwd file handling, etc.
See: https://github.com/dustymabe/bootengine/pull/11Closes: #1425
Approved by: jlebon
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
While looking at the inline help for `install`, I thought we could do
better by specifically stating that the `--uninstall` switch only
operates on layered packages. This might prevent any users from
trying to use the `--uninstall` switch on a package that is part of
the base deployment.
Closes: #1421
Approved by: jlebon
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
A bunch of commands had descriptions for `--reboot` that were copied
from the `upgrade` description. Let's just make them all the same to
keep it consistent.
Closes: #1418
Approved by: cgwalters
Minor tweaks to try to clarify that the `install` and `uninstall`
commands are for managing an overlay. This should hopefully make it less
likely that someone tries `uninstall` when really they want
`override remove`.
Also drop the paragraph about having to specify NEVRAs for removing
local RPMs since that's no longer necessary.
Closes: #1418
Approved by: cgwalters
Fewer variables and avoid extra strdupv calls. I also fixed
handling of refspec canonicalization that I broke with a previous
change (we weren't actually setting `self->refspec` to the canonicalized
version).
Closes: #1414
Approved by: jlebon
I was surprised when I fired up GDB and found out that my
`etc-group-members` modifications weren't being obeyed. It turns out
serde was looking for the wrong field name. I did a quick sanity check
and found a few others.
Closes: #1417
Approved by: cgwalters
I think this is what's showing up in a PR test:
21b68a68ff.2.1529072619059542132/artifacts/vmcheck/livefs.log
```
(rpm-ostree status:17017): Json-CRITICAL **: json_gvariant_serialize: assertion 'variant != NULL' failed
```
It shouldn't be happening; let's add an assertion which will give us a core
dump reliably instead of the "stumble on" `g_warning()` default.
Closes: #1416
Approved by: jlebon
It's just all-around simpler if we only parse the vardict
and avoid exploding everything into enums/parameters. Previously
we were converting the variant into parameters and flags, and
then in most cases converting the flags back into booleans!
This should make it easier to add new parameters.
Closes: #1412
Approved by: jlebon
We are having exact same function call between rpmostree_check_groups
and rpmostree_check_passwd, which means we are ignoring all the logic
for group checking.
This commit changes the option `passwd` to FALSE to also check for groups
during compose process.
Closes: #1413
Approved by: cgwalters
Minor regression from #1382. Since we no longer always include all the
option keys, we actually need to initialize the default values now.
Closes: #1410Closes: #1411
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
We were also counting the `NULL` element we added at the end of the
array when appending how many local installs we were doing. Fix this by
just reading the array length before adding the `NULL` terminator.
Closes: #1407
Approved by: cgwalters
We were previously relying on `!self->revision` to determine what
message to print in the no-op case. This made `override reset --all`
also print `No upgrade available.`.
Fix this by using the stronger `is_upgrade` instead.
Closes: #1407
Approved by: cgwalters
We were labeling pure `uninstall` transactions as `install`. Tease out
that distinction. (Though if a `--install` switch is passed, then we
still just label it as `install` -- there's no difference between that
and `install --uninstall` anyway).
Closes: #1407
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
Follow to previous change; this should make it easier to add
a new parameter. It also just makes more sense to centralize
the parsing here.
Closes: #1403
Approved by: jlebon
Subsequent patches will move it down farther; the high level
goal is to avoid touching many functions to add a parameter.
Closes: #1403
Approved by: jlebon
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
We were missing a bunch of flags as part of the property GType. I was
getting a warning that's become fatal because we set
`G_DEBUG=fatal-warnings` for `make vmsync`, which is how I was testing
this:
```
rpm-ostree[1813]: value "((RpmOstreeSysrootUpgraderFlags) 48)" of type 'RpmOstreeSysrootUpgraderFlags' is invalid or out of range for property 'flags' of type 'RpmOstreeSysrootUpgraderFlags'
kernel: traps: pool[1816] trap int3 ip:7f47f4b4b6d5 sp:7f47e989d1f0 error:0 in libglib-2.0.so.0.5600.1[7f47f4af9000+115000]
```
I'm not quite sure why this is happening now though, since I use
`make vmsync` a lot. My guess would be something to do with how we
changed flag passing in d568e54d from "all of them" to "only those we
need", but I didn't verify that.
Closes: #1398
Approved by: cgwalters
