Default image local is both incomplete and inconsistent
Closed this issue · 6 comments
Version of pynab: v0.9.1
Version of Nabaztag:
- Nabaztag (v1)
- Nabaztag:Tag (v2)
Version of TagTagTag:
- Maker Faire 2018
- Ulule 05/2019
The problem
When applying updates, the OS is complaining about some locale configuration not being set:
apt-listchanges: Can't set locale; make sure $LC_* and $LANG are correct!
Reading changelogs... Done
perl: warning: Setting locale failed.
perl: warning: Please check that your locale settings:
LANGUAGE = (unset),
LC_ALL = (unset),
LC_TIME = "fr_FR.UTF-8",
LC_MONETARY = "fr_FR.UTF-8",
LC_ADDRESS = "fr_FR.UTF-8",
LC_TELEPHONE = "fr_FR.UTF-8",
LC_NAME = "fr_FR.UTF-8",
LC_MEASUREMENT = "fr_FR.UTF-8",
LC_IDENTIFICATION = "fr_FR.UTF-8",
LC_NUMERIC = "fr_FR.UTF-8",
LC_PAPER = "fr_FR.UTF-8",
LANG = "en_GB.UTF-8"
are supported and installed on your system.
perl: warning: Falling back to a fallback locale ("en_GB.UTF-8").
locale: Cannot set LC_ALL to default locale: No such file or directory
This creates extra warnings for nothing and also highlights that the default image generated by the CI is not setting all the settings in a consistent way (some are set to en and others to fr).
Expected behavior
All locale variables are properly set to a single value.
Are you sure you don't have something else that somewhat alters your locale settings (changing some locale variables to use fr_FR locale)?
I am not aware of anything in the Pynab image build process that would change the locale settings (from the base OS image used for the build).
I just flashed a Pynab v0.9.1 image (which is based on Raspbian 2021-05-07 base image) to a SD card,
and here is what I get (on first login after first boot):
pi@Nabaztag:~ $ locale
LANG=en_GB.UTF-8
LANGUAGE=
LC_CTYPE=en_GB.UTF-8
LC_NUMERIC="en_GB.UTF-8"
LC_TIME="en_GB.UTF-8"
LC_COLLATE="en_GB.UTF-8"
LC_MONETARY="en_GB.UTF-8"
LC_MESSAGES="en_GB.UTF-8"
LC_PAPER="en_GB.UTF-8"
LC_NAME="en_GB.UTF-8"
LC_ADDRESS="en_GB.UTF-8"
LC_TELEPHONE="en_GB.UTF-8"
LC_MEASUREMENT="en_GB.UTF-8"
LC_IDENTIFICATION="en_GB.UTF-8"
LC_ALL=
This seems fairly consistent.
Also note: fr_FR.UTF-8 locale is not installed by default on image:
pi@nabaztag:~ $ locale -a
C
C.UTF-8
en_GB.utf8
POSIX
This is weird, I took the log excerpt used initially from the 0.9.1 image on GitHub and have imaged the SD card from it using Balena Etcher. Then, it went through its initial boot configuration and I never did any configuration to the OS (as it was a test env to compare drivers build).
However, there is a possibility that the SSH client is configured to inherit some local variables from the source env that initiates the SSH connection (that could account for the fr_FR discrepancy).
OTOH, the LANGUAGE & LC_ALL seems to be consistently undefined on the image leading to some package install/updates complaining about missing locale information.
I will double-check the dropbearSSH configuration to see about the local inheritance conf (not a major source of problem compared to undefined but still worth confirming).
However, there is a possibility that the SSH client is configured to inherit some locale variables from the source env that initiates the SSH connection
Indeed. To make sure, I have re-done the test after commenting out line AcceptEnv LANG LC_* from the /etc/ssh/sshd_config file on the image, restarting the ssh service and ssh'ing in again, and I get same result as above.
OTOH, the LANGUAGE & LC_ALL seems to be consistently undefined on the image...
This (LANGUAGE & LC_ALL no set) seems to be the case on most SBC Linux images:
I have a Pi 4 using a base Raspbian (Buster) image (no Pynab image involved here), and it also has:
LANGUAGE=
LC_ALL=
Same thing for an ASUS TinkerBoard running Debian (Stretch)...
Back to Pynab, I also made the test with fresh images for my v0.9.1+fl0.9.3 release (which is roughly on par with the current state of the Pynab master branch).
For the RaspiOS image (Bullseye - based on 2022-01-28 base image):
pi@Nabaztag:~ $ locale
LANG=en_GB.UTF-8
LANGUAGE=
LC_CTYPE="en_GB.UTF-8"
LC_NUMERIC="en_GB.UTF-8"
LC_TIME="en_GB.UTF-8"
LC_COLLATE="en_GB.UTF-8"
LC_MONETARY="en_GB.UTF-8"
LC_MESSAGES="en_GB.UTF-8"
LC_PAPER="en_GB.UTF-8"
LC_NAME="en_GB.UTF-8"
LC_ADDRESS="en_GB.UTF-8"
LC_TELEPHONE="en_GB.UTF-8"
LC_MEASUREMENT="en_GB.UTF-8"
LC_IDENTIFICATION="en_GB.UTF-8"
LC_ALL=
For the DietPi image (Bullseye - based on DietPi v7.9.3 base image):
dietpi@Nabaztag:~$ locale
LANG=C.UTF-8
LANGUAGE=
LC_CTYPE="C.UTF-8"
LC_NUMERIC="C.UTF-8"
LC_TIME="C.UTF-8"
LC_COLLATE="C.UTF-8"
LC_MONETARY="C.UTF-8"
LC_MESSAGES="C.UTF-8"
LC_PAPER="C.UTF-8"
LC_NAME="C.UTF-8"
LC_ADDRESS="C.UTF-8"
LC_TELEPHONE="C.UTF-8"
LC_MEASUREMENT="C.UTF-8"
LC_IDENTIFICATION="C.UTF-8"
LC_ALL=C.UTF-8
All this seems consistent from image to image, with the subtle difference that DietPi does set LC_ALL.
Thanks @f-laurens for your additional testing. I reproduced it on my dev board and my main laptop (Ubuntu with fr_FR locale).
When keeping the AcceptEnv LANG LC_* option active for the dropbearSSH server, the locale command & any APT action complains with the same message:
$ locale
locale: Cannot set LC_ALL to default locale: No such file or directory
LANG=en_GB.UTF-8
LANGUAGE=
LC_CTYPE="en_GB.UTF-8"
LC_NUMERIC=fr_FR.UTF-8
LC_TIME=fr_FR.UTF-8
LC_COLLATE="en_GB.UTF-8"
LC_MONETARY=fr_FR.UTF-8
LC_MESSAGES="en_GB.UTF-8"
LC_PAPER=fr_FR.UTF-8
LC_NAME=fr_FR.UTF-8
LC_ADDRESS=fr_FR.UTF-8
LC_TELEPHONE=fr_FR.UTF-8
LC_MEASUREMENT=fr_FR.UTF-8
LC_IDENTIFICATION=fr_FR.UTF-8
LC_ALL=
However, when I comment this option out and restart the SSHD service, then it only uses the Pi's locales and is happy (both with locale and APT actions):
$ locale
LANG=en_GB.UTF-8
LANGUAGE=
LC_CTYPE="en_GB.UTF-8"
LC_NUMERIC="en_GB.UTF-8"
LC_TIME="en_GB.UTF-8"
LC_COLLATE="en_GB.UTF-8"
LC_MONETARY="en_GB.UTF-8"
LC_MESSAGES="en_GB.UTF-8"
LC_PAPER="en_GB.UTF-8"
LC_NAME="en_GB.UTF-8"
LC_ADDRESS="en_GB.UTF-8"
LC_TELEPHONE="en_GB.UTF-8"
LC_MEASUREMENT="en_GB.UTF-8"
LC_IDENTIFICATION="en_GB.UTF-8"
LC_ALL=
I will raise the PR to address this papercut ;)
For future references, another possible way out of this warning is to re-run the locales configuration to generate the missing ones (the existing ones + inherited ones from the SSH connection should already be selected in the dialog):
sudo dpkg-reconfigure locales