42

I recently updated my Arch Linux server and during that process tmux got updated. I was using tmux while the upgrade was going on and used it afterwards, but all during the same SSH session.

Now, however, whenever I try to issue any tmux command I get this error:

tmux: need UTF-8 locale (LC_CTYPE) but have ANSI_X3.4-1968

Here's the output from locale -a on the server:

$ locale -a
C
POSIX

and on my machine (Ubuntu 15.10):

$ locale -a
C
C.UTF-8
en_AG
en_AG.utf8
en_AU.utf8
en_BW.utf8
en_CA.utf8
en_DK.utf8
en_GB.utf8
en_HK.utf8
en_IE.utf8
en_IN
en_IN.utf8
en_NG
en_NG.utf8
en_NZ.utf8
en_PH.utf8
en_SG.utf8
en_US.utf8
en_ZA.utf8
en_ZM
en_ZM.utf8
en_ZW.utf8
POSIX

What's going on and how do I fix it?

5 Answers 5

49

The same exact thing happened to me. Building on what Thomas said above, I was able to fix it by uncommenting en_US.UTF-8 UTF-8 in my /etc/locale.gen file (previously none of the lines had been uncommented), then running locale-gen.

6
  • For example, an upgrade may have overwritten your customized locale.gen file. Apr 22, 2016 at 20:37
  • @ThomasDickey More likely Arch Linux ARM was just being stupid, as Arch Linux ARM does some rather dumb things in the default image like shipping with useless packages that don't work because they're missing dependencies. I know I never touched that file, though. Apr 22, 2016 at 21:16
  • And, judging from @RPiAwesomeness's username, I'm guessing that the server in question happens to be a Raspberry Pi running Arch Linux ARM. (btw I run Ubuntu on my laptop and Arch on my Pi server too) Apr 22, 2016 at 21:17
  • 1
    @Hitechcomputergeek Indeed it is, desktop is Ubuntu proper 15.10 & server is a Pi 2 with Arch Linux ARM :D Apr 22, 2016 at 23:50
  • 1
    I had the same problem upgrading to Debian 9 Stretch , because my system locale is en_CA.UTF-8. That was un-commented in /etc/locale.gen. But en_US.UTF-8 was commented out and without that tmux threw that exact error. So that suggests if your locale is en_US then you won't see this issue. Mar 11, 2017 at 1:45
7

Following this link solves my problem:

sudo localectl set-locale LANG=en_CA.UTF-8
# or change to en_US.UTF-8 depends on your locale-gen

it generates a file /etc/locale.conf that fixes this issue

1
  • I had to do this in addition to the above to fix this for my raspberry running arch arm. So I used sudo localectl set-locale LANG=nl_BE.UTF-8 I also ran into an error org.freedesktop.PolicyKit1 not provided on daemon which put me on the wrong foot for a while, but this error was simply because I ran the command without sudo (I have a bad habit of leaving a terminal open that's already elevated) Mar 18, 2019 at 12:42
6

I had this one as well. My solution was …

apt search locales

I got a list, then install this …

apt install locales-all
2
  • The question mentions Arch Linux, which doesn't use apt for package management.
    – matt
    Mar 24, 2019 at 3:38
  • This is part of the solution =) thanks a lot!
    – mzalazar
    Apr 1, 2020 at 13:58
3

Perhaps your upgrade replaced the locale alias you were using and did not provide a useful upgrade path to the new name(s). You can regenerate locale information on the server, but keep in mind that the problem may be in your /etc/locale.gen or locale.conf file.

Further reading:

1

echo "LC_ALL=en_US.UTF-8" >> /etc/environment
echo "en_US.UTF-8 UTF-8" >> /etc/locale.gen
echo "LANG=en_US.UTF-8" > /etc/locale.conf
locale-gen en_US.UTF-8

1
  • Why does this solve the problem? And how does your answer differ from the already existing ones?
    – nohillside
    Mar 25, 2018 at 16:19

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.