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.
