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 1958876 - anaconda: Minimal installation should set locale to C.UTF-8
Summary: anaconda: Minimal installation should set locale to C.UTF-8
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Red Hat Enterprise Linux 9
Classification: Red Hat
Component: anaconda
Version: 9.0
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: beta
: 9.0 Beta
Assignee: Vendula Poncova
QA Contact: Release Test Team
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2021-05-10 11:07 UTC by Petr Zatko
Modified: 2021-12-07 21:23 UTC (History)
10 users (show)

Fixed In Version: anaconda-34.25.0.9-1.el9
Doc Type: No Doc Update
Doc Text:
Clone Of:
Environment:
Last Closed: 2021-12-07 21:20:54 UTC
Type: Bug
Target Upstream Version:
Embargoed:
pm-rhel: mirror+

Attachments (Terms of Use)

Description Petr Zatko 2021-05-10 11:07:10 UTC 
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
Comment 1 Florian Weimer 2021-05-10 11:22:06 UTC 
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.
Comment 4 Petr Zatko 2021-05-10 11:59:06 UTC 
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.
Comment 5 Florian Weimer 2021-05-10 12:58:51 UTC 
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.
Comment 7 Florian Weimer 2021-06-10 05:22:14 UTC 
I believe not installing weak dependencies is a deliberate result of choosing a minimal install, with bug 1331100 fixed.
Comment 8 Jiri Konecny 2021-06-10 14:00:03 UTC 
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.
Comment 9 Florian Weimer 2021-06-10 14:25:31 UTC 
(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.
Comment 11 Vendula Poncova 2021-06-17 17:01:56 UTC 
Fixed in this pull request: https://github.com/rhinstaller/anaconda/pull/3450
Comment 12 Vendula Poncova 2021-06-18 10:46:11 UTC 
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.
Comment 17 Jan Stodola 2021-08-11 16:27:21 UTC 
Moving to VERIFIED based on Radek's testing in comment 16.
Note You need to log in before you can comment on or make changes to this bug.