Hide Forgot
Description of problem: ostree changes the remote after an upgrade attempt when the local deployments contain multiple ostree remotes. Version-Release number of selected component (if applicable): ostree-2016.1-2.atomic.el7.x86_64 rpm-ostree-client-2015.11-1.atomic.el7.1.x86_64 How reproducible: Everytime Steps to Reproduce: cp /etc/ostree/remotes.d/redhat.conf /etc/ostree/remotes.d/local.conf change first line to [remote "local"] vi /etc/ostree/remotes.d/local.conf #rebase rpm-ostree rebase local: #reboot shutdown -r now # shows everything normal ostree admin status # Nothing should change here if you started up to date. ostree admin upgrade # shows wrong remote on booted deployment ostree admin status Actual results: ostree changes the remote from local to rhel-atomic-host-ostree after an upgrade attempt. Expected results: Remote should stay local after upgrade attempt. Additional info:
This doesn't seem to happen with 2015.11
Oh, I see. Yes...the semantics here are confusing. The current way ostree is designed is that when you do the `rebase` operation, you're setting the origin for the new deployment. Your current origin is not changed. `ostree admin upgrade` (and generally all operations) will only look at the currently booted system. It happens to not redownload anything because we already got that commit, but the not-booted new deployment is just trashed. Another way to look at this is, do `rpm-ostree rebase local:` again before the reboot and see it flip back. So...is this a bug? Changing things here would have large design implications...my inclination is not to try to do anything here (other than docs). Do you have a use case for this?
The rebase part was just to get the deployment list in the right state. I did reboot after the rebase. So the 'local' deployment was the booted deployment after the reboot completed. After the rebase reboot ostree admin status says: * rhel-atomic-host 8b2cf24b420d659179dc866eab1bb341748839204ba56ed46a86218010789e91.1 Version: 7.2.2-2 origin refspec: local:rhel-atomic-host/7/x86_64/standard rhel-atomic-host 8b2cf24b420d659179dc866eab1bb341748839204ba56ed46a86218010789e91.0 Version: 7.2.2-2 origin refspec: rhel-atomic-host-ostree:rhel-atomic-host/7/x86_64/standard Then you run ostree admin upgrade, this outputs: No update available. Nothing is changed but the origin for the booted deployment was changed and ostree admin status now says: * rhel-atomic-host 8b2cf24b420d659179dc866eab1bb341748839204ba56ed46a86218010789e91.1 Version: 7.2.2-2 origin refspec: rhel-atomic-host-ostree:rhel-atomic-host/7/x86_64/standard rhel-atomic-host 8b2cf24b420d659179dc866eab1bb341748839204ba56ed46a86218010789e91.0 Version: 7.2.2-2 origin refspec: rhel-atomic-host-ostree:rhel-atomic-host/7/x86_64/standard
Turns out this was caused by rhsmcertd messing with the configurations. This is IMO not a great place to be, but not also not a ostree bug. I'll close this until I figure out where to refile.
Oh yes, right =( See https://bugzilla.redhat.com/show_bug.cgi?id=1117420 which is related to this. I think we're going to have to coordinate better with subman somehow. Adding Adrian to CC. Let's open a different bug though, possibly on github?