Bug 1186757 - Atomic Host only supports the en_US locale
Summary: Atomic Host only supports the en_US locale
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: rhel-server-atomic
Version: 7.0
Hardware: x86_64
OS: Linux
medium
medium
Target Milestone: rc
: ---
Assignee: Colin Walters
QA Contact: atomic-bugs@redhat.com
Yoana Ruseva
URL:
Whiteboard:
: 1166544 1302342 (view as bug list)
Depends On:
Blocks: 1186913 1420851 1268897 1350975 1399379
TreeView+ depends on / blocked
 
Reported: 2015-01-28 13:39 UTC by Jeremy Harris
Modified: 2019-11-14 06:36 UTC (History)
18 users (show)

Fixed In Version:
Doc Type: Known Issue
Doc Text:
Red Hat Enterprise Linux Atomic Host only supports the en_US.UTF-8 locale During installation, if you select a language other than American English as the default keyboard type, it is not reflected in the installed system afterwards. The locale is still set to `en_US` and error messages about locales missing are displayed. This could be problematic for programs that require other locales, or, for example, when you have a password in another language, the system will not recognize it.
Clone Of:
Environment:
Last Closed: 2017-05-03 16:59:03 UTC
Target Upstream Version:


Attachments (Terms of Use)


Links
System ID Priority Status Summary Last Updated
Red Hat Bugzilla 1235726 'medium' 'CLOSED' 'installer should not present unsupported languages' 2019-11-29 21:30:43 UTC
Red Hat Knowledge Base (Solution) 1562963 None None None Never

Internal Links: 1235726

Description Jeremy Harris 2015-01-28 13:39:36 UTC
Description of problem:

 Login (as root) after install from ISO then initial upgrade. Errors from
bash "setlocale: LC_CTYPE: cannot change locale (en_GB.UTF-8): no such file or directory".

Ditto for LC_COLLATE, ~MESSAGES, ~NUMERIC, ~TIME.
No LC_* in `env`.


Version-Release number of selected component (if applicable):

 "atomic status" shows 7.0.1 active, 7.0.0 also present.


How reproducible:

 Not tried.


Steps to Reproduce:
1. Install as VM from ISO; english/UK (but with only a US keyboard choice forced)
2. subscription-manager registration as employee
3. atomic update
4. sysemctl reboot
5. log in as root

Actual results:
 Error messages

Expected results:
 No error messages

Additional info:
 F21 host for VM.  VM created via gui, type RHEL7.0, 8GB qcow2, 4GB memory.

Comment 2 Colin Walters 2015-01-28 14:32:36 UTC
Atomic hosts currently only include en_US.   There is no mechanism at present to extend the locale set post-installation.

This would require downstreams to create custom composes.

Comment 3 Jeremy Harris 2015-01-28 14:41:54 UTC
Additional: after a rollback to 7.0.0 there are no errors on a root login.
There are still no LC_* environment variables.

Comment 4 Colin Walters 2015-03-09 15:33:51 UTC
*** Bug 1166544 has been marked as a duplicate of this bug. ***

Comment 5 Colin Walters 2015-03-09 15:35:11 UTC
Future work may include non-US keyboard input but not translations.

Comment 8 Colin Walters 2015-05-04 13:21:34 UTC
One issue here is that ssh by default will propagate locale environment variables.  It might be nice to change ssh itself to detect whether a locale is available - Atomic is not the only system that comes locale-less.

That said it might be possible to tell ssh on atomic to always set en_US.UTF-8, but I'd prefer a solution in ssh as that would then support dynamic locale installation.

Comment 9 Micah Abbott 2015-06-23 18:44:47 UTC
This also affects the Centos Atomic rebuild that was recently released - http://lists.centos.org/pipermail/centos-devel/2015-June/013542.html

Comment 12 Christian Horn 2015-10-26 08:06:51 UTC
> During installation, if you select a language other than American English
> as the default keyboard type, it is not reflected in the installed system
> afterwards. The locale is still set to `en_US` and error messages about
> locales missing are displayed. This could be problematic for programs that
> require other locales, or for example when you have a password in another
> language, the system will not recognize it.
All correct, I think, just as a comment: having environment variables set to request a different locale does not require selecting at install.  I am using ja_JP.UTF-8 on my workplace system and these variables are by default also transferred into remote systems (ssh) and docker containers.

Comment 14 Subhendu Ghosh 2016-02-26 02:33:29 UTC
Jeremy - is it sufficient to disable alternate local selection on install for this BZ?

Comment 15 Jeremy Harris 2016-02-26 09:21:28 UTC
Yes, but only if there is a documented method for obtaining a specified locale.

Comment 16 Yoana Ruseva 2016-02-26 11:23:15 UTC
Is there a workaround for this issue that I can include in the release note?

Comment 17 Micah Abbott 2016-06-22 13:52:52 UTC
*** Bug 1302342 has been marked as a duplicate of this bug. ***

Comment 18 Daniel Walsh 2016-08-19 22:16:18 UTC
Any update on this?

Comment 19 Alexander Todorov 2016-09-15 11:09:17 UTC
This installer counterpart of this bug (rhbz#1235726) is now verified. Is there anything else to do/test here? If not how about we close it?

Comment 22 Colin Walters 2016-10-21 22:38:08 UTC
I think my vote is to add all the locales by default.  If we look at this from the axes of:

 1) General purpose, potentially single machine OS
 2) Clustered kube/other host

Locales are a case that are important in #1, but not #2.  I'm pushing for a model where Atomic Host works in #1 too.  The cost to the #2 case is relatively small.

Comment 23 Colin Walters 2016-10-21 22:44:11 UTC
This comes up in the Docker base image case as well obviously.  The calculus there is a bit different, but if we follow out the thread of the "centosmin" vs "centos" style, I'd say min would only have C.UTF-8, and centos would have systemd and all locales.

Comment 25 Jonathan Lebon 2016-10-27 13:47:43 UTC
(In reply to Colin Walters from comment #22)
> I think my vote is to add all the locales by default.

OK that works. I wasn't sure how hard we wanted to try to avoid shipping locales for the sake of size.

As a test, I just did a 7.3 tree compose in which we keep all the locales. The additional locales increase the size of the tree by almost exactly 100 MB. However, they compress to less than a quarter of that. So I'd expect the shipped qcow2 images, which are internally compressed, to increase by ~23 MB. Overall seems like an acceptable trade-off here given the benefits.

Should we target this for 7.3.1 or 7.3.2?

Comment 26 Daniel Walsh 2016-10-27 14:23:10 UTC
Has any thought be given to only shipping the "Supported" locales?  Can we do that?

Comment 27 Matthew Miller 2016-10-27 18:35:31 UTC
(In reply to Daniel Walsh from comment #26)
> Has any thought be given to only shipping the "Supported" locales?  Can we
> do that?

How much space does that save?

Comment 28 Jonathan Lebon 2016-10-27 18:42:48 UTC
(In reply to Daniel Walsh from comment #26)
> Has any thought be given to only shipping the "Supported" locales?  Can we
> do that?

I'm not familiar with what "Supported" means in that context. Is there a list of locales somewhere we consider supported?

Comment 29 Daniel Walsh 2016-10-27 19:01:02 UTC
Perhaps I am mistaken, I see Locales, and I am thinking languages.  But we currently support 22.  

Here is the RHEL6 list.

https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/6/html/6.6_Technical_Notes/ch-international_languages.html

Haven't figured out where the list is for RHEL7.

Comment 31 Jonathan Lebon 2016-10-27 19:45:15 UTC
OK, that brings it down to on-disk 8.9M and compressed 1.9M. So in other words, negligible. Not to mention it actually makes sense to support the same set other variants do.

Comment 33 Colin Walters 2016-10-28 13:01:57 UTC
Hum...but there's no such definition of "supported" locales for Fedora AFAICS.  I guess though we could take the same list, and say that any changes to it would require the same process as RHEL?

Comment 34 Jonathan Lebon 2016-11-09 22:03:19 UTC
OK, if we're ready to give this a try in Fedora, I created some PRs:

https://pagure.io/fedora-atomic/pull-request/30
https://pagure.io/fedora-atomic/pull-request/31

Comment 35 Jonathan Lebon 2016-11-15 21:21:02 UTC
On the latest rawhide tree compose:

-bash-4.3# localedef --list-archive
as_IN.utf8
bn_IN.utf8
de_DE.utf8
en_US.utf8
es_ES.utf8
fr_FR.utf8
gu_IN.utf8
hi_IN.utf8
it_IT.utf8
ja_JP.utf8
kn_IN.utf8
ko_KR.utf8
ml_IN.utf8
mr_IN.utf8
or_IN.utf8
pa_IN.utf8
pt_BR.utf8
ru_RU.utf8
ta_IN.utf8
te_IN.utf8
zh_CN.utf8
zh_TW.utf8
-bash-4.3# LANG=fr_FR.utf8 date
mar. nov. 15 20:36:57 UTC 2016
-bash-4.3# LANG=ru_RU.utf8 date
Вт ноя 15 21:16:52 UTC 2016

Comment 36 Jonathan Lebon 2016-11-16 18:21:01 UTC
Anaconda fix for RHEL AH installer:
https://github.com/rhinstaller/anaconda/pull/871

As mentioned in the PR above, one issue is that Anaconda currently shows all possible locales, rather than only the available ones. We could wait to put it back in the installer GUI until this is done properly. At least until then, users can specify one of the supported LANGs in their kickstarts.

Comment 40 Jonathan Lebon 2017-05-03 16:59:03 UTC
Going to close this now.

Starting with 7.3.3, Atomic Host ships with all the officially supported locales. This however requires the use of a kickstart since the GUI installer for now only allows en_US. Though note that this will be fixed in 7.4 (see https://bugzilla.redhat.com/show_bug.cgi?id=1429576).


Note You need to log in before you can comment on or make changes to this bug.