ERROR:src/app/rpmostree-libbuiltin.c:83:rpmostree_print_treepkg_diff: assertion failed: (deployments->len > 1) #981
Assignees
Comments
|
Hmm, interesting. Will try to reproduce this. |
|
Try this:
|
jlebon
added a commit
to jlebon/rpm-ostree
that referenced
this issue
Sep 11, 2017
Currently, when setting the `override-commit` key in the origin, the upgrader pulls that commit checksum directly and then updates the refspec to point to it. This behaviour was inherited from its ostree version; at the time it was implemented, the pull code didn't support passing a specific commit for a given refspec. However, we now have the override-commit-ids option, which will make libostree update the ref for us. We change the code here to make use of it and simplify the function. This also fixes the corner case of local branches: we shouldn't change the ref if we're on a local branch. This is actually what drove me to this patch as I was debugging coreos#981. (Aside: I'm still not convinced updating the refspec is always the correct thing to do even in the remote case, though it's a bit messy to disentangle).
jlebon
added a commit
to jlebon/rpm-ostree
that referenced
this issue
Sep 11, 2017
Also something I noticed while working on coreos#981. When sitting on a livefs commit, once a user does `rpm-ostree cleanup --pending --rollback`, it's impossible to redeploy the same booted commit. Let's allow users to do this.
jlebon
added a commit
to jlebon/rpm-ostree
that referenced
this issue
Sep 11, 2017
Commands like `upgrade` and `deploy` need to know if a new deployment was actually laid down so that it may print a pkg diff if so. This is implemented by listening for changes to the DefaultDeployment D-Bus property. D-Bus emits a signal when the deployment variant changes value. However, in coreos#595, with the introduction of `pending-*` related keys, the deployment variant no longer represents data solely tied to that specific deployment. In this case, because `deploy` operations currently set the ref to the resolved checksum, it can happen that deploying the same base commit when the current refspec *isn't* pointing to that base commit will result in the `pending-*` keys dropping out and a default deployment change notification going out. In this patch, we strengthen how we determine whether a new deployment was laid down by actually looking at the deployment id, rather than just assuming that a change to the property implies a new deployment. Closes: coreos#981
rh-atomic-bot
pushed a commit
that referenced
this issue
Sep 12, 2017
Currently, when setting the `override-commit` key in the origin, the upgrader pulls that commit checksum directly and then updates the refspec to point to it. This behaviour was inherited from its ostree version; at the time it was implemented, the pull code didn't support passing a specific commit for a given refspec. However, we now have the override-commit-ids option, which will make libostree update the ref for us. We change the code here to make use of it and simplify the function. This also fixes the corner case of local branches: we shouldn't change the ref if we're on a local branch. This is actually what drove me to this patch as I was debugging #981. (Aside: I'm still not convinced updating the refspec is always the correct thing to do even in the remote case, though it's a bit messy to disentangle). Closes: #984 Approved by: cgwalters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Using Fedora 26 AH (26.120), I was able to get
rpm-ostreeto dump core while doing anrpm-ostree deploy.I don't have a solid reproducer, as the host I was working on had gone through a lot of operations. I think I was in a weird state with two initial deployments, where the booted deployment had a pending commit that matched the rollback deployment. I'll just copy a bunch of details below.
The text was updated successfully, but these errors were encountered: