Note: This bug is displayed in read-only format because
the product is no longer active in Red Hat Bugzilla.
RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Description of problem:
I have a situation where rpm-ostree gets confused on which remote it should be
using. If I register a system using subscription manager and then rebase it onto
some other tree, then perform an upgrade the system is totally confused about
what remote it should be using. The version of rpm-ostree I was using was
rpm-ostree-client-2015.5-3.atomic.el7.x86_64 which was composed into my test
tree. Here is the worked out example:
*Initial Setup*
===============
-bash-4.2# rpm-ostree status
TIMESTAMP (UTC) VERSION ID OSNAME REFSPEC
* 2015-04-02 20:14:06 7.1.1-1 21bd99f9f3 rhel-atomic-host rhel-atomic-host:rhel-atomic-host/7/x86_64/standard
-bash-4.2#
-bash-4.2#
-bash-4.2# ls /etc/ostree/remotes.d/
-bash-4.2# subscription-manager register --auto-attach
Username: XXXXX
Password:
The system has been registered with ID: 8e26062d-c1e7-42d1-b0a7-10da70f88a6c
Installed Product Current Status:
Product Name: Red Hat Enterprise Linux Atomic Host
Status: Subscribed
Product Name: Red Hat Enterprise Linux Server
Status: Subscribed
-bash-4.2# ls /etc/ostree/remotes.d/
redhat.conf
*Rebasing*
==========
-bash-4.2# ostree remote add lab --set=gpg-verify=false http://192.168.122.121:8000/repo
-bash-4.2# rpm-ostree rebase lab:goodtree
568 metadata, 2724 content objects fetched; 173996 KiB transferred in 82 secondsCopying /etc changes: 25 modified, 4 removed, 58 added
Transaction complete; bootconfig swap: yes deployment count change: 1
Deleting ref 'rhel-atomic-host-ostree:rhel-atomic-host/7/x86_64/standard'
Changed:
...
...
-bash-4.2# reboot
*Upgrading*
==============
-bash-4.2# rpm-ostree status
TIMESTAMP (UTC) VERSION ID OSNAME REFSPEC
* 2015-05-25 02:27:05 7e4135eeb5 rhel-atomic-host lab:goodtree
2015-04-02 20:14:06 7.1.1-1 21bd99f9f3 rhel-atomic-host rhel-atomic-host-ostree:rhel-atomic-host/7/x86_64/standard
-bash-4.2# rpm-ostree upgrade
Updating from: lab:goodtree
51 metadata, 60 content objects fetched; 112700 KiB transferred in 9 seconds
Copying /etc changes: 25 modified, 4 removed, 60 added
Transaction complete; bootconfig swap: yes deployment count change: 0
Changed:
...
...
Upgrade prepared for next boot; run "systemctl reboot" to start a reboot
-bash-4.2#
-bash-4.2# rpm-ostree status
TIMESTAMP (UTC) ID OSNAME REFSPEC
2015-05-27 01:42:42 559d5f3d7b rhel-atomic-host lab:goodtree
* 2015-05-25 02:27:05 7e4135eeb5 rhel-atomic-host rhel-atomic-host-ostree:goodtree
-bash-4.2# reboot
*After Reboot*
==============
-bash-4.2# rpm-ostree status
TIMESTAMP (UTC) ID OSNAME REFSPEC
* 2015-05-27 01:42:42 559d5f3d7b rhel-atomic-host rhel-atomic-host-ostree:goodtree
2015-05-25 02:27:05 7e4135eeb5 rhel-atomic-host rhel-atomic-host-ostree:goodtree
-bash-4.2# rpm-ostree upgrade
Updating from: rhel-atomic-host-ostree:goodtree
error: Server returned status 404: Not Found
Version-Release number of selected component (if applicable):
rpm-ostree-client-2015.5-3.atomic.el7.x86_64
How reproducible:
Always
Steps to Reproduce:
See description.
My best guess here is the subscription manager daemon `rhsmcertd` is coming in and overwriting things.
Try:
systemctl stop rhsmcertd
systemctl mask rhsmcertd
?
(In reply to Colin Walters from comment #2)
> My best guess here is the subscription manager daemon `rhsmcertd` is coming
> in and overwriting things.
>
> Try:
> systemctl stop rhsmcertd
> systemctl mask rhsmcertd
>
> ?
At what point in the process (the one described in the description) do you want those two commands to be run?
(In reply to Colin Walters from comment #2)
> My best guess here is the subscription manager daemon `rhsmcertd` is coming
> in and overwriting things.
>
> Try:
> systemctl stop rhsmcertd
> systemctl mask rhsmcertd
>
> ?
That seems to work if I disable/mask rhsmcertd right after I run *subscription-manager register --auto-attach*.
One thing that might be of interest is that I see these denials when I run *subscription-manager register --auto-attach*:
[ 125.083645] type=1400 audit(1433086915.767:5): avc: denied { write } for pid=9505 comm="rhsmcertd-worke" name=".dbenv.lock" dev="dm-0" ino=4199789 scontext=system_u:system_r:rhsmcertd_t:s0 tcontext=system_u:object_r:usr_t:s0 tclass=file
[ 219.084882] type=1400 audit(1433087009.767:6): avc: denied { write } for pid=9505 comm="rhsmcertd-worke" name="21bd99f9f37727358454866bf4f0d51fe53c2f03fc74f2e69c75cbef0383a3f1.0.origin" dev="dm-0" ino=4199523 scontext=system_u:system_r:rhsmcertd_t:s0 tcontext=system_u:object_r:usr_t:s0 tclass=file
[ 220.419414] type=1400 audit(1433087011.102:7): avc: denied { write } for pid=9513 comm="rhsmcertd-worke" name=".dbenv.lock" dev="dm-0" ino=4199789 scontext=system_u:system_r:rhsmcertd_t:s0 tcontext=system_u:object_r:usr_t:s0 tclass=file
[ 225.179294] type=1400 audit(1433087015.863:8): avc: denied { write } for pid=9513 comm="rhsmcertd-worke" name="21bd99f9f37727358454866bf4f0d51fe53c2f03fc74f2e69c75cbef0383a3f1.0.origin" dev="dm-0" ino=4199523 scontext=system_u:system_r:rhsmcertd_t:s0 tcontext=system_u:object_r:usr_t:s0 tclass=file
I need a bit of clarification on the use case here. This comment might be more appropriate for the RFE bz above but nevertheless I will place it here.
What use case is being tested here? It seems the subscription manager ostree plugin assumes the only valid configurations for remotes will be in '/etc/ostree/remotes.d/redhat.conf'. Is there a valid use case in this bug that is not covered by the RFE?
Is it expected and valid to add a remote not included in an entitlement cert and rebase off said remote?
If the answer to the above is 'no' I will close this bug in favor of the RFG bug 1378495
Thank you in advance for your response.
Hey Chris,
I don't know the answers to your questions. Is rebasing something that needs to be supported? Maybe? I guess that depends on if we ever offer different trees to our customers.
I think what I was trying to report here is a situation where the software is behaving in a way it shouldn't. Upstream rpm-ostree has a feature that allows you to rebase to another tree, and in the case I outlined above I rebased to a different tree, did an upgrade, and then it no longer knows how to contact the remote.
I was just trying to report the issue, as there is some bug here (or was at the time I was trying this out).
This works as designed. Switching from a tree that was provided by a subscription to a tree that was added through some other means is unsupported. For any parties interested in that functionality please refer to bug 1378495 as the work to support that functionality will be completed there.