Update broke my locale...again

My domUs are based on debian-12-minimal.

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.

How are you configuring your locale in your domUs? Where are you making the configuration change?

I can’t even figure that out, honestly. I’ve been looking in file after file and can’t find anything.

Edit: And that’s because it’s not in a file; it’s a command I ran when I created the qube: localedef -f UTF-8 -i en_US en_US.UTF-8 (as root).

Apparently update can unset this.

You can use dpkg-reconfigure locales, update does run it automatically on minimal templates.

1 Like

Thanks…I’m looking at that.

I’d prefer something that can be run from within a script.

Plus, what does it mean that “updates runs it”? Will it wipe out what I did?

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.

To be a bit more clear, I think this is what is occurring:

  1. Your commands are modifying non-persistent (system) and persistent (user) configuration files.
  2. You are rebooting AppVMs after template updates. (this is speculation on my part)
  3. The reboots are reverting (or clearing) the non-persistent system configuration changes.
  4. There is a conflict between what the persistent user configuration expects and what is reverted/changed in system configurations from the template.
  5. You are associating the update with broken system configuration in the AppVM, when it is actually the AppVM reboot.

The root filesystem is non-persistent.

I don’t think you need to change any salt files or set up any scripts. I think you just need to set up the locale in the template, not the AppVM.

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.

I DID do the original set in the template. And multiple clones were made of that template.

All worked fine until the update, which apparently wiped out my setting in each and every template…

1 Like

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.

Can you share the output of locale? I want to have a reference of what yours looks like when I’m testing and comparing debian-12-minimal on my system.

Before or after I fix it?

Are they different? If different, I guess both.

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

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.