I have spent a lot of time over the last 8 years helping people fix their broken systems and seeing people constantly describe how much trouble it is to keep their Arch-based systems running. Meanwhile, even though I run many systems with different configs, I never actually have these problems myself.1 I have helped people with so many obscure issues that if I ever did have issues with systems failing after an update I could fix them myself without too much trouble in most cases. However, I donât have to. I donât have those issues on my normal systems.2 Is this because I am some kind of Linux techno-ninja? No. I am not doing anything special or using any special skills or deep knowledge. I use my day to day systems the same as everyone else does. In fact, I generally have more complicated setups that should be more prone to breakage.
Lately I have been thinking about why this is and that led me to start thinking about all the things that cause breakage or cause frustration for other people. I think there are some things people do that make it more difficult and/or stressful than it needs to be. I made a list of these things, hoping that it would help people who want a system that âjust worksâ without having to worry about it overly.
First, I will warn you that some of these things go against what other guides and tutorials will recommend you do. Someone is bound to pop in and say I do âinsert thing hereâ and have never had a problem. Maybe that is luck, maybe there is some other factor. These are based on my personal experiences and my experience helping others fix problems. Second, if you have a good level of expertise or prioritize fun over stability donât follow these. Instead, do what you enjoy. These arenât must do items that will cause a failure if you donât do them. They are things that increase your chances of not having a failure in the first place.
In order of importance:
- Use the LTS kernel - No seriously. Unless you have a specific reason not to use the LTS kernel, use it. It is very common for new kernels to have issues with certain hardware or configurations. The LTS kernel protects you from 90% of these issues.
- Uninstall your update notifier - I often see people switching distros due to the frequency of updates and the stress caused by it. Arch streams constant updates in, but you donât need to update all the time. There is no good reason to use an update notifier on Arch. There will almost always be updates. It is OK to ignore them. Personally, I update about twice per month. I would recommend updating at least once per month but otherwise whenever you feel like it. You can install
arch-audit-gtkto ensure you are not missing any security updates. - Install only a single DE/WM - You only need one, trust me. Most of us go through a phase of having multiple DEs/WMs. It can be fun at first to try out a bunch and switch between them. However, most of us also learn three things in that process. Having more than one causes lots of little inconsistencies since they tend to step on each other in small ways, it actually isnât a great way to test DEs because you are introducing breakage that otherwise wouldnât be there and, lastly, you never really know if the issues you see are caused by a bug or the fact that you have/had multiple DEs installed. Use a VM or a second machine to test new DEs. Also, you donât need a âbackup DEâ.
- Let your updates finish before rebooting - A decent amount of the issues we see people having with their systems is caused by not letting updates finish. There are processes that run at the end of the of the update process that are critical to the boot process.
- Make sure your root partition doesnât become completely full - This one is pretty obvious. Donât let your root partition fill up. If it happens during an update, it can cause some serious havoc that can be hard to recover from
- Use a simple partition layout - Want to know a great way to avoid your partitions from filling up? Have less of them. Just have a single partition with
/and an EFI partition. Add a swap partition if you want/need one. Splitting your free space between partitions just makes storage management more complicated. - Use a simple system configuration - The simpler your system is, the less prone it is to breakage. This is general advice but one example would be using btrfs, grub and snapshot booting. People often do this so they can more easily roll back from failures. However, this setup adds complexity and increases your chance of having failures in the first place. Complexity is a balancing act. Keep it as simple as you can to achieve your goals.
- Donât re-use
/home- People will often tell you to have a separate partition for/home. IMO, this is terrible advice. You should never share/homebetween distros. Even with the same distro, it typically doesnât make sense to re-use it. If there is some problem that causes you to reinstall, the issue is just as likely to be in/homeas outside of it. If you want to preserve or share your personal data, instead, create a partition or subvolume that contains your user data and then mount or symlink the data to~/Documents,~/Videos,~/Picture, etc. - Have some amount of swap - If you completely run out of memory, your system hard crashes. This is bad. Having some swap will decrease the chance of this happening. It doesnât matter if it is zram, a swapfile or a swap partition. Just have some swap.
- Donât reset or hard power off your system - It causes filesystem corruption and other issues. Donât so it. Be sure to enable Sysrq which allows you to use REISUB if your system freezes.
- Donât install packages you donât use - The more packages you have, the more complicated updates become. This is especially true for AUR packages that may be tied to specific library versions creating problematic dependencies. To be clear, I am not advocating for maniacally removing packages. Just install the software you actually use and remove the stuff you donât.
- Donât use 3rd party repositories - In addition to all the risks associated with these repos, they also make updates more complicated and are often the cause of issues.
- Donât use
*-gitpackages without a reason - These packages usually pull from the latest source code in a repo. In addition to the fact that this means more frequent updates, this code is usually unreleased and often untested. There are of course, exceptions. Sometimes things like theming will only have a git package because the theme owners donât actually do releases. - Use a minimal maintenance routine - People often ask how I maintain my system. I do three things. When using advanced filesystems, I setup a scheduled job automate those tasks on a monthly basis. I remove orphans a few times per year. I update the system a couple of times per month. That is it. I donât clean my package cache, I donât merge pacnew files. I donât prune the logs or anything else. To be clear, I am not saying never to do any of these things. You may need to do some of them(Like pruning your package cache if you are low on disk space). However, too many people break their systems trying to maintain them. Keep it minimal.
- Donât use bleachbit and friends - This is an extreme version of the above point. These tools often âover cleanâ and break your system or applications.
- Read the questions pacman asks you - Donât just hit the enter button and accept the default choice. Especially when you are installing or removing software. Often those questions are important.
- Donât multi-boot - Yes, it can be fun to run a bunch of different OSes but it also makes things more complicated and more prone to breakage.
- If you multi-boot, donât use os-prober -
os-proberis imperfect. If you multi-boot, either use systemd-boot, grub with manual stanzas or refind with manual stanzas. When using grub or refind, I recommend chain-loading. It may be an extra click or an extra couple of seconds at boot but it is 100% reliable with all UEFI installs. - Donât follow advice you donât understand - Typing commands a random stranger on the internet gives you is a bad idea. Typing commands from a random Reddit post that may or may not be related to your issue is even worse. If you donât understand what a command does, ask someone to explain it.
- Use common, mainstream hardware - Sometimes, we donât have the luxury of choosing hardware. However, when you do have the choice, use common mainstream hardware that is well supported in Linux. Avoid newly released hardware when possible.
Bonus - Maintain backups - This doesnât make your system more reliable. However, having backups can be the difference between a really bad day and a minor bump in the road. Always have backups.
The reality is that most of this stuff is true for any distro. With a few small exceptions, you can treat EOS/Arch like a non-rolling distro if you want to.
That being said, an Arch-based distro isnât for everyone and there are some times when you just shouldnât use one
- You are extremely bandwidth constrained - Arch, being a fast moving distro will see a lot more long-term bandwidth usage than an LTS distro. If this is a concern, something based on Debian stable, Ubuntu LTS or RedHat is probably a better choice
- You update less than once per month - If you canât update at least once every month-ish, you may be better off with a non-rolling distro.
- The primary user of the device wants a completely hands-off automated experience - If the person using the OS doesnât want to ever see the terminal or think about the minor questions that pop-up during an update or software install you are probably better off with something that supports that use-case better. Solus, PopOS or Linux Mint for example.
- You need commercial support for your applications - Very few commercial applications officially support Arch. Often, this is because it is pretty hard to test and certify something that is constantly changing.
- You prefer your applications to not change - If you hate when applications change and new features mess up the menu layout you are used to, you are better off with a distro that doesnât get new application versions as often
1 - Do I occasionally have minor issues introduced by getting the latest software? Yes. But these are usually annoyances, not system breaking issues.
2 - I do a lot of development and testing so I often create expected breakage that I need to fix. However, that is in VMs where I am deliberately doing those things.
