Dietpi: Upgrading from 2.6 to 2.8 leads to characters in weather and MOTD becoming squares symbols

[stephantual]

Creating a bug report/issue

Required Information

• DietPi version | 2.8
• Distro version | stretch
• Kernel version | 4.19.66-v7+ #1252 SMP
• SBC device | rpi 3 model b+
• Power supply used | official raspi PSU
• SDcard used | sandisk extreme 128gb

Steps to reproduce

1 . from 2.6 upgrade to 2.8 using dietpi update

Expected behaviour

motd and weather should display as before

Actual behaviour

characters in both motd and weather are replaced with squares ■, similar to when you use the wrong character set or try to display utf8 characters on a non-utf8 compatible device

Extra details

not much to add, it seems to affect only weather and motd, but i haven't dug deep. I can do more research if you point me where to look

[MichaIng]

@stephantual
Many thanks for your report.

Hmm code-wise the banner didn't receive any change (only a tiny non-related). Both, MOTD (currently) and weather (always did) contain UTF-8 characters, hence yes the console needs to be UTF-8 capable. However at least when you configure locales via dietpi-config, it always is.

Could you please paste the output of: locale; locale -a

[paliasp]

I noticed the same, however the problem is narrowed down (at least in my case) to Asbru connection manager. If I connect from the linux terminal, or even the local shell in Asbru, it works fine. Same from windows with SecureCRT.

dietpi@DietPi:[~]$ locale
LANG=en_GB.utf8
LANGUAGE=
LC_CTYPE="el_GR.UTF-8"
LC_NUMERIC="el_GR.UTF-8"
LC_TIME="el_GR.UTF-8"
LC_COLLATE="el_GR.UTF-8"
LC_MONETARY="el_GR.UTF-8"
LC_MESSAGES="el_GR.UTF-8"
LC_PAPER="el_GR.UTF-8"
LC_NAME="el_GR.UTF-8"
LC_ADDRESS="el_GR.UTF-8"
LC_TELEPHONE="el_GR.UTF-8"
LC_MEASUREMENT="el_GR.UTF-8"
LC_IDENTIFICATION="el_GR.UTF-8"
LC_ALL=el_GR.UTF-8
dietpi@DietPi:[~]$ locale -a
C
C.UTF-8
el_GR.utf8
en_GB.utf8
POSIX

and from my linux pc

trendy@garida:[~]$locale
LANG=en_GB.utf8
LANGUAGE=en_GB.utf8
LC_CTYPE="en_GB.utf8"
LC_NUMERIC=el_GR.utf8
LC_TIME=el_GR.utf8
LC_COLLATE=C
LC_MONETARY=el_GR.utf8
LC_MESSAGES="en_GB.utf8"
LC_PAPER=el_GR.utf8
LC_NAME=el_GR.utf8
LC_ADDRESS=el_GR.utf8
LC_TELEPHONE=el_GR.utf8
LC_MEASUREMENT=el_GR.utf8
LC_IDENTIFICATION=el_GR.utf8
LC_ALL=
trendy@garida:[~]$locale -a
C
C.UTF-8
POSIX
cs_CZ.utf8
el_CY.utf8
el_GR.utf8
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_IL
en_IL.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
ru_RU.utf8
ru_UA.utf8

[MichaIng]

@paliasp
Great find!

Probably Asbru CM does not natively support UTF-8 char display on client side? Maybe there is an option to enable it?
Another idea is that it might override the system locale with its own configured one, or the one it finds on the client host. SSH clients generally can do this and it's up to the SSH server to allow or deny it. OpenSSH has a switch for this, Dropbear AFAIK not. It is a known issue hence with Dropbear, that when the SSH clients sends an invalid locale, it is reverted to POSIX, hence no UTF-8 support: https://github.com/MichaIng/DietPi/issues/1540
We added a workaround for this to the global login script: https://github.com/MichaIng/DietPi/blob/master/rootfs/etc/bashrc.d/dietpi.bash#L26
Probably with Asbru CM it is a similar issue but the result of invalid locale is different there. I mean in theory SSH clients can run any commands after login to adjust console and such 🤔. Makes sense to search a bid through the Asbru CM settings at least.

[paliasp]

@MichaIng
Asbru does support utf8 and it is enabled in every possible setting.
Since I am running OpenSSH could you tell me the setting to deny locale override from the ssh client to test it? A quick search didn't help :(

[MichaIng]

@paliasp
Comment or remove the AcceptEnv setting in /etc/ssh/sshd_config. However based on your output no guarantee that this solves the issue.

[paliasp]

Indeed, doesn't fix it. I'll take it to Asbru.
Thank you @MichaIng !

[MichaIng]

I mark this as closed then, as SSH client related. If on Asbru there can be distilled a server-side workaround, feel free to reopen, so we could add it to DietPi.

[paliasp]

FYI, there seems to be some problem with expect in Asbru.
Apart from the broken MOTD, UTF8 characters in the same session work fine, for example the date/time.

[MichaIng]

Great, so indeed the way SSH was invoked via internal module was the culprit. Great that the Asbru devs fixed it so quickly :+1:.

[paliasp]

Yes, thankfully it was fixed immediately. I am waiting for the next release to verify it :)