On a couple of occasions, an update has broken my locale, which is annoying but I’ll save that for the rant below. And sure enough all of the sudden after the update, I’m back to getting bash: warning: setlocale: LC_ALL: cannot change locale (en_US.utf-8): No such file or directory every time I open a terminal in a domU, and I am sure it will show up as added garbage in every zenity error/message dialog I see from here on out.
It was fine before the update.
Why does it keep breaking? And how can I fix it and have it stay fixed?
I can’t remember the code to hide text under the little black triangle, so I can’t hide the following:
Side rant: It’s not as if this is of any importance, but it’s obnoxious and a constant nag. I’d be fine with the default locale, except that you can’t just not set it and have it use the default; it complains every time you do that too because the locale is not set and I’m going to nag you until you do whether you want it or not.
This is like being nagged about the toilet seat…by someone who doesn’t even live in my house.
Is your problem not that all locales in /etc/locale.gen is disabled, which is why it gets unset when the system tries to reapply your locales?
dpkg-reconfigure should enable the locales you select.
One thing I’ve noticed, gnome doesn’t work if you don’t enable en_US, I use a foreign language and unless I also enable en_US apps like gnome-terminal doesn’t start.
I think it is also important to run these sudo commands in the template, not the AppVMs. Changes made to system configuration files on an AppVM will be reset when you restart the AppVM.
Have you been running these commands in the template or the AppVMs? It could be that you are associating template updates and AppVM reboots, which restore template system configuration files, with the update instead of the reverting of the system files (from the template).
OK, I think I’m starting to understand. So let me state what I think is going on to see if it makes sense to you:
/etc/local.gen needs to be set up properly; doing what I was doing before (localedef -f UTF-8 -i en_US en_US.UTF-8 (as root–and, incidentally, from a salt file)) wasn’t changing that file. So the next update would simply undo what I set, because it would refer to this file.
So what I need to do, is have my salt file uncomment out en_US.UTF-8 in that file, instead of what I am doing. Then run some additional command to actually get the system to implement what is requested in the file. I know that just editing the file won’t do it, and even restarting that vm won’t do it.
The original run of the command is in the template…the one I consider my “base” template in fact. (It gets cloned when I create other templates.)
So that should be good.
Experimenting I’ve done today has been in VMs. Including what I just said to renehoj about editing the file not doing anything even after a restart. And that is a big OOPS on my part; I should have edited the file in the template. Trying that now.
In other words, when I first create my “base” template, I have salt run localedef -f UTF-8 -i en_US en_US.UTF-8 in it.
That does not alter /etc/locale.gen, but it does set up my locale the way I like. This carries through to every template I clone from this one, and all AppVms based on those templates.
Later on an update happens and essentially undoes my localedef command, in every single template, which breaks every AppVM in my system. Until I regenerate the template (or reissue the command manually in my template), it’s broken after that point. (Or I can issue it in an appvm, but as you note, that won’t persist.)
I’ll experiment with a Debian 12 minimal template on my end to see if I can reproduce. Unfortunately, all of my existing minimal templates are Fedora-based so I cannot provide any guidance on Debian minimal quirks right now.
Hopefully someone with more experience with Debian minimal and locales can provide some suggestions.
At this point my missing link is a command (that I can run from salt; i.e., one that doesn’t require the user to do anything) to “do” what’s in that file. I know that just editing the file and restarting the VM won’t do it.
I can then set up salt to uncomment out my locale in the file, then run that command. Then hopefully update won’t break it.
EDIT: That command appears to be locale-gen without any parameters. Need to do a little more to prove that, though.
That doesn’t apply to me…but that does stink. If it absolutely has to have something in particular, it should be the default, not something from a specific country.
OK. From a completely untouched (since the update) qube:
locale: Cannot set LC_CTYPE to default locale: No such file or directory
locale: Cannot set LC_MESSAGES to default locale: No such file or directory
locale: Cannot set LC_ALL to default locale: No such file or directory
LANG=en_US.UTF-8
LANGUAGE=
LC_CTYPE="en_US.utf-8"
LC_NUMERIC="en_US.utf-8"
LC_TIME="en_US.utf-8"
LC_COLLATE="en_US.utf-8"
LC_MONETARY="en_US.utf-8"
LC_MESSAGES="en_US.utf-8"
LC_PAPER="en_US.utf-8"
LC_NAME="en_US.utf-8"
LC_ADDRESS="en_US.utf-8"
LC_TELEPHONE="en_US.utf-8"
LC_MEASUREMENT="en_US.utf-8"
LC_IDENTIFICATION="en_US.utf-8"
LC_ALL=en_US.utf-8
And from one I’ve applied the fix to (the fix is to edit the local.gen file to suit and then run locale-gen. I did this on a template that needs updates. Then, I updated that template, and the locale did NOT break. That looks identical except the three error messages aren’t present.