manjaro

Home/Tag: manjaro
28 05, 2020

locale: Cannot set LC_ALL to default locale: No such file or directory

By |2020-05-28T00:13:15-04:00May 28th, 2020|Engineering, Random Fixes|0 Comments

Cannot Set Default Locale

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.

cannot set default locale
cannot set default locale

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.

cannot set default locale
cannot set default locale

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!

22 05, 2020

ERROR: Failure while downloading nitrux-icon-theme_3.5.3.tar.gz

By |2020-05-22T06:27:35-04:00May 22nd, 2020|Engineering, Random Fixes|0 Comments

error-failure-while-downloading-nitrux-icon-theme
ERROR: Failure while downloading nitrux-icon-theme

Arch/Manjaro Update Fails Downloading nitrux-icon-theme_3.5.3.tar.gz

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:

error downloading sources nitrux-icon-theme
Edit the PKGBUILD for nitrux-icon-theme
  • Grab the latest release from GitHub: https://github.com/Nitrux/nitrux-icon-theme/archive/3.5.4.tar.gz
  • run md5sum on the gunzipped tarball
  • rerun pacman with –editmenu so it asks if you want to edit the PKGBUILD file
  • Select any option that allows you to edit the PKGBUILD file (for me, using yay this was [A]
  • Update the source field with the latest available release
  • Update the md5sum field with the m5sum command’s output
  • Write and exit the PKGBUILD file
  • Continue the installation

ERROR: Failure while downloading nitrux-icon-theme – Fixed! Quickly!

wget https://github.com/Nitrux/nitrux-icon-theme/archive/3.5.4.tar.gz
md5sum 3.5.4.tar.gz
yay --editmenu -Syyu nitrux-icon-theme

Check out other random fixes on Gray Hat Freelancing.

20 04, 2020

p11-kit-trust.so exists in filesystem – Quickly Fixed!

By |2020-05-28T01:21:30-04:00April 20th, 2020|Engineering, Random Fixes|0 Comments

Solving nss: /usr/lib/p11-kit-trust.so exists in filesystem

Error: Failed to commit transaction (conflicting files)

I crossed this one today, nss: /usr/lib/p11-kit-trust.so exists in filesystem, doing a full system upgrade on my daily driver. I use Linux Manjaro for all purposes. As I was installing an English thesaurus, I decided to go around and sync with the upstream repository and do a full update.

yay -Syyu mythesia

This hardly happens, but sure enough, I got this error:

error: failed to commit transaction (conflicting files)
nss: /usr/lib/p11-kit-trust.so
libs32-nss: /usr/lib32/p11-kit-trust.so

For the record, yay is just a wrapper around pacman for updating Arch and Manjaro. It also utilizes the AUR, if you want it to. If you haven’t used it, it’s worth checking out. Just know that it could be part of how I ended up in this situation.

p11-kit-trust.so file exists in file system
fike exists in filesystem

At first glace, that’s alarming. Those packages, nss and lib32-nss, are required by tons of packages. Meaning all of those packages depend on them. But, don’t panic. I was ballsy enough to try and just overwrite them and it didn’t brick my system. So, it’s fine.

p11-kit-trust.so file exists in filesystem
sudo Don’t argue with me

The Fix for ‘nss: /usr/lib/p11-kit-trust.so exists in filesystem’:

yay -Syyu --overwrite /usr/lib/p11-kit-trust.so --overwrite /usr/lib32/p11-kit-trust.so
p11-kit-trust.so file exists in filesystem

Contact me, any time, for a free consultation.