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