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").
Workaround: dnf install glibc-langpack-cs Yet the upgrade was not seamless because of this.
(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.
(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.
(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.
$ 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
(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?
OK. I don't actually need this fixed, as my upgrade is finished. So at least you know about this. Thanks for swift communication.
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
(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 ***
I also faced this issue, for the Greek locale (el).
Also faced this issue for Russian (ru_RU) locale.
I also faced this issue for the Finnish (fi_FI) locale.