Hazards of a rolling distro

I love Garuda, and that mostly goes for any Arch based distro as well. Truth to tell though, I would never recommend a rolling distro like an Arch based one for non technically inclined newbs.

Arch based distro's require maintenance. They are not set and forget. Anybody can install Garuda on a computer. That's pretty simple in this day and age. The problem isn't in the installing, it's in learning to upkeep your system.

If you are going to run an Arch based distro for the long term then you need to learn how to maintain it properly. People with no desire to learn technical aspects of the OS probably shouldn't pick an Arch based daily driver.

Anyone that enjoys tinkering with their system will love a rolling distro based on Arch. For the set and forget crowd they should run a static distro.

Not being an elitist, just a realist. Just my opinion.


I switched to Ubuntu because M$ is a pain.
Then to Mint because Ubuntu became torture.
Because even the Mint kernel I built was still twice as big as Arch's,
I switched to (MJ) Deepin. Just because of the look :slight_smile: .
When I changed to i3 and more and more unnecessary things inflated my system,
the only way left was Cleanjaro (Thanks @Yorper).
Which finally resulted in "my own" i3wm system which was kindly created by @librewish.

What can I say, others seem to like it too :wink:


Installing Arch is a measure of your literacy.
Maintaining Arch is a measure of your diligence.
Contributing to Arch is a measure of your competence.

-- Jasonwryan, (Retired ArchWiki Administrator)


Preach it.

And if you’re not just a realist but also a pragmatist, think about what happens when the set and forget person has trouble with their system because they didn’t read update announcements or maintain their system.

You’re going to get the brunt of their blame and complaints, for recommending this to them.

And it’s not their fault. Some people just use their computers as appliances; they aren’t interested in the OS per se nor tinkering with it.


BTRFS and Timeshift mitigates this somewhat, but in other ways it's more dangerous for naive newbs. To the non sophisticated user they might assume they're covered as far as backups are concerned. That is a dangerous assumption and one that's very likely to lose their data. BTFFS + Timeshift is an excellent system restore feature, but it is not foolproof (neither is it a proper backup system).


What's with all this Negative Nancy stuff? I admit you're right, but...we're not supposed to SAY it :slight_smile:
I never assume my data is safe unless I have it in three places...(at least) and I don't mean on the same computer in three places. And really, my data isn't that important. If you actually had money riding on/in your data and it's close to irreplaceable...you should do definitely learn about backups, cloud storage, co-location,etc.

1 Like

No one wants to hear it, but your data should be in at least three places. One of those being offsite or in the cloud. That's not being negative, it's just being prudent.

Rarely do users with limited experience in Linux ever put a backup strategy into place. Then if there's a system meltdown it's always the distro that gets blamed.

A little preparation goes a long ways to preventing a lot of tears.


I'm back.... Sort of... So I've got a PC up and running, but have been super busy with my new job. I also kind of broke my phone, which is why i've been silent so long.....

Did i miss much?


Lots of nice little additions and changes and new servers :grin:
Thats an overview on what changed since last month :smiley:


I'm currently busy trying to put together a shell script that will help provide new users with helpful tips during the update process. It will be triggered by a pacman hook. The hook will trigger if major components are being upgraded such as the kernel or systemd (and others).

The script will provide onscreen and popup messages with helpful tips for newbs and a redirect to the Arch update news. It will also notify the user when an update is likely to require a system reboot. This will hopefully cut down on the number of help requests from users who simply forget to reboot after the kernel has been updated.

One of the things covered in the tips is how to restore your system if you encounter a bad update and the fact that timeshift does not backup your data by default. It's aimed at those new to Linux or new to an Arch Linux based distro.

It will be designed so it is easily disabled through the Garuda Welcome app if the user finds it annoying (but it won't stop the update process).

My scripting skills are a little rusty, and they were never that great in the first place.

So if there's any volunteers that would like to be a test pilot for how it works shoot me a PM and I'll send you an early draft to test it out on your system. Keep in mind the target user for this script is those new to Linux or the Arch world. Let me know if you'd like to check out the script and hook before it ever gets put into usage.

Any feedback during development would be appreciated.


I have been reading a lot about Arch Linux, as a distribution, being more geared towards advanced Linux users versus the other options. As a new user myself, I have already tried a few, and continued to look for and test other distributions.

I wanted to try Garuda because the appearance was what first caught my attention. I went about the usual method of installation and found it to be extremely easy. This was interesting right away because like I mentioned, many previous discussions regarding an Arch distro install said it wasn't easy.

Next comes the DE, and it was just as pleasant to get around as any other "basic" Linux distro I've used before, except for what I see as many, many more options, and lack of bloat (which I understand comes standard).

So, as an Arch distro, I see the intention of Garuda as to provide an experience that is inviting to a new user while still maintaining the power for advanced users. Am I correct in thinking this is the case? I didn't expect this OS to be as pleasant as it is, and for that I am grateful.


Well said...exactly my own perspective, views and thanks!

1 Like

Mostly, yes.

Arch is not just an OS, it's a way of thinking, i.e. it's intended to be used by people who like to understand their PC from the most basic level up. Arch support channels will assume you installed using the Arch Installation Guide and so you know exactly what software you have installed and understand how it is configured - but you can configure it in any way you want. The Arch approach is essentially a "social contract" that people installing the OS agree to.

Garuda takes almost the opposite approach and instead provides an opinionated setup that is intended to work in a particular way. If you like what it offers then it works well, but when you start manually making changes or configuring things yourself then you can end up breaking the underlying tooling (e.g. you decide to install on ext4 instead of btrfs, or decide you don't like the snapshot feature and try to remove it, ...).

This is not to say that you can't make changes to your Garuda installation if you know what you are doing, but if you are intentionally removing Garuda features then you should probably be using a more "vanilla" Arch and adding to it, rather than breaking down all the work that the Garuda maintainers have done. One option would be to use the "barebones" installer that provides a base Garuda installation without a lot of extra software, and the other, assuming you don't want to install "the Arch way", is to use a distribution like EndeavourOS which intentionally sets out to be an unopinionated Arch derivative.

So, the "spectrum of opinionatedness" would look something like this:

Arch <-> EndeavourOS <-> Garuda


As I mentioned a few months back I have been working on informational hooks and a service to provide informational alerts for new users. I have written 3 hooks and a service to aid new users in learning how to maintain their system properly.

Anyone wishing to test a version of my post transaction hook and script that I've written please feel free to test it out to see the beautified output messages it provides at the end of the update process. Any feedback would be appreciated. Bare in mind it is still in the testing phase. I have been testing it in conjunction with 2 pre-transaction update hooks and a service. The service will provide further info such as if new update notices have been released and if a reboot will be required after update completion. The code is still messy, unfinished and a work in progress. I'm no pro coder, so don't laugh too loudly at it's current messy state.

The post transaction hook and script for those who'd like to test this version is as follows:

Create and save the following post transaction hook:


The hook contents:

#cat /etc/pacman.d/hooks/upgrade-adviser.hook

Operation = Install
Operation = Upgrade
Operation = Remove
Type = Package
Target = *

Description = Check for pac* files and alien/orphaned packages ...
When = PostTransaction
Exec = /usr/bin/bash /etc/pacman.d/hooks.bin/upgrade-adviser.sh

The script that the hook launches is as follows:


Script contents:

#!/usr/bin/env bash
#cat /etc/pacman.d/hooks.bin/upgrade-adviser.sh
uid="$(find /run/user/ -maxdepth 1 -mindepth 1 -type d | awk -F/ '{print $NF}')"
user="$(grep $uid /etc/passwd  | sed 's/:.*//')" 
display="$(DISPLAY=$(echo "$DISPLAY"))"
xauth="$(XAUTHORITY=/home/$(grep $uid /etc/passwd  | sed 's/:.*//')/.Xauthority)"

export XAUTHORITY=/home/$user/.Xauthority
#export DISPLAY=:0
export DISPLAY=$(echo "$DISPLAY")
export DBUS_SESSION_BUS_ADDRESS="unix:path=/run/user/$uid/bus"

su $(grep $uid /etc/passwd  | sed 's/:.*//') -c "DISPLAY=$(echo "$DISPLAY") $(XAUTHORITY=/home/$(grep $uid /etc/passwd  | sed 's/:.*//')/.Xauthority) DBUS_SESSION_BUS_ADDRESS=unix:path=/run/user/$uid/bus XDG_RUNTIME_DIR=/run/user/$uid notify-send  'Important update safety announcements to follow'"

pacfiles="$(pacdiff -o)"
orphans="$(pacman -Qtd | awk '{ print $1 }')"
default='\033[0m' # Default Color

# disable the 3 earlier Garuda hooks that this script replaces.
# comment out the 3 commands below after first run (not required).
mv /etc/pacman.d/hooks/pacnew-check.hook /etc/pacman.d/hooks/pacnew-check.hook.bak >/dev/null 2>&1 || true 
mv  /etc/pacman.d/hooks/orphans.hook  /etc/pacman.d/hooks/orphans.hook.bak >/dev/null 2>&1 || true 
mv  /etc/pacman.d/hooks/foreign.hook  /etc/pacman.d/hooks/foreign.hook.bak >/dev/null 2>&1 || true 
# Create a Unix timestamp file to identify when the update was completed.
# sudo -Hiu $user sh -c "/usr/bin/echo -e "$(date +%s)" > /home/$user/.local/cache/last-upgrade.log" >/dev/null 2>&1 || true 

# cancel if run in a tty
case $(tty) in /dev/tty[0-9]*)
    exit 0 ;;
    printf "\n"
echo -e "${blue}* * *     * * *     * * *     * * *     * * *${default}"            # blue colored output divider
    printf "\n"
echo -e "${yellow}Return a list of all orphaned packages detected in the system ...${default}"      # yellow colored textual output
    printf "\n"
echo -e "${orange}$orphans:${default}\n"        # orange colored output, (package version numbers stripped).
if [ $? -eq 0 ]; then
    echo -e "${yellow}Double check package dependencies before uninstalling ...\n${default}"      # yellow colored textual output
    echo -e "${lt_green}No orphaned packages detected in the system ...\n${default}"       # light green colored textual output
echo -e "${blue}* * *     * * *     * * *     * * *     * * *${default}"            # blue colored output divider
printf "\n"; echo -e "${lt_green}Return a list of all AUR (foreign/alien) packages installed on the system ...${default}"      # green colored textual output
    printf "\n"
echo -e "${green}$(pacman -Qm | awk '{ print $1 }')${default}"  
if [ $? -eq 0 ]; then
    printf "\n"; echo -e "${lt_green}Ensure that all AUR packages are updated to prevent breakages ...\n${default}"      # green colored textual output
    echo -e "${lt_green}No foreign packages detected in the system ...${default}"      # light green colored textualual output
echo -e "${blue}* * *     * * *     * * *     * * *     * * *${default}"            # blue colored output divider
if [[ -n "pacfiles" ]]; then
    printf "\n"; echo -e "${red}.pac* file(s) detected in the system ...${default}\n"      # red colored textual output
    ## new experimental lines below:
    # rm /tmp/pac-files.log 2> /dev/null || true   
    # pacdiff -o | tee /tmp/pac-files.log >/dev/null 2>&1 || true 
    # sudo -u $user bash -c "cat  /tmp/pac-files.log > /home/$user/.local/cache/check-pac-files.log"
    echo -e "${red}$pacfiles:${default}\n"      # red colored textual output

    su $user -c  "$display $xdg_rd $xauth $dbus_sba /usr/bin/notify-send --urgency=critical 'Pac* files have been detected, most pacnew files should be merged, (very rarely immediately)'"


    echo -e "${red}Most pacnew files require merging ...${default}"      # red colored textual output
    printf "\n"
    echo -e "${red}Rarely pacnew files may require merging immediately ... ${default}"      # red colored textual output
    printf "\n"
    echo -e "${red}Information regarding merging pacnew files can be found at the following links:${default}"      # red colored textual output 
    printf "\n"
    # the websites below can be replaced with Garuda specific content once it has been created.
    # the links below are in purple colored text.
    echo -e "${purple}https://wiki.archlinux.org/index.php/Pacman/Pacnew_and_Pacsave${default}" 
    printf "\n"
    echo -e "${purple}https://wiki.archlinux.org/index.php/System_maintenance#Deal_promptly_with_new_configuration_files${default}"
    printf "\n"
     echo -e "${lt_green}No pacnew or pacsave files found in the system ...${default}"       # light green colored textual output
echo -e "${blue}* * *     * * *     * * *     * * *     * * *${default}"            # blue colored output divider
printf "\n"

Make the script executable:

chmod +x /etc/pacman.d/hooks.bin/upgrade-adviser.sh

The script is still very messy as and it contains a lot of commented out functions that were for testing or are planned for future integration with the service. The first popup message is really only for testing purposes. The only popup that will occur with this script is when pac* files exist.

You don't need to create the hook to test the scripts functionality, but it would be most helpful if others tested it out under actual update conditions.

If you feel like testing this out, or simply have comments or suggestions about my code please feel free to post comments here.


I'm all for helpful hooks - so if you want some more testing I have a few builds up (Garuda, Arch, EndeavourOS) to see what they do. In fact I have borrowed a few hooks from Garuda, and added in some of my own home-brews for things like maintaining package counts for conky display... Do you have them as a set - or just the pieces described here?

What kind of maintenance needs to be done for Arch based distros? (not expecting a full response as a reply here, links to other resources work too)

1 Like

From my experience as a user that doesn't know much about programming the maintenance isn't too bad.

You need to update using pacman -Syu relatively regularly
You need to be able to intervene when there is an error in upgrading packages. Usually this info can be figured out on news.archlinux.org. Here is an example: Arch Linux - News: hplip 3.20.3-2 update requires manual intervention. Manual intervention required to upgrade is typically rare.

The biggest issue I would say is dealing with the implications of the updates. For example, when I upgrade it can sometimes bork system functionality or cause issues. The biggest case where I've seen this is when new kernels/Nvidia Drivers release.

With every new major kernel/nvidia driver upgrade, it is an experiment to see if it works(you're one of the first real users to test the software!). Most of the time it does, but the occasions where it doesn't can be infuriating. For example, this morning I was having some crazy sluggishness and weird errors. At first, I tried switching kernel versions(5.11 to 5.10), but that didn't fix the issue. In the end, I offhandedly ran sudo pacman -Syu and it had an upgrade for opencl-nvidia and lib32-opencl-nvidia. After installing that and rebooting, the issues seemed to have resolved.

You need to have a problem-solving and mildly technical mind to figure out these sort of problems and you need to be able to drop everything and fix it(or perhaps don't install upgrades while you are in online school, like I foolishly did.)


I found maintenance after the first few days of tweaking to be quite simple really. As long as you don't make huge tweaks. Keeping it upto date daily saves a lot of headache. Since there is less chance of components breaking. Especially if you have common hardware and well supported hardware like my rx470 and ryzen 5 1600 drivers aren't an issue at all. I've only ever had issues with ultra low end PCs. As a general rule of thumb you might need to add a few packages like drivers and kernels that can cause system instability after update to the ignore package list and update them manually when you got time.


And don't forget you may need to have the knowledge to resolve packaging issues, like recently where pulseaudio was replaced by pipewire in most Arch based distros. You should either keep up with ongoing issues and/or be willing to research a bit on your own. And I hate signing issues (lol).


That’s awesome.

Yes, I have 2 more related hooks, as well as an interrelated service. The first hook /etc/pacman.d/hooks/00-adviser-1.hook is for setting a timestamp file for when a minor update commences. The second hook is for creating a timestamp file for when a major update that likely requires a reboot commences. I’m sure these hooks wouldn’t interest you, unless you wanted to test out the service that they were created for. The service is still not quite ready as far as all the features i"d like to add but it is quite functional as I’ve been using it for months. I’m just not at the point where I’d want to release the code for wide spread testing quite yet. I’ll shoot you a PM regarding the service @freebird54 .

Regarding maintenance there are a lot of not so obvious things that if left too long could cause problems, such as merging pacnew files. Also removing orphans, checking your crashdump logs to see if they are becoming massive because of an ongoing problem, balancing your btrfs drive. I could probably think of a lot more if I thought on it.