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!
I really hope this didn’t stump any of you. It’s okay, if it did, you probably didn’t use the console and therefor probably didn’t see what actually failed. So, the link to the package, nitrux-icon-theme_3.5.3.tar.gz, is dead. Which makes it kind of hard for the PKGBUILD script to download it, build it and install it.
Locating the missing source for nitrux-icon-theme on the AUR
And, if you run a quick pacman -Qi nitrux-icon-theme you quickly see there’s supposed to be a nitrux website at https://nitrux.in/. But, trying to go there, you can see they closed their doors. The project forked into two projects now known as NX Desktop and Nitrux OS.
I’m probably wrong (according to my girlfriend, I am always wrong), but since the launchpad.net team references the Nitrux OS domain, and it was the last source in the PKGBUILD in the AUR, I kind of assume it was the more “official” source (at least as far as following the package maintainer’s intent). Looking quickly at their website, we get sent off to trusty old GitHub where the repository is now Archived (this means, no longer supported).
Quick patching the PKGBUILD file for missing source nitrux-icon-theme
There’s a chance here the AUR package maintainer has noticed this and simply wants the package to die. He’s not responded to quite a few comments on the AUR as well. Anywho, here’s the fix:
Yikes! This page went to shit during migrations. I apologize for that. I will make a note to pay better attention to my SEO errors. The gist of this blog post was covering errors around “yay build file exists“. So, I’ll rebuild it from memory, the best I can. Hope this helps!
error: failed to commit transaction (conflicting files)
yay build file exists
yay build file exists
nss & lib32-nss: /usr/lib/p11-kit-trust.so exists in filesystem
As we can see above yay has run into an error where a file that it does not expect to still exist, does still exist and it has stopped running. This is a pretty easy fix. However, it startled me because of the packages that it flagged on ‘nss’ and ‘lib32-nss’ respectively. These are very important packages on almost any modern linux distribution.
Fortunately for you, and unfortunately for me, I have a bit of a wonton attitude when it comes to my personal machines. So, without hesitation, I threw in the –overwrite toggles on these two bad boys and simply crossed my fingers.
This worked out just fine for me. The files were safely overwritten and the machine continue to function without any problems. So, if it’s simply a matter of an existing file that’s not shared by other packages, feel free to overwrite it.