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:
It seems that there is a change of behaviour in what glibc langpack is installed on RHEL-9 and RHEL-8 in a slightly specific scenario, miniminal packageset installation with only BaseOS repo provided, is it expected?
When doing a new installation of RHEL-9, providing only BaseOS repo and selecting minimal packageset, glibc-minimal-langpack is installed.
[root@localhost ~]# rpm -qa glibc*
glibc-minimal-langpack-2.33-10.el9.x86_64
glibc-common-2.33-10.el9.x86_64
glibc-2.33-10.el9.x86_64
And only C.UTF-8 is available as a locale
[root@localhost ~]# localectl list-locales
C.UTF-8
Even though based on installation the locale set on the system is en_US.UTF-8, but that is not available
[root@localhost ~]# locale
locale: Cannot set LC_CTYPE to default locale: No such file or directory
locale: Cannot set LC_MESSAGES to default locale: No such file or directory
locale: Cannot set LC_ALL to default locale: No such file or directory
LANG=en_US.UTF-8
LC_CTYPE="en_US.UTF-8"
LC_NUMERIC="en_US.UTF-8"
LC_TIME="en_US.UTF-8"
LC_COLLATE="en_US.UTF-8"
LC_MONETARY="en_US.UTF-8"
LC_MESSAGES="en_US.UTF-8"
LC_PAPER="en_US.UTF-8"
LC_NAME="en_US.UTF-8"
LC_ADDRESS="en_US.UTF-8"
LC_TELEPHONE="en_US.UTF-8"
LC_MEASUREMENT="en_US.UTF-8"
LC_IDENTIFICATION="en_US.UTF-8"
LC_ALL=
in comparison, the same scenario on RHEL-8 results in glibc-all-langpacks being installed and en_US.UTF-8 being available and set as a locale.
[root@localhost ~]# rpm -qa glibc*
glibc-common-2.28-151.el8.x86_64
glibc-all-langpacks-2.28-151.el8.x86_64
glibc-2.28-151.el8.x86_64
I realize that installation only from BaseOS repo is not a customer-supported scenario but it could affect some testing. For example I have stumbled upon it while testing in beaker with using 'sort' in a test. With kickstart snippet provided to beaker recipe, the installation is set just from specified variant, and so the installation is done just from BaseOS and the test then fails due to different sort output for C.UTF-8 and en_US.UTF-8 since en_US.UTF-8 is not available. This is not something that can't be easily fixed on our side, but I would like to know if the change in behaviour is expected or is actually a bug.
Version-Release number of selected component (if applicable):
Tested with RHEL-9.0.0-20210506.3 and glibc-2.33-10.el9
Would you please provide additional information about the installation method? The glibc-langpack-* packages are part of BaseOS, so this is probably not the result of something that glibc is doing.
Yes the installation selected the en_US.utf8
looking in the anaconda.log I can see:
12:27:38,608 INF installation: Task started: Find additional packages & run pre_install() (9/40)
12:27:38,647 WRN modules.payloads.payload.dnf.requirements: Selected locale 'en_US.UTF-8' does not match any available langpacks.
Thanks. I'm reassigning this to anaconda for further analysis/comments. I think it makes sense to switch to the C.UTF-8 locale for minimal installs because nothing else is available.
(In reply to Jiri Konecny from comment #8)
> Do I understand it correctly that Anaconda should fall-back in this case to
> C.UTF-8? If yes, we should change this on RHEL-9 but also on Fedora.
Yes, that's what I had in mind. And I expect that Fedora would benefit from it, too.
From a UI point of view, it is a bit unfortunate that the locale is selected before the installation scope is selected. But hopefully that can be solved.
Just a note, if we are not able to run locale -a in the chroot of the installed system, we are not able to determine whether the requested locale is supported. I suggest to install the requested locale instead of C.UTF-8 in that case. Otherwise, it would change the current behaviour.