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.

Bug 1961843

Summary: leapp fails when connected to Satellite with SCA content if system language is not english
Product: Red Hat Enterprise Linux 7 Reporter: Ryan Mullett <rmullett>
Component: leapp-repositoryAssignee: Leapp team <leapp-notifications>
Status: CLOSED DUPLICATE QA Contact: Alois Mahdal <amahdal>
Severity: medium Docs Contact:
Priority: low    
Version: 7.9CC: fkrska, jcastran, leapp-notifications, mreznik, pstodulk
Target Milestone: rcFlags: pm-rhel: mirror+
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2021-10-06 10:54:19 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On:    
Bug Blocks: 1818088    

Description Ryan Mullett 2021-05-18 19:45:02 UTC
Description of problem:
Because leapp specifically looks for the following SCA_TEXT it is not compatible with systems that don't have english as the system language during the upgrade when the content on the Satellite is SCA content.

    SCA_TEXT = "Content Access Mode is set to Simple Content Access"

Version-Release number of selected component (if applicable):
leapp-0.12.0-1.el7_9.noarch

How reproducible:
Always

Steps to Reproduce:
1. Have a Satellite with SCA content.
2. Set LANG=fr_FR.UTF-8
3. Try to leapp upgrade using the system with french language connected to a Satellite with SCA content

Actual results:
Upgrade has been inhibited due to the following problems:
    1. Inhibitor: The system is not registered or subscribed.
Consult the pre-upgrade report for details and possible remediation

Expected results:
leapp should be language agnostic. 

Additional info:
Here's the exact sections that are an issue. Note that SCA_TEXT is the specific output that you would get on an English system, but subscription-manager will not output this text on a system with a different language:

===============================================================================================================================

~~~~~~~~~~~~~~~~
  # cat actors/checkrhsmsku/libraries/checkrhsmsku.py
    from leapp import reporting
    from leapp.libraries.common import rhsm
    from leapp.libraries.stdlib import api
    from leapp.models import RHSMInfo
    from leapp.reporting import create_report

    SCA_TEXT = "Content Access Mode is set to Simple Content Access"

    def process():
        if not rhsm.skip_rhsm():
            for info in api.consume(RHSMInfo):
                if not info.attached_skus and not info.sca_detected:
                    create_report([
                        reporting.Title('The system is not registered or subscribed.'),
                        reporting.Summary(
                            'The system has to be registered and subscribed to be able to proceed'
                            ' with the upgrade, unless the --no-rhsm option is specified when'
                            ' executing leapp.'
                        ),
                        reporting.Severity(reporting.Severity.HIGH),
                        reporting.Tags([reporting.Tags.SANITY]),
                        reporting.Flags([reporting.Flags.INHIBITOR]),
                        reporting.Remediation(
                            hint='Register your system with the subscription-manager tool and attach'
                                 ' proper SKUs to be able to proceed the upgrade or use the --no-rhsm'
                                 ' leapp option if you want to provide target repositories by yourself.'),
                        reporting.RelatedResource('package', 'subscription-manager')
                    ])

~~~~~~~~~~~~~~~~
  # cat libraries/rhsm.py

    @with_rhsm
    def get_rhsm_status(context):
        """
        Retrieve "subscription-manager status" output.

        :param context: An instance of a mounting.IsolatedActions class
        :type context: mounting.IsolatedActions class
        :return: "subscription manager status" output
        :rtype: String
        """
        with _handle_rhsm_exceptions():
            result = context.call(['subscription-manager', 'status'])
            return result['stdout']

    def is_manifest_sca(context):
        """
        Check if SCA manifest is used in Satellite.

        :param context: An instance of a mounting.IsolatedActions class
        :type context: mounting.IsolatedActions class
        :return: True if SCA manifest is used else False
        :rtype: Boolean
        """
        return SCA_TEXT in get_rhsm_status(context)

Comment 2 Petr Stodulka 2021-05-19 07:22:56 UTC
Hi Ryan, thanks for the feedback. Currently this is expected behaviour which can be observed only when user does not follow required steps described in the official upgrade documentation:
  ..Ensure you have the system locale set to en_US.UTF-8:..."

See the chapter "Preparing a RHEL 7 system for the upgrade"
https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/8/html-single/upgrading_from_rhel_7_to_rhel_8/index

As a workaround, user can do e.g.
  # export LC_ALL="en_US.UTF-8"
  # leapp preupgrade

But we agree we could fix the leapp to ,ensure the correct locale is set' / to set the correct locale in the application. So keeping this opened.

Comment 3 Ryan Mullett 2021-05-19 19:49:55 UTC
(In reply to Petr Stodulka from comment #2)
> Hi Ryan, thanks for the feedback. Currently this is expected behaviour which
> can be observed only when user does not follow required steps described in
> the official upgrade documentation:
>   ..Ensure you have the system locale set to en_US.UTF-8:..."
> 
> See the chapter "Preparing a RHEL 7 system for the upgrade"
> https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/8/
> html-single/upgrading_from_rhel_7_to_rhel_8/index
> 
> As a workaround, user can do e.g.
>   # export LC_ALL="en_US.UTF-8"
>   # leapp preupgrade
> 
> But we agree we could fix the leapp to ,ensure the correct locale is set' /
> to set the correct locale in the application. So keeping this opened.

I had missed this because I only checked known limitations for mention of it. Is it possible we can also mention it in the known limitations while the bug is being worked on?

Comment 4 Petr Stodulka 2021-05-20 12:54:24 UTC
This is not good idea from my POV as we could tell that about bunch of other stuff (like remove version-locking for rpms if set anything, etc). It's expected to go through the instructions (there is more stuff expected from customer to check & do prior the run of `leapp`; e.g. imagine that user does not stop or reconfigure the configuration management services before the upgrade...) when people want to upgrade to the new system. It really doesn't make sense to be honest to duplicate big part of the document.

Comment 5 Ryan Mullett 2021-05-20 16:28:42 UTC
(In reply to Petr Stodulka from comment #4)
> This is not good idea from my POV as we could tell that about bunch of other
> stuff (like remove version-locking for rpms if set anything, etc). It's
> expected to go through the instructions (there is more stuff expected from
> customer to check & do prior the run of `leapp`; e.g. imagine that user does
> not stop or reconfigure the configuration management services before the
> upgrade...) when people want to upgrade to the new system. It really doesn't
> make sense to be honest to duplicate big part of the document.

By definition the fact that leapp is not compatible with locale other than english it is a known limitation of leapp and should be documented as such. As I mentioned previously, when looking at this my first response was to check known limitations and see if english was a requirement, and I did not see it mentioned in that section where I expected it. Of course it's listed in the steps, but it is by definition a known limitation.

Comment 6 jcastran 2021-05-20 16:43:49 UTC
Since leapp detects other pre-requisite steps that are required and marks them as an inhibitor, can we add a check for this as well?

Currently the message of you are not registered, while being registered, doesn't really make it clear what the problem was. 

It would be great if it would just change the setting, or run in a shell with the required locale. But I suspect we need it configured permanently in /etc/locale.conf in which case, it should be a preupgrade check and inhibitor.

Comment 7 Petr Stodulka 2021-05-20 16:58:57 UTC
Kind of I think we can easily resolve it just by setting the LC_ALL inside leapp when running instead of inhibitor in this case (kind of the inhibitor doesn't have to be helpful when it's between other reports and user will read just the first one..)

Ryan: it depends on the POV. I would not say that known limitation that user cannot run nor install leapp on RHEL 7.1 is expected to be in the list as well. What is set as an expectation, should not be in the list of known limitations. In a case we should consider these "requriements" to be "known limitations", we can really expect in such a case x-time bigger list, which will not be helpful. Would it help to write something like: ,,before you read the known limitations when you hit a problem, ensure you read chapter 2 (or the whole document) before you started to use leapp"? I really want to be sure, that we will not copy&paste all the stuff from chapter 2 in time.

Comment 8 Petr Stodulka 2021-06-09 17:04:20 UTC
*** Bug 1953622 has been marked as a duplicate of this bug. ***

Comment 11 Michal Reznik 2021-10-06 10:54:19 UTC

*** This bug has been marked as a duplicate of bug 1892368 ***