Description of problem: After upgrading from FC27 with all updates to FC28 on a system with language DE (German) strange things happened Version-Release number of selected component (if applicable): FC27 -> FC28 How reproducible: at least on 2 systems for now Steps to Reproduce: 1. upgrade Actual results: - XFCE logout window talks "English" - terminal "su -" results in $ su - Password: -bash: Warnung: setlocale: LC_TIME: Kann die Standorteinstellungen nicht ��ndern (de_DE.UTF-8). Expected results: Proper working Additional info: looks like "langpacks-de" is not covered by automatic upgrade during migration, after installation including dependencies everything looks fine: # yum install langpacks-de Failed to set locale, defaulting to C Fedora 28 - x86_64 - Updates 4.9 MB/s | 5.0 MB 00:01 Fedora 28 - x86_64 5.8 MB/s | 60 MB 00:10 RPM Fusion for Fedora 28 - Free - Updates 294 kB/s | 21 kB 00:00 RPM Fusion for Fedora 28 - Free 2.8 MB/s | 752 kB 00:00 RPM Fusion for Fedora 28 - Nonfree - Updates 22 kB/s | 3.6 kB 00:00 RPM Fusion for Fedora 28 - Nonfree 817 kB/s | 208 kB 00:00 Failed to synchronize cache for repo 'virtualbox', disabling. Last metadata expiration check: 0:00:00 ago on Wed May 2 20:02:51 2018. Dependencies resolved. ================================================================================ Package Arch Version Repository Size ================================================================================ Installing: langpacks-de noarch 1.0-12.fc28 fedora 8.5 k Installing weak dependencies: glibc-langpack-de x86_64 2.27-8.fc28 fedora 484 k kde-l10n-de noarch 17.08.3-3.fc28 fedora 983 k man-pages-de noarch 1.22-2.fc27 fedora 2.0 M tesseract-langpack-deu noarch 3.05.01-6.fc28 fedora 4.3 M Transaction Summary ================================================================================ Install 5 Packages Total download size: 7.8 M
Same issue for French with a graphical upgrade (from GNOME Software).
*** Bug 1575186 has been marked as a duplicate of this bug. ***
Please, can you provide us with relevant part (covering the system upgrade) of /var/log/dnf.log?
*** Bug 1574769 has been marked as a duplicate of this bug. ***
*** Bug 1573911 has been marked as a duplicate of this bug. ***
Created attachment 1432847 [details] dnf.log dnf log of f27->f28 upgrade that triggered the problem
Hm, it looks like langpacks-it and glibc-langpack-it packages were not installed even before upgrade, so it was not the "dnf system-upgrade" what caused the problem. I can see quite a lot of occurrences of this bug, all of them solved by installing glibc-langpack-*: https://bugzilla.redhat.com/show_bug.cgi?id=1570924 https://bugzilla.redhat.com/show_bug.cgi?id=1573712 https://bugzilla.redhat.com/show_bug.cgi?id=1572679 https://forums.fedora-fr.org/viewtopic.php?id=67631 http://www.hack23.de/blog/2018/05/fedora-28-upgrade-problem-mit-locale-settings/ There is probably something wrong with dependencies, which caused that glibc-langpack-* was not installed at all. But I'm puzzled how locales could work without this package (until upgrade to f28). I'm moving this bug to the glibc, just to ask if they have some suggestions where this bug could come from.
(In reply to Marek Blaha from comment #7) > There is probably something wrong with dependencies, which caused that > glibc-langpack-* was not installed at all. But I'm puzzled how locales could > work without this package (until upgrade to f28). The best explanation so far is that existing files were still around in the file system after a package has been deinstalled, and the RPM database did not reflect that. This can easily happen due to a system crash or the system administrator hitting ^C during a DNF operation. Unfortunately, this could have happened years ago because we did not change the locale format for quite some time, and only Fedora 28 stopped using the old files due to a format change.
FWIW my machine is one I installed F26 on, did regular updates as they were available, upgraded to F27 when it came out, did more regular updates on, then upgraded to F28. I haven’t installed that many apps on it and I probably never removed anything from it.
On F26 workstation you should have glibc-all-langpacks installed. That's probably why you do not need specific glibc-langpack-it. But according to attached log, you do not have this package installed neither. You can try to explore why is that. This command could be a good starting point: # dnf history list glibc-all-langpacks
*** Bug 1565718 has been marked as a duplicate of this bug. ***
*** Bug 1570924 has been marked as a duplicate of this bug. ***
It does not appear that I never had glibc-all-langpacks installed, yet this issue only manifested itself after the recent upgrade to FC 28: Is there a way to get wide output from dnf history? LANG=C dnf history *c-*langpack* ID | Command line | Date and time | Action(s) | Altered ------------------------------------------------------------------------------- 570 | install glibc-langpack-d | 2018-05-05 03:03 | Install | 1 569 | system-upgrade upgrade | 2018-05-05 01:49 | D, E, I, O, U | 2847 EE 537 | upgrade --refresh | 2018-03-14 22:26 | E, I, U | 109 EE 534 | upgrade | 2018-03-10 17:15 | I, U | 188 EE 502 | system-upgrade upgrade | 2018-01-25 00:42 | D, E, I, O, U | 2656 EE 501 | upgrade --refresh | 2018-01-25 00:28 | E, I, U | 39 EE 468 | upgrade | 2017-10-27 20:55 | E, I, U | 80 443 | --releasever=26 system-u | 2017-09-21 23:22 | D, E, I, O, U | 2600 ** 433 | upgrade | 2017-09-05 21:12 | Update | 8 ** 416 | upgrade | 2017-07-13 21:23 | E, I, U | 41 387 | upgrade | 2017-06-23 22:16 | Update | 16 370 | upgrade | 2017-06-12 21:24 | I, U | 17 262 | upgrade | 2016-12-28 00:09 | E, I, U | 119 239 | --releasever=25 system-u | 2016-12-01 15:48 | D, E, I, O, U | 1753 EE 174 | upgrade | 2016-08-21 14:06 | E, I, U | 240 163 | reinstall glib* | 2016-07-22 00:57 | Reinstall | 11 139 | --releasever=24 system-u | 2016-06-21 21:11 | D, E, I, O, U | 2104 EE
FWIW my system is F20 that’s been upgraded to the next version whenever it was available as shown by https://pastebin.com/mBDVZaP5
(In reply to Arne Ahrend from comment #13) > Is there a way to get wide output from dnf history? You can get details of particular history record by using the info subcommand: # dnf history info 163
I have two systems (laptops) here, one still on F27, the other one already on F28. I upgraded the second one via graphical method and it showed the problem of missing the langpack (de). Since I have a few installations in my environment where the users upgrade by themselves when I tell them that everything should work I want to make sure that this is fixed so they can upgrade without me installing the langpack everywhere. I can provide information both from the upgraded plus from the laptop still on F27. Since we have information of upgraded systems already in the thread, I’ll provide information about the old one. Let me know what I can provide for you to fix the problem (maybe introduce an additional dependency in a F28 package langpack to pull the corresponding glibc-langpack in?). sudo dnf history list glibc*langpack* ID | Befehlszeile | Datum und Zeit | Aktion(en) | Verände ------------------------------------------------------------------------------- 156 | system-upgrade upgrade | 2018-01-06 22:10 | E, I, O, U | 6214 EE 33 | --releasever=24 system-u | 2016-08-20 22:37 | D, E, I, O, U | 5346 EE sudo dnf history info 33 | grep langpack Installieren glibc-langpack-en-2.23.1-10.fc24.x86_64 @@commandline/24 Installieren libreoffice-langpack-en-1:5.1.5.2-3.fc24.x86_64 @@commandline/24 sudo dnf history info 156 | grep langpack Installieren evolution-data-server-langpacks-3.26.3-1.fc27.noarch @updates Installieren evolution-ews-langpacks-3.26.3-1.fc27.noarch @updates Installieren evolution-langpacks-3.26.3-1.fc27.noarch @updates Aktualisiert glibc-langpack-en-2.25-12.fc26.x86_64 (unknown) Aktualisiert libreoffice-langpack-de-1:5.3.7.2-6.fc26.x86_64 (unknown) Aktualisiert libreoffice-langpack-en-1:5.3.7.2-6.fc26.x86_64 (unknown) So, yes, the glibc-langpack-de is not installed on the system: rpm -aq | grep glibc-langpack glibc-langpack-en-2.26-27.fc27.x86_64 Still, the UI is German. Any package I can query that helps you understand why this works?
(In reply to Torsten Casselt from comment #16) > So, yes, the glibc-langpack-de is not installed on the system: > > > rpm -aq | grep glibc-langpack > glibc-langpack-en-2.26-27.fc27.x86_64 > > > Still, the UI is German. Any package I can query that helps you understand > why this works? The most common cause for this is that there is a file /usr/lib/locale/locale-archive, but the file is not listed in the RPM database. This happens if dnf/rpm is interrupted before the postuninstall scriptlet from glibc-all-langpacks runs. Fedora 28 is no longer compatible with the older file format for this file, so it is ignored, and the locale data contained in it is not used.
I was adviced to put my comments in this bug (responding on remarks in bug 1565718). > Interesting, you had a combined en_US and nl_NL. I never looked at my locale settings before this issue occurred. I do like application menu's and errors in English, but probably set numeric and other settings to follow our local habits. > 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. > How many upgrades has this system gone through? Short: maybe 10. Long: The system this occurred on is old and has gone through many updates. I have been using Fedora since ~FC4, and probably started fresh when building this PC in ~2008 (don't know the actual release number). Updating works great since yum/dnf, never anything I could not work around (but I am probably not a typical user).
After upgrading from F27 to F28, I was also not able to launch gnome-terminal with LANG=en_CA.UTF-8, after installing glibc-langpack-fr.x86_64 the terminal would launch.
*** Bug 1577330 has been marked as a duplicate of this bug. ***
I also had the same issue after upgrading with dnf from F27 to F28. I couldn't run gnome-terminal, gnome wanted to change the folder names, and part of the user interface was in English. I had to install glibc-langpack-it.
(In reply to Florian Weimer from comment #17) > The most common cause for this is that there is a file > /usr/lib/locale/locale-archive, but the file is not listed in the RPM > database. This happens if dnf/rpm is interrupted before the postuninstall > scriptlet from glibc-all-langpacks runs. > > Fedora 28 is no longer compatible with the older file format for this file, > so it is ignored, and the locale data contained in it is not used. Thanks for the explanation of the cause. Lots of users reported this issue now and since this is reproducible and there are a lot of installations out there that run the desktop in a language that is not English, this should be fixed somehow. Especially for casual users who might not find bug reports like this one because they search for the wrong terms (especially in their mother tongue). Since this bug is assigned to Carlos O'Donell and this is really a case for QA: Do you plan to fix it? If not, can I help fixing it? This kind of bug should really not happen on an upgrade. The casual user will probably reinstall if this bug occurs because to him it looks like something went wrong in the upgrade process — while it did not, it is just one package to install…
(In reply to Torsten Casselt from comment #22) > (In reply to Florian Weimer from comment #17) > > The most common cause for this is that there is a file > > /usr/lib/locale/locale-archive, but the file is not listed in the RPM > > database. This happens if dnf/rpm is interrupted before the postuninstall > > scriptlet from glibc-all-langpacks runs. > > > > Fedora 28 is no longer compatible with the older file format for this file, > > so it is ignored, and the locale data contained in it is not used. > > Thanks for the explanation of the cause. > > Lots of users reported this issue now and since this is reproducible and > there are a lot of installations out there that run the desktop in a > language that is not English, this should be fixed somehow. Especially for > casual users who might not find bug reports like this one because they > search for the wrong terms (especially in their mother tongue). > Since this bug is assigned to Carlos O'Donell and this is really a case for > QA: Do you plan to fix it? If not, can I help fixing it? This kind of bug > should really not happen on an upgrade. The casual user will probably > reinstall if this bug occurs because to him it looks like something went > wrong in the upgrade process — while it did not, it is just one package to > install… Help us reproduce the issue in-situ so we can understand what broke and why? The glibc-all-langpacks file always owns /usr/lib/locale/locale-archive. Why and how are things out of sync on these users systems? We don't know what kind of robustness fix we need without understanding the failure mode. That is to say, anything we put in might not do anything useful if we don't know what's wrong.
(In reply to Carlos O'Donell from comment #23) > Help us reproduce the issue in-situ so we can understand what broke and why? > > The glibc-all-langpacks file always owns /usr/lib/locale/locale-archive. > > Why and how are things out of sync on these users systems? My theory is that it was a side effect of bug 1397087, where users hat to interrupt DNF to recover, without completing the transaction.
I haven't noticed any dnf hangs during the upgrade and I was affected by this.
(In reply to Miro Hrončok from comment #25) > I haven't noticed any dnf hangs during the upgrade and I was affected by > this. The hang would have happened several Fedora releases ago.
Shouldn't this issue have appeared in F27 if the hang bug affected uses with other langpacks in F26? In fact, I never even had another langpack (other than en) installed until this happened to us. These are system backups that contains a list of installed rpms from F24-F28, # grep glibc-lang */root/bin/rpm.last.list Fedora_24_TwentyFour/root/bin/rpm.last.list:glibc-langpack-en-2.23.1-11.fc24.x86_64 Sun 06 Nov 2016 02:00:57 AM EST Fedora_25_TwentyFive/root/bin/rpm.last.list:glibc-langpack-en-2.24-10.fc25.x86_64 Tue 05 Sep 2017 02:00:11 AM EDT Fedora_26_TwentySix/root/bin/rpm.last.list:glibc-langpack-en-2.25-12.fc26.x86_64 Fri 27 Oct 2017 02:01:14 AM EDT Fedora_27_TwentySeven/root/bin/rpm.last.list:glibc-langpack-en-2.26-27.fc27.x86_64 Thu 15 Mar 2018 02:00:41 AM EDT Fedora_28_TwentyEight/root/bin/rpm.last.list:glibc-langpack-fr-2.27-15.fc28.x86_64 Mon 28 May 2018 02:00:16 AM EDT Fedora_28_TwentyEight/root/bin/rpm.last.list:glibc-langpack-en-2.27-15.fc28.x86_64 Mon 28 May 2018 02:00:11 AM EDT We were happily using gnome shell before F28 without any issue, myself using most english and my SO mostly french, but we both switched keyboard input, dictionaries, etc without issue. The weirdness only appeared after the update.
(In reply to Steeve McCauley from comment #27) > Shouldn't this issue have appeared in F27 if the hang bug affected uses with > other langpacks in F26? No, in Fedora 27, glibc could still use stale locale files from much earlier glibc versions. The locale format only changed in Fedora 28, making the issue visible.
Just for info got similar problem after upgrading F26->F28. - Mate desktop was in English. - console shows error with question signs - even when set English in console some of those questions still appeared installing glibc-langpack-en and glibc-langpack-uk solved problem. PS but now disappointed kernel-PAE discontinued :(
Some info from casual user: I also see that bug on our shared home PC. We have two logins, one with en_GB with Czech formats and the second user has full cs_CZ. After F27->F28 upgrade the gnome-terminal didn't start and the second user wasn't able to login at all (as described in bug 1573683). This system is from 2014. Packages are regularly updated (in fact, on every shutdown of any user if requested on logout screen). I think that system was upgraded on every Fedora release (i.e. no release was skipped), but some times after a very long time after official release (i.e. even more than year). Obviously installing glibc-langpack-cs fixed it. I didn't play with langpacks so far: [root@fuji log]# dnf history *c-*langpack* ID | Command line | Date and time | Action(s) | Altered ------------------------------------------------------------------------------- 60 | install glibc-langpack-c | 2018-06-24 14:13 | Install | 1 51 | --releasever=25 system-u | 2016-12-10 22:02 | D, E, I, O, U | 2017 EE 19 | --releasever=24 system-u | 2016-09-07 00:16 | D, E, I, O, U | 2644 EE [root@fuji log]#
*** Bug 1648671 has been marked as a duplicate of this bug. ***
See comment 17. In all instances where more data was available, the file system contents and the RPM database were out of sync. This is not something we can correct in glibc.
@Florian Weimer: just one last thought (and i might be completely wrong): could it be that the scope/content of the langpacks changed from F27 to F28 or F29? I am sure I had never installed langpack_de on my F27, so it didn't get updated anyway, but i still used a German keyboard layout. Now with F29 i had to install the langpack_de in order to get the Germany keyboard layout (as it is a specific locale setting)? Otherwise my LC_ALL wasn't set, causing gnome-terminal to fail. If so, the issue will only happen when upgrading from F27 or below to F28 or above, and will be gone for all other scenarios. And it would be special case for having English language with a German (or maybe other localization) keyboard layout?
(In reply to Harald from comment #33) > @Florian Weimer: just one last thought (and i might be completely wrong): > could it be that the scope/content of the langpacks changed from F27 to F28 > or F29? I am sure I had never installed langpack_de on my F27, so it didn't > get updated anyway, but i still used a German keyboard layout. See comment 24 and comment 28. It's like that this was a dormant issue for quite some time.
while locale [1] have all set in en_US, in my env I got LANGUAGE=en_US:pt [2] and evolution runs translated to Portuguese , where LANGUAGE is setting ? [1] locale 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= [2] env | grep pt LANGUAGE=en_US:pt
I'm right now experiencing same bug on Fedora 31 as fedora-review perl script is giving me this warning >perl: warning: Please check that your locale settings: > LANGUAGE = (unset), > LC_ALL = (unset), > LC_CTYPE = "C.UTF-8", > LANG = "cs_CZ.UTF-8" > are supported and installed on your system. >LANG=cs_CZ.UTF-8 >LC_CTYPE="cs_CZ.UTF-8" >LC_NUMERIC="cs_CZ.UTF-8" >LC_TIME="cs_CZ.UTF-8" >LC_COLLATE="cs_CZ.UTF-8" >LC_MONETARY="cs_CZ.UTF-8" >LC_MESSAGES="cs_CZ.UTF-8" >LC_PAPER="cs_CZ.UTF-8" >LC_NAME="cs_CZ.UTF-8" >LC_ADDRESS="cs_CZ.UTF-8" >LC_TELEPHONE="cs_CZ.UTF-8" >LC_MEASUREMENT="cs_CZ.UTF-8" >LC_IDENTIFICATION="cs_CZ.UTF-8" >LC_ALL= >rpm -qa | grep glibc >glibc-headers-2.30-5.fc31.x86_64 >glibc-langpack-cs-2.30-5.fc31.x86_64 >glibc-2.30-5.fc31.x86_64 >glibc-langpack-en-2.30-5.fc31.x86_64 >glibc-devel-2.30-5.fc31.x86_64 >glibc-common-2.30-5.fc31.x86_64 >glibc-all-langpacks-2.30-5.fc31.x86_64 In history I have installed F30 and immediately upgraded to F31 without any visible error. My system is in Czech and I use en_US keyboard layout
(In reply to Ondřej Pohořelský from comment #36) > I'm right now experiencing same bug on Fedora 31 as fedora-review perl > script is giving me this warning > > >perl: warning: Please check that your locale settings: > > LANGUAGE = (unset), > > LC_ALL = (unset), > > LC_CTYPE = "C.UTF-8", > > LANG = "cs_CZ.UTF-8" > > are supported and installed on your system. > > > >LANG=cs_CZ.UTF-8 > >LC_CTYPE="cs_CZ.UTF-8" > >LC_NUMERIC="cs_CZ.UTF-8" > >LC_TIME="cs_CZ.UTF-8" > >LC_COLLATE="cs_CZ.UTF-8" > >LC_MONETARY="cs_CZ.UTF-8" > >LC_MESSAGES="cs_CZ.UTF-8" > >LC_PAPER="cs_CZ.UTF-8" > >LC_NAME="cs_CZ.UTF-8" > >LC_ADDRESS="cs_CZ.UTF-8" > >LC_TELEPHONE="cs_CZ.UTF-8" > >LC_MEASUREMENT="cs_CZ.UTF-8" > >LC_IDENTIFICATION="cs_CZ.UTF-8" > >LC_ALL= Is the above the output from the locale command? If it does not show any errors, this is a different issue. If the system is generally using Czech as the system language and only Perl prints an error, this looks like a bug in Perl.
>Is the above the output from the locale command? Yes Thank you for your reply and useful information