This time, as almost every time before it, it is all my fault. I decided to use an untested tool, to help with my clean up tasks, during some maintenance and I am paying the price. I just reconfigured the default locale, one of the first things you configure when you’re installing linux.
This is the second problem I’ve bumped into and I realize now that I’ve bungled my /etc/. Being an engineer, this is okay. But, for some of you, this would be reinstall time. Allow me to rewind.
Suddenly, I can’t use ‘sudo’. Have I been hacked?
I was alarmed during the maintenance, because suddenly it seemed as if my password had changed or I otherwise could no longer use ‘sudo’. I also tried to switch users with ‘su’, into root, and that wasn’t possible for me either. You may find this odd, but that was actually a relief.
Obviously, I was aware that I was doing maintenance and cleaning up file lint (in this case, a lot of “.pacnew” files in etc, as well as “.old” had begun to pile up). In my haste to make good time and get back to work, I went ahead and told a particular tool to go ahead and replace the files with the “.pacnew”. I should’ve made sure to check that it was going to replace /etc/shadow. But, I didn’t.
Restoring /etc/shadow on Manjaro
Realizing the problem, I powered down and grabbed my bootable USB stick, loaded with a Manjaro installation image. For this trick, you can likely use any bootable linux distribution. I’d even recommend a distribution that is intended to be run from removable media. Because, that way, if you find your situation to be much worse, you have more tools are your disposal.
It booted into the live linux just fine. I unlocked my encrypted drive and mounted it. Browsing to the ‘etc’ folder, I was fortunate enough to find my shadow.old file sitting there. As well, I can proudly say that it did have the correct permissions set as well. So, my backup shadow file was not exposing sensitive secrets. An easy fix for me, but what if you don’t have your old shadow file?
In that case, the go-to fix is to set the password to a known value, so you can copy and paste it into other accounts, to restore normality. Once you’ve achieved that, you can reset those other accounts to stronger passwords once more. Let’s get back to the default locale issue.
locale: Cannot set LC_ALL to default locale: No such file or directory
Now, I’m familiar with why this happens. But, I was a little annoyed this time. Normally, a quick export LC_ALL=en_US.UTF-8 solves all problems (for Americans speaking English, anyway.. your default locale may be different). Well, that’s only because you’re used to SSHing into your linux machines. I realized, the second time I launched a terminal and the problem had returned, that I had done more damage before than I originally thought.
But, the optimist in me wanted to think that maybe wasn’t the case. So, I waded through all of the other possible default locale issues and the people responding, and upvoting, the above export LC_ALL fix. Turns out, often, someone has changed a profile setting, or other preference, in their terminal emulator (this is possible, it just wasn’t my problem). So, I check those and still nothing.
Finally, I bother to check /etc/locale.gen. Sure enough, it is default, everything is commented out. So, for me the fix was to purge my locale, uncomment my preferred locale in /etc/locale.gen and run locale-gen with sudo or otherwise as root.
All in all, I’m just taking this opportunity to allow errors to crop up, so that I can blog about fixing them.
Work your way back from system wise to local user applications.
If your locale issues keep coming back, exporting the appropriate default locale is only a temporary fix for that session, you’ll be wanting to check your terminal emulator (if applicable), local “dot files” that manage those settings and above all your system wide configuration. To save time, it’s best to actually do that in the other order. Start with the system wide configuration and work your way back into user configurations and finally down to specific applications.
Don’t let little problems ruin your day. Hire Gray Hat Freelancing to troubleshoot your next issue, fill out our form and we will give you a free consultation! We are “DevSecOps”, we do everything.. or, at least, it’s easier to list the things we can’t do. So, check us out!