DietPi-Config | "dpkg-reconfigure keyboard-configuration" shows wrong language with "en_GB.UTF-8" locale

[diveyez]

keyboard layout stuck on GB
No matter what I do, I cannot get it to recognize an American English keyboard as an American English keyboard.
I tried 9 spare keyboards at the office and it registers them all as GB

[MichaIng]

@diveyez
What you mean by "recognize"? There is no auto-recognition, but you must configure it: dietpi-config > Language/Regional Options > Keyboard

[diveyez]

https://imgur.com/gallery/u4jL08z

[diveyez]

This is really annoying

https://imgur.com/gallery/7T0Qmct

[diveyez]

Is there anyway to get a US keyboard layout in dietpi @MichaIng ??

[diveyez]

sudo dpkg-reconfigure keyboard-configuration

Allowed me to actually set my keyboard layout properly. It appears the menu for dietpi has incorrect values stored.

[diveyez]

@MichaIng ^_^

[MichaIng]

@diveyez

sudo dpkg-reconfigure keyboard-configuration

This is exactly what dietpi-config calls: https://github.com/MichaIng/DietPi/blob/master/dietpi/dietpi-config#L2195

Hmm very strange that it shows this strange characters in your case when started from within dietpi-config while it obviously does not when starting it outside. This was on RPi with Buster image?

Only thing I could imagine somehow is the changed locale, although en_US/en_GB UTF-8 should have no difference in characters. If you want to debug, you could try:

export LC_ALL='en_GB-UTF-8'
sudo dpkg-reconfigure keyboard-configuration

And check if the unreadable layout list is there as well. To revert:

export LC_ALL='en_US-UTF-8'

We apply en_GB in scripts to be failsafe when scraping external command outputs. Especially when having locales applied with totally different character set, external commands which support localisation would be unreadable to us, or the wording is different and such.

[diveyez]

Yes, all on buster today. I went back to stretch. I think Debian jinxed themselves with that release name lol

[diveyez]

Without a desktop environment, buster is smoooooth!

[diveyez]

That command you said to debug with showed the same results on buster. Switching back to stretch and production needs. +1 for superdev

[MichaIng]

I could replicate on Debian Buster as well. dpkg-reconfigure keyboard-configuration does not like en_GB.UTF-8 locale for whatever reason or interprets it wrong:

LC_ALL='en_US.UTF-8' dpkg-reconfigure keyboard-configuration:

Needs report to the Debian bug tracker if not already there.

[MichaIng]

I think it is this bug, already with a fix provided but not yet merged: https://salsa.debian.org/installer-team/console-setup/merge_requests/2

Lets hope this will be fixed soon, at least before official Buster release.

---

Waiting for user reply = "Waiting for Debian to fix it" 😉

[diveyez]

LMAO, Love you bro!

[MichaIng]

I reopen this issue to not forget checking back by times. If it is not resolved until official Buster release, we have to implement a workaround.

[MichaIng]

New/additional bug report has been opened: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=931139

[MichaIng]

Fix has been merged: https://salsa.debian.org/installer-team/console-setup/merge_requests/2
But it is not uploaded for the initial Debian Buster release anymore, however package update is expected "soon".

[G-Spawn]

sudo dpkg-reconfigure keyboard-configuration

Allowed me to actually set my keyboard layout properly. It appears the menu for dietpi has incorrect values stored.

damn thank you that instantly fixed my issues on dietpi. Mine was on like some russian bs prior now its perfect

[MichaIng]

It depends on your chosen locale btw. If you didn't change, so en_GB is chosen for console, the command will not change anything. Also some other locales have the same issue.

en_US seems to work, so correct workaround is:

export LC_ALL='en_US-UTF-8'
sudo dpkg-reconfigure keyboard-configuration

EDIT

Ah I just checked, and the bug has been solved with console-setup source v1.192 already.
So just run G_AGUP && G_AGUG when you still face it.

[jaxjexjox]

This bug, appears to be in place as of 15/Sept/2019 included in the downloadable ESXi (VMWare?) ISO on the web site :(

I've changed local to USA, I've changed keyboard to USA, I've reboted, I'm kinda baffled, I just want to be able to type \ instead of #

Regardless if this is broken 'in the backend' scripter / installer, what's the fix for those of us with DietPi installed and just want to use it?

[jaxjexjox]

I have continued to futz with this and several documented fixes online, to no avail.

sudo nano /boot/dietpi.txt - there's a line which clearly states
AUTO_SETUP_KEYBOARD_LAYOUT=gb

Editing it to US and rebooting, results in it setting itself back ... so I'm baffled

[MichaIng]

@jaxjexjox
The bug is present since long time in Debian Buster, so it has nothing to do with any recent change or DietPi at all.
But it has been resolved with a recent APT update, G_AGUP && G_AGUG + reboot (as I suggested above) does not help? The related dialog to choose/select the keyboard layout still shows strange languages/characters?

AUTO_SETUP_KEYBOARD_LAYOUT just has an effect when set before booting the first time, like all "AUTO_SETUP" settings.

You can apply the setting manually via:

G_CONFIG_INJECT 'XKBLAYOUT=' 'XKBLAYOUT="us"' /etc/default/keyboard

To apply "us" keyboard layout.

[jaxjexjox]

Firstly,

Thanks for the reply.
Secondly G_AGUP is case sensitive! So I had failed at it earlier.
I've now ran it and rebooted it.

I have manually applied the setting using this command now.

G_CONFIG_INJECT 'XKBLAYOUT=' 'XKBLAYOUT="us"' /etc/default/keyboard

and rebooted, I continue to have # when I should have \

Am I doing something wrong?

[jaxjexjox]

Ok so I have now SSH in to the device and this is working.

However, the direct console via VMWare continues to be GB.
This is acceptable for me but odd. My system is 100% configured for en-us (AU) - and I don't seem to see any settings for VMWare workstation indicating customisable region options.

None the less, it works - thanks for the hard work!

[MichaIng]

@jaxjexjox
I am currently not sure if running setupcon might be required to apply /etc/default/keyboard settings to console even after reboot. At least worth to give it a try.

And did you retry via dietpi-config now, after G_AGUP && G_AGUG? Jep on Linux shells, all commands and functions are case sensitive.

On SSH sessions, the SSH client defines the keyboard layout, so what has been configured on the server has only an effect for local or serial consoles.

[jaxjexjox]

I am currently not sure if running setupcon might be required to apply /etc/default/keyboard settings to console even after reboot. At least worth to give it a try.

This was precisely it - I edited that file, switch from PC105 to PC101, replaced a gb with US and ran setupcon.

Again, thanks for the help - please consider rolling all this in to the next build for newbies though.

[jaxjexjox]

Wait......... so that worked, then rebooting, it reverted :/

[MichaIng]

@jaxjexjox
You mean the file /etc/default/keyboard reverted to previous stage? Then there is an issue with your drive respectively virtualizer. I expect then any change to the file system will be reverted after reboot, cause nothing on DietPi touches this file after first boot (which you would recognise because of first run update and dietpi-software prompt on login).

I just retested dpkg-reconfigure keyboard-configuration (which is what dietpi-config calls when editing the keyboard layout) and it works very well here, even with locales that are not installed, showing all entries with correct language 😄.
If a reboot in your case resets the file system, probably as well the keyboard-configuration/console-setup package is reverted to a version which did not yet solve the bug.

root@VM-Buster:~# dpkg -l keyboard-configuration
ii  keyboard-configuration 1.193~deb10u1 all          system-wide keyboard preferences

• If your system shows a lower version than 1.193, then G_AGUP && G_AGUG (in case you run with non-root user, prefix with both with G_SUDO) should upgrade it.
• If after reboot it is again not the current version, then check your ESXi for any error logs.

[jaxjexjox]

You mean the file /etc/default/keyboard reverted to previous stage?

No, upon reboot, this is actually correct.
If I log in to the console and literally just type "setupcon" it is fixed automatically.

I do not know why - this is (basically) a fresh build
My version is 1.193 btw.

[MichaIng]

@jaxjexjox
Ah, can you please paste the output of: journalctl -u console-setup

[jaxjexjox]

root@DietPi:~# journalctl -u console-setup
-- Logs begin at Tue 2019-09-17 14:05:06 AEST, end at Tue 2019-09-17 17:35:31 AE
ST. --
Sep 17 14:05:11 DietPi console-setup.sh[233]: /usr/bin/setupcon: 870: /usr/bin/setupcon: cannot open /tmp/tmpkbd.f7Mrt7: No such file
Sep 17 14:05:11 DietPi systemd[1]: console-setup.service
: Main process exited, code=exited, status=1/FAILURE
Sep 17 14:05:11 DietPi systemd[1]: console-setup.service
: Failed with result 'exit-code'.
Sep 17 14:05:11 DietPi systemd[1]: Failed to start Set console font and keymap.

[MichaIng]

@jaxjexjox
Does the following succeed? systemctl restart console-setup

Apart from that I found: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=818065
Some later post shows exactly your error, also stating that on Linux/udev systems (which DietPi is), udev rules do the console setup. I just verified they exist as part of the package.
The keyboard configuration is done via keyboard-setup service, so what needs to be checked is actually: journalctl -u keyboard-setup

Also check the following script, which is finally called, has 755 permission mode:

ls -l /etc/console-setup/cached_setup_keyboard.sh

Regardless the console-setup should not fail.
I further checked /etc/console-setup/cached_setup_keyboard.sh and it only calls setupcon if either /etc/default/keyboard or /etc/default/console-setup are newer than the script itself, so if one changes them manually, which is true in your case.

I changed the file now as well and:

root@VM-Buster:~# journalctl -u console-setup.service
-- Logs begin at Tue 2019-09-17 10:36:23 CEST, end at Tue 2019-09-17 10:39:04 CEST. --
Sep 17 10:36:24 VM-Buster systemd[1]: Starting Set console font and keymap...
Sep 17 10:36:26 VM-Buster console-setup.sh[178]: WARNING: Unknown X keysym "dead_belowmacron"
Sep 17 10:36:26 VM-Buster console-setup.sh[178]: WARNING: Unknown X keysym "dead_belowmacron"
Sep 17 10:36:26 VM-Buster console-setup.sh[178]: /usr/bin/setupcon: 870: /usr/bin/setupcon: cannot open /tmp/tmpkbd.5uMkx7: No such file
Sep 17 10:36:26 VM-Buster systemd[1]: console-setup.service: Main process exited, code=exited, status=1/FAILURE
Sep 17 10:36:26 VM-Buster systemd[1]: console-setup.service: Failed with result 'exit-code'.
Sep 17 10:36:26 VM-Buster systemd[1]: Failed to start Set console font and keymap.

systemctl status keyboard-setup however shows success, but this means no setupcon is called on boot, which seems to be required in your case.

A quite complicated service and condition structure, no wonder why issues occur...

---

So the bug report I linked above further states to add /tmp to the service mount dependencies. This does not help in my/our case since it starts very well late after /tmp was mounted.

Another suggestion is to edit/regenerate the cached script files, however the mentioned offending line /tmp/tmpkbd.iDWdSi is not part of this script, but created during setupcon call.

But indeed systemctl start console-setup fixes the issue on boot since the cached scripts are regenerated which leads to setupcon is not called during boot.
setupcon --save does this actually.

As fast as /etc/default/keyboard is saved, even without any change (just to update the timestamp), the service again fails on boot, so it has nothing to do with the files/scripts contents but only that setupcon for some reason cannot be called during boot, even that /tmp has long been mounted and is used by many other scripts already successfully.

---

Okay long story short:

• When manually editing /etc/default/keyboard, run setupcon --save afterwards, to prevent the failing call on boot.
• This is not even done/fixed by dpkg-reconfigure keyboard-configuration as I recognised now.

So we have to warm up the old bug report again, since the issue has not been solved since last post from > 1h...

---

This is btw no bug on Stretch, there the service succeeds on boot. Opened PR to fix: https://github.com/MichaIng/DietPi/pull/3114

[MichaIng]

Updated bug report: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=818065#95