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:
Customer uses an HTTP proxy for their environment. They regularly use the "--proxy" option when executing subscription-manager commands.
Upon testing a RHEL 7.6 to RHEL8 beta leapp upgrade, they got this fatal error:
2019-03-10 19:46:27.196 INFO PID: 30183 leapp.workflow.Download: Executing actor prepare_upgrade_transaction
Process Process-65:
Traceback (most recent call last):
File "/usr/lib64/python2.7/multiprocessing/process.py", line 258, in _bootstrap
self.run()
File "/usr/lib64/python2.7/multiprocessing/process.py", line 114, in run
self._target(*self._args, **self._kwargs)
File "/usr/lib/python2.7/site-packages/leapp/repository/actor_definition.py", line 59, in _do_run
target_actor(logger=logger, messaging=messaging).run(*args, **kwargs)
File "/usr/lib/python2.7/site-packages/leapp/actors/__init__.py", line 228, in run
self.process(*args)
File "/usr/share/leapp-repository/repositories/system_upgrade/el7toel8/actors/prepareupgradetransaction/actor.py", line 234, in process
prev_rhsm_release = preparetransaction.call(['subscription-manager', 'release'])[0]
File "/usr/share/leapp-repository/repositories/system_upgrade/el7toel8/actors/prepareupgradetransaction/libraries/preparetransaction.py", line 67, in call
r = subprocess.check_output(args, stderr=err).decode('utf-8')
File "/usr/lib64/python2.7/subprocess.py", line 575, in check_output
raise CalledProcessError(retcode, cmd, output=output)
CalledProcessError: Command '['subscription-manager', 'release']' returned non-zero exit status 1
It did this because leapp has no way of knowing about the proxy. Thus, when it runs "subscription-manager release", it exits with non-zero exit code "Errno -2".
Version-Release number of selected component (if applicable):
leapp-0.5.0-1.el7_6.noarch
How reproducible:
Try to run leapp on a machine that must use a HTTP proxy for connectivity.
Additional info:
I'm not sure whether this should really be considered a bug, or not. Perhaps it is just something we need to make clear in the leapp documentation.
I see in "man subscription-manager" that one can set proxy values in /etc/rhsm/rhsm.conf so that one is not constantly adding the "--proxy" option to one's subscription-manager commands. This may be the way we instruct users to handle this situation instead of programming in proxy capabilities to leapp.
Not sure about that. Assigning to Chris Snyder from RHSM team who are responsible for subscription-manager part of upgrades.
Comment 3Vinzenz Feenstra [evilissimo]
2019-03-15 21:32:34 UTC
Bernie, is there any reason the customer cannot configure the proxy in the rhsm.conf? Or did they do that? If it would be in the RHSM conf, it shouldn't fail then AFAIK.
Comment 4Vinzenz Feenstra [evilissimo]
2019-03-15 21:34:16 UTC
Bernie, nevermind, just noticed you added the KB. Sorry for the noise.
It appears to me that this is a bug in Leapp not subscription-manager. Unless Leapp will be modified to pass a well-formed "--proxy" option to subscription-manager, the solution in the attached KB will be our only solution. My team is not responsible for any of the Leapp code, as such I'm reassigning this to the default for leapp-repository.
If you have any questions during implementation that the RHSM client tools team can help with please let me know.
We have documented this issue in https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/8/html-single/upgrading_from_rhel_7_to_rhel_8/index:
"
If you use an HTTP proxy, Red Hat Subscription Manager must be configured to use such a proxy, or the subscription-manager command must be executed with the --proxy <hostname> option. Otherwise, an execution of the subscription-manager command fails. If you use the --proxy option instead of the configuration change, the upgrade process fails because Leapp is unable to detect the proxy. To prevent this problem from occurring, manually edit the rhsm.conf file as described in How to configure HTTP Proxy for Red Hat Subscription Management.
"
In our opinion that is sufficient. I'm closing the bug.
Description of problem: Customer uses an HTTP proxy for their environment. They regularly use the "--proxy" option when executing subscription-manager commands. Upon testing a RHEL 7.6 to RHEL8 beta leapp upgrade, they got this fatal error: 2019-03-10 19:46:27.196 INFO PID: 30183 leapp.workflow.Download: Executing actor prepare_upgrade_transaction Process Process-65: Traceback (most recent call last): File "/usr/lib64/python2.7/multiprocessing/process.py", line 258, in _bootstrap self.run() File "/usr/lib64/python2.7/multiprocessing/process.py", line 114, in run self._target(*self._args, **self._kwargs) File "/usr/lib/python2.7/site-packages/leapp/repository/actor_definition.py", line 59, in _do_run target_actor(logger=logger, messaging=messaging).run(*args, **kwargs) File "/usr/lib/python2.7/site-packages/leapp/actors/__init__.py", line 228, in run self.process(*args) File "/usr/share/leapp-repository/repositories/system_upgrade/el7toel8/actors/prepareupgradetransaction/actor.py", line 234, in process prev_rhsm_release = preparetransaction.call(['subscription-manager', 'release'])[0] File "/usr/share/leapp-repository/repositories/system_upgrade/el7toel8/actors/prepareupgradetransaction/libraries/preparetransaction.py", line 67, in call r = subprocess.check_output(args, stderr=err).decode('utf-8') File "/usr/lib64/python2.7/subprocess.py", line 575, in check_output raise CalledProcessError(retcode, cmd, output=output) CalledProcessError: Command '['subscription-manager', 'release']' returned non-zero exit status 1 It did this because leapp has no way of knowing about the proxy. Thus, when it runs "subscription-manager release", it exits with non-zero exit code "Errno -2". Version-Release number of selected component (if applicable): leapp-0.5.0-1.el7_6.noarch How reproducible: Try to run leapp on a machine that must use a HTTP proxy for connectivity. Additional info: I'm not sure whether this should really be considered a bug, or not. Perhaps it is just something we need to make clear in the leapp documentation. I see in "man subscription-manager" that one can set proxy values in /etc/rhsm/rhsm.conf so that one is not constantly adding the "--proxy" option to one's subscription-manager commands. This may be the way we instruct users to handle this situation instead of programming in proxy capabilities to leapp.