Code talks louder than words:

root@myhost # locale-gen
Generating locales (this might take a while)...

(skipping a bit here)

error: Bad entry 'en_GB '
  en_GB.UTF-8... done

(skipping a bit here)

  en_SG.UTF-8... done
error: Bad entry 'en_US '
  en_US.ISO-8859-1... done
  en_US.UTF-8... done
error: Bad entry 'en_US.iso88591 '
error: Bad entry 'en_US.iso885915 '
  en_ZA.UTF-8... done

(skipping a bit here)

Generation complete.

Why am I getting these errors and how can I avoid them?


  • I use Linux Mint 18.2, but this started happening at some point in the (near?) past with Mint 18.1. They're both based on Ubuntu 16.04 I think.
  • I haven't found files with these "bad entries" (with or without the extra space at the end) under /etc; specifically not /etc/locale.gen.

Additional info:

Relevant contents of /etc/locale.gen:

# grep -v "#" /etc/locale.gen | sed "s/$/+/" | grep "en_"
en_GB.UTF-8 UTF-8+
en_US ISO-8859-1+
en_US.UTF-8 UTF-8+
  • Is that an extra space after the offending locales? – Rui F Ribeiro Jul 4 '17 at 10:40
  • @RuiFRibeiro: It looks like it, but I haven't found a file in /etc with that extra space. – einpoklum Jul 4 '17 at 10:47
  • what is the output of grep -v "#" /etc/locale.gen | sed "s/$/+/"? – Rui F Ribeiro Jul 4 '17 at 10:51
  • 1
    @RuiFRibeiro: See edit. I should also mention I had not messed with that file manually. – einpoklum Jul 4 '17 at 10:52
  • That file seems ok I think. At least the UTF entries are ok. What happens if you comment the ISO-8859-1 line and run locale-gen? – Rui F Ribeiro Jul 4 '17 at 10:56

locale-gen is a (not very well written) bash script. That error is reported by:

is_entry_ok() {
  if [ -n "$locale" -a -n "$charset" ] ; then
    echo "error: Bad entry '$locale $charset'"

So, here the problem is that $charset is empty.

The list of locales to generate is compiled from /etc/locale.gen and all the files in /var/lib/locales/supported.d.

Possibly, one of the files in there contains en_US on its own without the name of a charset.

Since your /etc/locale.gen doesn't have a en_SG.UTF-8, you most probably have files in /var/lib/locale/supported.d, and that's probably the ones that have malformed lines. Once you've identified the culprit, you can use dpkg -S on its path to see which package it came from if any.

  • That should be easy to find out...only if it is in a bad commented line. Interestingly enough, the OP is saying he did not mess manually with the offending file. – Rui F Ribeiro Jul 4 '17 at 11:09
  • 1
    @RuiFRibeiro, the problem is likely to be in a file in /var/lib/locales/supported.d (language-pack-* packages at least put files in there). Given the way that script is written, another possibility could be a comment line that contains # blahblah \nen_US, but that would be unlikely. – Stéphane Chazelas Jul 4 '17 at 11:13
  • The culprit is /var/lib/locales/supported.d/mintlocale, which is generated - so it seems - by either the mintlocale package or the mint-translations package (probably the first). Perhaps I should post something to the Mint forums then. – einpoklum Jul 4 '17 at 20:38
  • @einpoklum, yes, I can reproduce if I run mintlocale, and then click Install/Remove Languages and then Add... and add any language. It then generates the broken supported.d/mintlocale file. If you look at /usr/lib/linuxmint/mintlocale/add.py, it does a localedef --list-archive | sed 's/utf8/UTF-8 UTF-8/g' > /var/lib/locales/supported.d/mintlocale which is the source of the problem. – Stéphane Chazelas Jul 4 '17 at 20:52
  • 1
    @einpoklum That python code makes little sense. localedef --list-archive reports the list of already generated locale names. So dumping that (and incorrectly trying to derive the charset from the name) into a file meant to be used as the basis for generating locales makes no sense. – Stéphane Chazelas Jul 4 '17 at 21:02

Edit: This workaround is probably not the best solution; but it does work.

Based on @StephaneChazelas' answer, I figured out the problem is with /var/lib/locales/supported.d/mintlocale - a file specific to my distribution, Linux Mint. It is mis-generated, without charset fields for most (not all) of the lines, e.g.:

en_GB.UTF-8 UTF-8


en_US.UTF-8 UTF-8

So what I needed to do is generate the second field for everything. Here's what I did, basically:

sed -i -r '/^[a-zA-Z_]*$/d' mintlocale
sed -i -r 's/.([^. ]+)$/.\1 \1/' mintlocale
sed -i -r 's/ iso8859([0-9]+)$/ISO-8859-\1/' mintlocale

so, removing the lines without a .charset suffix, replicating the .charset suffix after a space, and changing the ISO 8859 charset formatting to match what we have in /usr/shared/i18n/charmaps/ (otherwise we'd get other errors).

Finally, I re-ran locale-gen and no there were no errors.

Note: I'm not 100% sure about the removal of the charset-less lines, so comments about that are welcome.

  • I'd say you can probably remove that file altogether and use dpkg-reconfigure locales instead of mintlocale. – Stéphane Chazelas Jul 4 '17 at 20:59

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.