Bug 1565718 - After upgrading to F28, my Czech locale is gone
Summary: After upgrading to F28, my Czech locale is gone
Keywords:
Status: CLOSED DUPLICATE of bug 1574222
Alias: None
Product: Fedora
Classification: Fedora
Component: glibc
Version: 28
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Carlos O'Donell
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2018-04-10 15:20 UTC by Miro Hrončok
Modified: 2018-10-03 15:34 UTC (History)
14 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2018-04-11 14:38:58 UTC
Type: Bug


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Bugzilla 1312690 0 unspecified CLOSED gnome-terminal crashes on launch if only C locale is available 2021-02-22 00:41:40 UTC
Red Hat Bugzilla 1313818 0 unspecified CLOSED Have setlocale fallback to C.UTF-8 before C/POSIX. 2021-02-22 00:41:40 UTC
Red Hat Bugzilla 1570924 0 unspecified CLOSED No fr_FR.utf8 locale after upgrade makes gnome-terminal impossible to launch 2021-02-22 00:41:40 UTC

Internal Links: 1312690 1313818 1570924

Description Miro Hrončok 2018-04-10 15:20:47 UTC
Description of problem:
I've upgraded to F28 via https://fedoraproject.org/wiki/DNF_system_upgrade

My system was in Czech, now it is in English:

$ locale
locale: Cannot set LC_ALL to default locale: No such file or directory
LANG=cs_CZ.utf8
LC_CTYPE="cs_CZ.utf8"
LC_NUMERIC="cs_CZ.utf8"
LC_TIME="cs_CZ.utf8"
LC_COLLATE="cs_CZ.utf8"
LC_MONETARY="cs_CZ.utf8"
LC_MESSAGES="cs_CZ.utf8"
LC_PAPER="cs_CZ.utf8"
LC_NAME="cs_CZ.utf8"
LC_ADDRESS="cs_CZ.utf8"
LC_TELEPHONE="cs_CZ.utf8"
LC_MEASUREMENT="cs_CZ.utf8"
LC_IDENTIFICATION="cs_CZ.utf8"
LC_ALL=


Version-Release number of selected component (if applicable):
glibc-common-2.27-8.fc28.x86_64

During the upgrade, I've seen the following perl warning when one of the scriptlets was running:

perl: warning: Setting locale failed.
perl: warning: Please check that your locale settings:
	LANGUAGE = (unset),
	LC_ALL = (unset),
	LANG = "cs_CZ.utf8"
    are supported and installed on your system.
perl: warning: Falling back to the standard locale ("C").

Comment 1 Miro Hrončok 2018-04-10 15:24:14 UTC
Workaround:

    dnf install glibc-langpack-cs

Yet the upgrade was not seamless because of this.

Comment 2 Carlos O'Donell 2018-04-10 15:35:13 UTC
(In reply to Miro Hrončok from comment #1)
> Workaround:
> 
>     dnf install glibc-langpack-cs
> 
> Yet the upgrade was not seamless because of this.

What version of Fedora were you upgrading to F28?

Did you run out of disk space during the upgrade?

The way this is designed to work is that:

* In F28 we have "Suggests: glibc-all-langpacks".
* As you upgrade to F28 the default "All languages" are installed and so you would continue to have cs_CZ.utf8.

The only time this might fail is if you ran out of disk space during the upgrade or something went wrong that interrupted the locale build or copy process.

Comment 3 Miro Hrončok 2018-04-10 15:46:14 UTC
(In reply to Carlos O'Donell from comment #2)
> What version of Fedora were you upgrading to F28?

Fedora 27.

> Did you run out of disk space during the upgrade?

I haven't noticed any problems. Is there a log I can check?

> The way this is designed to work is that:
> 
> * In F28 we have "Suggests: glibc-all-langpacks".

Suggests does nothing AFAIK. It only makes the package take precedense if multiple packages satisfy a dependency.

> * As you upgrade to F28 the default "All languages" are installed and so you
> would continue to have cs_CZ.utf8.

$ rpm -q glibc-all-langpacks
package glibc-all-langpacks is not installed

> The only time this might fail is if you ran out of disk space during the
> upgrade or something went wrong that interrupted the locale build or copy
> process.

There was no user visible error during the entire upgrade.

Comment 4 Carlos O'Donell 2018-04-10 15:56:36 UTC
(In reply to Miro Hrončok from comment #3)
> (In reply to Carlos O'Donell from comment #2)
> > What version of Fedora were you upgrading to F28?
> 
> Fedora 27.

OK, so you were already using either the Czech langpack or the glibc-all-lanpacks. This is good.

> > Did you run out of disk space during the upgrade?
> 
> I haven't noticed any problems. Is there a log I can check?
> 
> > The way this is designed to work is that:
> > 
> > * In F28 we have "Suggests: glibc-all-langpacks".
> 
> Suggests does nothing AFAIK. It only makes the package take precedense if
> multiple packages satisfy a dependency.

I simplified this explanation to make the answer shorter :-)

Let me quote from our spec file:

# For language packs we have glibc require a virtual dependency
# "glibc-langpack" wich gives us at least one installed langpack.
# If no langpack providing 'glibc-langpack' was installed you'd
# get all of them, and that would make the transition from a
# system without langpacks smoother (you'd get all the locales
# installed). You would then trim that list, and the trimmed list
# is preserved. One problem is you can't have "no" locales installed,
# in that case we offer a "glibc-minimal-langpack" sub-pakcage for
# this purpose.

e.g.
Requires: glibc-langpack = %{version}-%{release}
Suggests: glibc-all-langpacks = %{version}-%{release}

So in the absence of any langpacks installed you should upgrade to glibc-all-langpacks because that's the suggestion that meets the requires (as do all the language packs from glibc).

> > * As you upgrade to F28 the default "All languages" are installed and so you
> > would continue to have cs_CZ.utf8.
> 
> $ rpm -q glibc-all-langpacks
> package glibc-all-langpacks is not installed

Can you run:

rpm -qa | grep glibc

I want to see if dnf accidentally installed glibc-minimal-lanpack as a solution to the install.

> > The only time this might fail is if you ran out of disk space during the
> > upgrade or something went wrong that interrupted the locale build or copy
> > process.
> 
> There was no user visible error during the entire upgrade.

OK.

Comment 5 Miro Hrončok 2018-04-10 16:08:04 UTC
$ rpm -qa | grep glibc
glibc-headers-2.27-8.fc28.x86_64
glibc-langpack-en-2.27-8.fc28.x86_64   <---- this seems to be the thing
glibc-2.27-8.fc28.x86_64
glibc-2.27-8.fc28.i686
glibc-common-2.27-8.fc28.x86_64
glibc-devel-2.27-8.fc28.x86_64
glibc-langpack-cs-2.27-8.fc28.x86_64


$ LANG=C dnf history info 1149 | grep glibc
    Upgraded   glibc-2.26-27.fc27.i686                                                           @updates/27
    Upgraded   glibc-2.26-27.fc27.x86_64                                                         @updates/27
    Upgraded   glibc-common-2.26-27.fc27.x86_64                                                  @updates/27
    Upgraded   glibc-devel-2.26-27.fc27.x86_64                                                   @updates/27
    Upgraded   glibc-headers-2.26-27.fc27.x86_64                                                 @updates/27
    Upgraded   glibc-langpack-en-2.26-27.fc27.x86_64                                             @updates/27

Comment 6 Carlos O'Donell 2018-04-11 13:50:57 UTC
(In reply to Miro Hrončok from comment #5)
> $ rpm -qa | grep glibc
> glibc-headers-2.27-8.fc28.x86_64
> glibc-langpack-en-2.27-8.fc28.x86_64   <---- this seems to be the thing
> glibc-2.27-8.fc28.x86_64
> glibc-2.27-8.fc28.i686
> glibc-common-2.27-8.fc28.x86_64
> glibc-devel-2.27-8.fc28.x86_64
> glibc-langpack-cs-2.27-8.fc28.x86_64

It looks like you went from glibc-all-langpacks (all langauges) to just the English language pack, or from the Czech language pack the English language pack.

I don't know how this would have happened. Both the English and Czech language packs meet the requirements for glibc, having just one is enough. I would not have expected dnf to remove Czech for English given that Czech is always available as part of the upgrade. Perhaps some combination of packages caused English to be chosen instead of Czech. I'll have to keep an eye out for this.

I don't have any concrete suggestions here except to close out the issue and ask you to open another one if you see another instance of this. We'll keep tracking this on our end to see if it happens again.

Any other questions?

Comment 7 Miro Hrončok 2018-04-11 14:38:58 UTC
OK. I don't actually need this fixed, as my upgrade is finished. So at least you know about this. Thanks for swift communication.

Comment 8 johan 2018-05-10 13:37:50 UTC
I encountered the same issue. After upgrade to F28 from F27, the first noticeable issue was the inability to open the gnome-terminal. Using a full-screen terminal session I tried dnf update and was greeted with 'can not set lc_all to default locale'. This lead me to this issue.

I performed the workaround described. A dnf install glibc-langpack-nl solved my issue.

My guess as to what happens: I did not have this language package installed before the upgrade. This was acceptable because english was available as a fallback. After the upgrade glibc requires the stated locale to be available?

Investigation (performed after installing glibc-langpack-nl)
$ locale
LANG=en_US.utf8
LC_CTYPE="en_US.utf8"
LC_NUMERIC=nl_NL.utf8
LC_TIME=nl_NL.utf8
LC_COLLATE="en_US.utf8"
LC_MONETARY=nl_NL.utf8
LC_MESSAGES="en_US.utf8"
LC_PAPER="en_US.utf8"
LC_NAME="en_US.utf8"
LC_ADDRESS="en_US.utf8"
LC_TELEPHONE="en_US.utf8"
LC_MEASUREMENT=nl_NL.utf8
LC_IDENTIFICATION="en_US.utf8"
LC_ALL=

$ rpm -qa | grep glibc
glibc-langpack-nl-2.27-8.fc28.x86_64
glibc-common-2.27-8.fc28.x86_64
glibc-devel-2.27-8.fc28.x86_64
glibc-2.27-8.fc28.x86_64
glibc-utils-2.27-8.fc28.x86_64
glibc-headers-2.27-8.fc28.x86_64
glibc-langpack-en-2.27-8.fc28.x86_64
glibc-static-2.27-8.fc28.x86_64 

$ dnf history 
shows the upgrade transaction number (in my case 457)
$ dnf history info 457
shows a lot of actions, including tell tale warnings
  38 /etc/locale.conf: line 3: warning: setlocale: LC_TIME: cannot change locale (nl_NL.utf8): No such file or directory
  39 perl: warning: Setting locale failed.
  40 perl: warning: Please check that your locale settings:
  41 	LANGUAGE = (unset),
  42 	LC_ALL = (unset),
  43 	LC_MEASUREMENT = "nl_NL.utf8",
  44 	LC_MONETARY = "nl_NL.utf8",
  45 	LC_NUMERIC = "nl_NL.utf8",
  46 	LC_TIME = "nl_NL.utf8",
  47 	LANG = "en_US.UTF-8"
  48     are supported and installed on your system.
  49 perl: warning: Falling back to a fallback locale ("en_US.UTF-8").
  50 perl: warning: Setting locale failed.
  51 perl: warning: Please check that your locale settings:
  52 	LANGUAGE = (unset),
  53 	LC_ALL = (unset),
  54 	LC_MEASUREMENT = "nl_NL.utf8",
  55 	LC_MONETARY = "nl_NL.utf8",
  56 	LC_NUMERIC = "nl_NL.utf8",
  57 	LC_TIME = "nl_NL.utf8",
  58 	LANG = "en_US.UTF-8"
  59     are supported and installed on your system.
  60 perl: warning: Falling back to a fallback locale ("en_US.UTF-8").

$ dnf history info 457  | grep glibc
    Upgraded   glibc-2.26-27.fc27.x86_64                                                         @updates/27
    Upgraded   glibc-common-2.26-27.fc27.x86_64                                                  @updates/27
    Upgraded   glibc-devel-2.26-27.fc27.x86_64                                                   @updates/27
    Upgraded   glibc-headers-2.26-27.fc27.x86_64                                                 @updates/27
    Upgraded   glibc-langpack-en-2.26-27.fc27.x86_64                                             @updates/27
    Upgraded   glibc-static-2.26-27.fc27.x86_64                                                  @updates/27
    Upgraded   glibc-utils-2.26-27.fc27.x86_64                                                   @updates/27

Comment 9 Carlos O'Donell 2018-05-10 14:19:54 UTC
(In reply to johan from comment #8)
> I encountered the same issue. After upgrade to F28 from F27, the first
> noticeable issue was the inability to open the gnome-terminal. Using a
> full-screen terminal session I tried dnf update and was greeted with 'can
> not set lc_all to default locale'. This lead me to this issue.
> 
> I performed the workaround described. A dnf install glibc-langpack-nl solved
> my issue.
> 
> My guess as to what happens: I did not have this language package installed
> before the upgrade. This was acceptable because english was available as a
> fallback. After the upgrade glibc requires the stated locale to be available?

glibc does not require any locale to be installed, but there should always be a minimum of C.UTF-8 and C/POSIX installed.

gnome-terminal requires a UTF-8 locale:
https://bugzilla.redhat.com/show_bug.cgi?id=1312690

There *are* UTF-8 fallbacks in Fedora, namely C.UTF-8, which is always installed and cannot be removed (unless you manually delete the files). But we don't fall back to that by default:

"Have setlocale fallback to C.UTF-8 before C/POSIX."
https://bugzilla.redhat.com/show_bug.cgi?id=1313818

Therefore if you have a mix of languages (en_US/nl_NL), and you ended up in some way getting one removed by dnf during upgrade, then gnome-terminal will fail to start.

I think the most robust solution is probably to pursue the C.UTF-8 fallback default.

This is all a workaround though for a root cause we don't yet understand.

> Investigation (performed after installing glibc-langpack-nl)
> $ locale
> LANG=en_US.utf8
> LC_CTYPE="en_US.utf8"
> LC_NUMERIC=nl_NL.utf8
> LC_TIME=nl_NL.utf8
> LC_COLLATE="en_US.utf8"
> LC_MONETARY=nl_NL.utf8
> LC_MESSAGES="en_US.utf8"
> LC_PAPER="en_US.utf8"
> LC_NAME="en_US.utf8"
> LC_ADDRESS="en_US.utf8"
> LC_TELEPHONE="en_US.utf8"
> LC_MEASUREMENT=nl_NL.utf8
> LC_IDENTIFICATION="en_US.utf8"
> LC_ALL=

Interesting, you had a combined en_US and nl_NL.

> $ rpm -qa | grep glibc
> glibc-langpack-nl-2.27-8.fc28.x86_64
> glibc-common-2.27-8.fc28.x86_64
> glibc-devel-2.27-8.fc28.x86_64
> glibc-2.27-8.fc28.x86_64
> glibc-utils-2.27-8.fc28.x86_64
> glibc-headers-2.27-8.fc28.x86_64
> glibc-langpack-en-2.27-8.fc28.x86_64
> glibc-static-2.27-8.fc28.x86_64 

How many upgrades has this system gone through?

My hypothesis is, as Florian stated also in bug 1574222, is that this may be a dnf upgrade issue with langpacks, and an old locale-archive file.

> $ dnf history 
> shows the upgrade transaction number (in my case 457)
> $ dnf history info 457
> shows a lot of actions, including tell tale warnings
>   38 /etc/locale.conf: line 3: warning: setlocale: LC_TIME: cannot change
> locale (nl_NL.utf8): No such file or directory
>   39 perl: warning: Setting locale failed.
>   40 perl: warning: Please check that your locale settings:
>   41 	LANGUAGE = (unset),
>   42 	LC_ALL = (unset),
>   43 	LC_MEASUREMENT = "nl_NL.utf8",
>   44 	LC_MONETARY = "nl_NL.utf8",
>   45 	LC_NUMERIC = "nl_NL.utf8",
>   46 	LC_TIME = "nl_NL.utf8",
>   47 	LANG = "en_US.UTF-8"
>   48     are supported and installed on your system.
>   49 perl: warning: Falling back to a fallback locale ("en_US.UTF-8").
>   50 perl: warning: Setting locale failed.
>   51 perl: warning: Please check that your locale settings:
>   52 	LANGUAGE = (unset),
>   53 	LC_ALL = (unset),
>   54 	LC_MEASUREMENT = "nl_NL.utf8",
>   55 	LC_MONETARY = "nl_NL.utf8",
>   56 	LC_NUMERIC = "nl_NL.utf8",
>   57 	LC_TIME = "nl_NL.utf8",
>   58 	LANG = "en_US.UTF-8"
>   59     are supported and installed on your system.
>   60 perl: warning: Falling back to a fallback locale ("en_US.UTF-8").
> 
> $ dnf history info 457  | grep glibc
>     Upgraded   glibc-2.26-27.fc27.x86_64                                    
> @updates/27
>     Upgraded   glibc-common-2.26-27.fc27.x86_64                             
> @updates/27
>     Upgraded   glibc-devel-2.26-27.fc27.x86_64                              
> @updates/27
>     Upgraded   glibc-headers-2.26-27.fc27.x86_64                            
> @updates/27
>     Upgraded   glibc-langpack-en-2.26-27.fc27.x86_64                        
> @updates/27
>     Upgraded   glibc-static-2.26-27.fc27.x86_64                             
> @updates/27
>     Upgraded   glibc-utils-2.26-27.fc27.x86_64                              
> @updates/27

Perhaps you can comment on 1574222, which is where we are moving the issue.

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

Comment 10 George Petasis 2018-06-12 20:00:48 UTC
I also faced this issue, for the Greek locale (el).

Comment 11 Muxa Mot 2018-08-16 10:20:47 UTC
Also faced this issue for Russian (ru_RU) locale.

Comment 12 Jyri-Petteri Paloposki 2018-10-03 15:34:49 UTC
I also faced this issue for the Finnish (fi_FI) locale.


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