New users start here (aka. the never-complete Beginner's Guide to Cachy)

FAQ and Tutorials
1

Hello and welcome to the wonderful world of CachyOS!

While Cachy makes it look pretty easy to run an Arch-based system, well… it still is an Arch-based system and that means you are the maintainer and administrator of your own operating system.

Which is cool, but with great power comes great responsibility, so before you jump straight into ricing your system, here are some topics you might want to look into first.

This list is not comprehensive and probably partly objective, but it should help you with your first steps in CachyOS and its forum.

Generally speaking

  • The Arch Wiki is your best source of knowledge regarding Arch and Linux in general.
  • The Cachy Wiki contains all Cachy-specific nuances on top of the Arch base. You might find this FAQ page especially helpful.
  • Read those wikis, they might already answer your question.
  • Activate the magic SysRQ REISUB keys on your system! This is much better than just pressing the power button when your system is unresponsive. For more technical info on that, read here.
  • You can (almost) always go to a TTY with the key combination CTRL + ALT + F3 (or F4, F5 and so on). From there, you might be able to do some magic. You can come back to your desktop session with CTRL + ALT + F2
  • Make sure you have BTRFS snapshots enabled. If you don’t want to use the BTRFS filesystem, you might want to get accustomed with Timeshift. Restoring a snapshot is way easier than manually trying to recover from whatever is your issue.
  • Familiarize yourself with the idea of backing up your system and your personal files. My personal approach is this one, but that might be a bit to techy for some folks.
  • Consider writing a “diary”, where you note down the changes you did to your system. It will help you to retrace your steps in case something breaks.
  • If you use Linux, learn how to troubleshoot.

Recovering your system when something broke

  • Yes, that might actually happen and chances are it was you who caused that but luckily, there is already a whole post on that topic covering basically everything you need to know right now.

System Maintenance

  • Best tip from my personal experience: read the Arch wiki page on maintenance first.
  • When and how often to update your system is a philosophical question with as many answers as there are users out there. If you ask me: do it about once a week when you feel you have the time to look into problems. I’m not saying there will be problems, but should they arise, they might take some time to be taken care of.
  • Get familiar with pacman. Like, really.
  • The best way to update your operating system is by running one of these commands:
    • sudo pacman -Syu: this will update the pacman database and then run a full update on all the “regular” packages in your system,
    • paru -Syu: this will do the same but will also update all packages you might have installed from the AUR (more on that later).
    • cachy-update: this will do about the same as the two previous commands combined, plus it will show you Arch News (if there are any) and it will do some cleaning later on.
    • I know there are people out there who will tell you of things like topgrade or pamac or whatnot, but from what I’ve seen in this forum, I would not touch any of those tools with a ten-foot-pole.
  • You might want to rate your mirrors every now and again to make sure you get the packages from a mirror near to where you are. The current version of CachyOS comes with a script called cachyos-rate-mirrors which is automatically run periodically with a service. I admit that I’m not a big fan of that so I disabled it.
    That said, to rank your mirrors run one of these commands:
    • rate-mirrors: the “regular” way to rank your mirrors
    • cachyos-rate-mirrors: the same but with some special Cachy-mirrors baked into it
    • or you may try out @cscs 's refremir script.
  • Consider using @cscs 's maclean script to free your disk of garbage.
  • Make yourself familiar with .pacnew and .pacsave files. Now that is an advice I wish someone gave me right from the start. To quote the Wiki:

    When pacman removes a package that has a configuration file, it normally creates a backup copy of that configuration file and appends .pacsave to the name of the file. Likewise, when pacman upgrades a package which includes a new configuration file created by the maintainer differing from the currently installed file, it saves a .pacnew file with the new configuration. pacman provides notice when these files are written.

    • The one and only way to handle these files is manually and in a concentrated manner! Never blindly overwrite any config file with a .pacnew file!! That would be a recipe for disaster.
    • Use pacdiff -s to go through the list of .pacnew files and handle them one by one. When in doubt, use Q to quit the process and ask in the forum before rushing things.
    • You may use the following command to set a better diff tool (provided that meld is installed) :
      DIFFPROG=meld pacdiff -s
  • Finally, here are some videos that helped me to get a grip on Arch and Linux:

Using the Cachy forum

  • Please search before you post. Get accustomed to the ‘Advanced Filters’ functionality to find posts with an approved solution only. If there is a solution to your problem, there is no need for a new post.
  • Read the CachyOS FAQ & Troubleshooting Guide before posting, there is a large section on how to properly report errors.
  • Take a look into the Announcements every now and again. For me, the pinned articles do not always work properly, so make sure to actually go into the category at least one a month.
  • Write in English. If English is not your strength, there are plenty of translation services on the internet. The language here is English and you will have the best chances to get an answer if you respect that.
  • When posting error messages or console output, please paste the text and format it with the </> button. Please refrain from posting screenshots of your terminal.
  • Write a meaningful title to your post. Make sure the title actually contains your problem or whatever it is that you want to bring across. Avoid clickbaity titles.
    • Good examples:
      • “Steam Memory leak causing crash (wine: Unhandled page fault)”
      • “Can’t run .AppImage’s. Getting “fish: unknown command””
      • “Pacdiff v shows a lot of errors in cachyos-mirrorlist file”
    • Bad examples:
      - “Help”
      - “Everything was fine until”
      - “DaVinci Resolve Studio”
      - “Mal so ne Frage”

Regarding the Arch User Repository (AUR)

One of the best and worst things about Arch Linux is the AUR.

The best, because you might get packages there that are not officially in the repos.

The worst, because

So if you ask me, I avoid the AUR as best as I can, but of course your mileage may vary.

Never forget to have some fun with your OS

Oh boy, this list is already too long, don’t you think? :sweat_smile: I’ll stop here for now.

2

Activate the magic SysRQ REISUB keys on your system! This is much better than just pressing the power button when your system is unresponsive.

the link you linked here leads to the “Show your Screenshots” thread, could you elaborate on this?

3

Oops. Good catch, thanks! Will correct that right now!

4

this is a very helpful article, even I understand all of this post - however I did have a question about this part I qouted.

if its no trouble could you explain it to me?

What other tools are there for managing these save files?

could you give an example of using the command mentioned?

5

Lots. They are called diff tools, because they show you the differences of two (presumably) text files. Some of those tools (like meld or kompare) are also capable of diffing whole folder structures while others (like BeyondCompare) are even capable of diffing pictures, office files and whatnot. But for the sake of simplicity, I will stick to diffing simple text files.

To my surprise, the documentation of meld is very sub-par, as it explains how to use the tool but does not show you how to do so.

Luckily, these tools are widely used throughout the IT universe, so here is one fine video tutorial on meld or if you prefer to read about it, you may take a look at this.

Basically speaking, you see one text file on the left and one on the right, with graphical hints on which lines are equal, which lines have changes, which were added or deleted.

It might be bit of a learning curve when you have never used such tools, but once you get the hang of it, they are a walk in the park for simple changes, whereas more complex changes still fry my brain and I’m using these tools since ~25 years now :sweat_smile:

If for example your mirrorlists are affected by pacnew, there may be impossible-to-solve differences, because when you used a tool like cachyos-rate-mirrors, that tool would have completely turned the default mirrorlist inside out, so the “latest, original” mirrorlist from the repo will look 100% different, even if the content will not have changed too drastically, but the order of the lines has. In that case, I personally overwrite the mirrorlist with the pacnew file, then rate the mirrors again. But that is my personal preference only.

could you give an example of using the command mentioned?

Can’t say much there, I’m afraid. This command:

DIFFPROG=meld pacdiff -s

means

  • set the environment variable DIFFPROG to meld
  • then call pacdiff with the -s parameter (meaning that it will use sudo to run the difftool, because many of the config files in linux are owned by root and you need to become a superuser (su) to change them)

pacdiff goes through the list of all existing *.pacnew and *.pacsave files and diffs them with the diffprog you set in the variable (meld in this case).

If there are none of these files, then pacdiff just does nothing. You may just view the list of current pacnew and pacsave files with

pacdiff -l

but of course, all of that is explained in the pacdiff man page (man pages are a topic I missed in the OP, maybe I should add them, too :wink: )

6

oh thats cool! thank you for explaining it, that makes sense.

7

:sign_of_the_horns:

The number one thing to remember sbout .pacnew files is that they are only created if your existing file doesn’t match the previous default**.**

If your old setting is just the old default…pacman will just update. The only reason .pacnews exist is because you or some program** changed the configuration** - and you normally (almost always) want to maintain that change.

We keep seeing new people “handle” .pacnew files in probably the worst way possible - never just copy/apply a .pacnew - the only reason a .pacnew exists at all is because the system has identified that it’s not safe to just apply the new default settings.

8

All stated in the linked Arch wiki page but yeah, sure, totally true :slight_smile:

9

given how many people just yolo it I figured it worth being explicit and standalone that .pacnew files omly exist because the system deemed applying the “new” settings unsafe.

11

@HardCode4All

I think that there is a typo in your post: “backing up up your system”

Screenshot_20260625_093253

12

Not for long :wink: good catch, thanks!

13

Thank you so much for the .pacnew part. I’ve been aware that these files exist but I never bothered to check what I’m supposed to do with them. Turns out I had a few months of unmerged changes waiting for me!

14

Well written, there is indeed some pretty good advice in here!