Bug 1186757
| Summary: | Atomic Host only supports the en_US locale | ||
|---|---|---|---|
| Product: | Red Hat Enterprise Linux 7 | Reporter: | Jeremy Harris <jeharris> |
| Component: | rhel-server-atomic | Assignee: | Colin Walters <walters> |
| Status: | CLOSED CURRENTRELEASE | QA Contact: | atomic-bugs <atomic-bugs> |
| Severity: | medium | Docs Contact: | Yoana Ruseva <yruseva> |
| Priority: | medium | ||
| Version: | 7.0 | CC: | atodorov, bbreard, chorn, cpelland, dmoessne, dwalsh, erich, fhornain, ghelleks, jeharris, jlebon, kyoneyam, mattdm, miabbott, rodolfoarce, sfroemer, vanhoof, walters, ypu |
| Target Milestone: | rc | Keywords: | Extras |
| Target Release: | --- | ||
| Hardware: | x86_64 | ||
| OS: | Linux | ||
| Whiteboard: | |||
| 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.
|
Story Points: | --- |
| Clone Of: | Environment: | ||
| Last Closed: | 2017-05-03 16:59:03 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: | 1186913, 1268897, 1350975, 1399379, 1420851 | ||
|
Description
Jeremy Harris
2015-01-28 13:39: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. Additional: after a rollback to 7.0.0 there are no errors on a root login. There are still no LC_* environment variables. *** Bug 1166544 has been marked as a duplicate of this bug. *** Future work may include non-US keyboard input but not translations. 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. This also affects the Centos Atomic rebuild that was recently released - http://lists.centos.org/pipermail/centos-devel/2015-June/013542.html > 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.
Jeremy - is it sufficient to disable alternate local selection on install for this BZ? Yes, but only if there is a documented method for obtaining a specified locale. Is there a workaround for this issue that I can include in the release note? *** Bug 1302342 has been marked as a duplicate of this bug. *** Any update on this? 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? 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. 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. (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? Has any thought be given to only shipping the "Supported" locales? Can we do that? (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? (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? 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. 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. 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? 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 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 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. 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). |