Very useful yay commands for maintaining Arch-based linux distributions

About yay

yay commands using updates based on time, instead of version numbers, uses both official repository and aur simultaneously, loops sudo to prevent authenticating more than once, saves to config

Yay, Yet another Yogurt. is a command line tool for accessing the AUR (Arch User Repository) and managing packages on Linux Arch and Arch-based distributions (see: Manjaro and many more..). Written in Go, yay has been tried and tested for many years and remains my go to package manager for any distribution that supports use of the AUR.

That said, many users find themselves in deep water when they’ve accidentally allowed their packages to come into a “partially updated” state. This most often happens when people bounce from repository to repository trying to scratch a tiny itch (like say, from stable to testing or, more likely, from testing back to stable). These kinds of transitions need careful steps to be taken to be performed smoothly. And, even then, you should really have a good understanding of your operating systems before proceeding.

Either way, it’s possible, after a while or even heavy use, that you find yourself in a situation where your packages are in a “partially updated” state. And, of course, we all need to do a little spring cleaning, from time to time. The following yay commands will help you immensely.

Full System Update Using Yay  Commands

Copy

yay -Syyu

Lets break this down. First, we have -Syyu.

Here, -S tells yay we want to synchronize our package list with our upstream (defined in pacman.conf), an obvious step in looking for updates.

Next we have the repeated -yy this tells yay to get a fresh list of packages, and the second iteration tells yay to get a fresh list of packages even if our current list is not out-dated. This yay command should not be abused more than once a day.

Finally, we have -u, which predictably tells yay to upgrade any out-of-date packages. But, we still have these other toggles and why do I use them? It’s because I use the AUR.

Thise particular yay command is useful anytime you notice you have a package that has a version number that is abnormal.

yay shows packages with unusual version numbers

And here’s why. --timeupdate the timeupdate toggle tells yay to ignore version numbers and look for the date and time the latest PKGBUILD was pushed upstream to judge whether an upgrade is available for a package or not. This is critically important if you happen to get a package that’s orphaned often or otherwise has inconsistent version numbers.

Combined upgrade is exactly what it sounds like. Adding the toggle --combinedupgrade tells yay to upgrade packages from both the official upstream repository, as well as from the AUR, at the same time.

This one is simply handy. --sudoloop keeps sudo in play, in the background, during the various PKGBUILD processes, so that you don’t have to keep authenticating during longer package builds.

--save, of course, saves the toggles you used this time as the default toggles, for the next time you run any yay commands. It will assume these options, unless you specify otherwise.

Yay commands for maintenance

Due to the nature of the AUR, lint can tend to get left all over your system. Be it an orphhttps://www.grayhatfreelancing.com/aned package, or a PKGBUILD changed dependencies or requirements by the time it or some other package was removed. Here are some useful yay commands for maintaining the software on your system.

Copy to Clipboard

The yay command yay -Qt comes in quite useful when you’re cleaning your system of software lint. Or, in other words, software you may have explicitly installed, but can safely remove.

The -Q toggle stands for Query. You’re telling yay to query packages installed on your system.

The -t toggle stands for dependency test. This toggle for both pacman and yay will search for packages are that not required or not optionally required by any other installed package. Hence, they can safely be removed. If you’re feeling frisky, you can use the -t toggle twice, to include packages that are optionally required by installed packages. These can safely be removed without breaking any installed package, but you may lose some functionality if they’re not present.

2021-10-16T09:11:39-04:00October 12th, 2021|Categories: Engineering|Tags: , , , , , , , , |

systemd-backlight fails to start

So, for years now, some of us have been plagued with this nagging systemd-backlight services failure that’s mostly benign. But, anytime you run systemctl status you’d be returned with a status of degraded because this silly systemd-backlight service was just not wanting to cooperate. For most of us, it simply failed to store out backlight brightness level after reboot. But other’s have had more serious issues.

I’ve seend this issue crop up on multiple linux distributions in various forms. So, be clear, it was affecting me most recently on Linux Manjaro (my daily driver). I have an MSI laptop, with an AMD Ryzen CPU and AMD Radeon GPU. As well, my backlight has always worked and been fully adjustable.

The only negative side effect I suffered was that my system would never remember my brightness settings across a restart. Which is not really a problem at all, in fact, it’s been helpful more than once. But, others have not been so lucky. So, here’s how you fix this annoying bug.

You’re going to need to edit two different files, as you’ll see during remediation, there’s more than one problem going on here. First and foremost, if you’re seeing the [email protected]:acpi_video0 status failed lets start by attacking that issue.

I’m not certain, but the bug tracker sounds like it’s a race condition during discovery, that is solved if you specify your acpi_backlight module at boot. This is what worked for me.
So, lets open /etc/default/grub in our favorite editor and find the line GRUB_CMDLINE_LINUX_DEFAULT.

Append the acpi_backlight kernel option by adding acpi_backlight=vendor. Please note, there are three possible options here: vendor, video and native. If one doesn’t work for you, you’ll have to try the others. For my amdgpu vendor worked for me, which is where I ran into another issue.

Edit grub config

Coming back to that, after you’ve saved your changes, go ahead and run update-grub and reboot. Hopefully, this fixes your issue. For me, I started seeing errors with [email protected]:amdgpu_bl1.
It was telling me I had an invalid Type variable in my systemd file.

To fix this, I edited the /usr/lib/systemd/system/[email protected] file and changed the line Type=idle to Type=oneshot. And whala! No more errors. Now when I run systemctl status it always returns running.

systemd-backlight

/usr/lib/systemd/system/systemd-backlight

Check here for some scripts that might work for you, if you want a more comprehensive solution (provided that your issues match the problem mentioned here, mine did not).

Note that one other thing I did was to quit relying on KMS (sigh), as it’s been causing me other race conditions at boot. So, I added graphics module to /etc/mkinitcpio.conf. If you’re using something like a hybrid setup that requires bumblebee or what not, I do not recommend this. But, I specified on the MODULES line MODULES=(amdgpu). And of course ran mkinitcpio -g afterwards and reboot.

systemd-backlight add gpu's kernel module

/etc/mkinitcpio.conf

It was depressing for me, personally. Because I’ve always had to deal with that Intel+Nvidia bumblebee cluster fuck. And I was greatly looking forward to letting KMS do it’s thing. But, race conditions are hard to nail down and I’m not going to be annoyed until someone gets around to it.

2021-09-30T00:10:21-04:00September 29th, 2021|Categories: Engineering, Random Fixes|Tags: , , , , , , |

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

 

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!

 

2020-07-07T01:59:31-04:00May 28th, 2020|Categories: Engineering, Random Fixes|Tags: , , , |
Go to Top