It is recommended to perform full system upgrades regularly, to enjoy both the latest bug fixes and security updates, and also to avoid having to deal with too many package upgrades that require manual intervention at once.

It is recommended to perform full system upgrades regularly, to enjoy both the latest bug fixes and security updates, and also to avoid having to deal with too many package upgrades that require manual intervention at once.

−

See [[Pacman#Upgrading packages]] for details. To revert upgrades causing instability, see [[Downgrading packages]].

+

See [[Pacman#Upgrading packages]] for details.

If the system has packages from the [[AUR]], carefully upgrade all of them.

If the system has packages from the [[AUR]], carefully upgrade all of them.

Line 90:

Line 90:

If possible, test changes to configuration files, as well as updates to software packages, on a non-critical duplicate system first. Then, if no problems arise, roll out the changes to the production system.

If possible, test changes to configuration files, as well as updates to software packages, on a non-critical duplicate system first. Then, if no problems arise, roll out the changes to the production system.

+

+

=== Revert broken updates ===

+

+

If a package update is expected/known to cause problems, packagers will ensure that pacman displays an appropriate message when the package is updated. If experiencing trouble after an update, double-check pacman's output by looking at the log (/var/log/pacman.log).

+

+

At this point, only after ensuring there is no information available through pacman, there is no relative news on https://www.archlinux.org/, and there are no forum posts regarding the update, consider seeking help on the forum, over IRC, or [[Downgrading packages|downgrading]] the offending package.

Avoid certain pacman commands

Avoid using the --force option with pacman, especially in commands such as pacman -Syu --force involving more than one package. The --force option ignores file conflicts and can even cause file loss when files are relocated between different packages! In a properly maintained system, it should never need to be used.

Do not use pacman -Rdd package. Using the -d flag skips dependency checks during package removal. As a result, a package providing a critical dependency could be removed, resulting in a broken system.

Partial upgrades are unsupported

Arch Linux is a rolling release, and new library versions will be pushed to the repositories. The developers and Trusted Users will rebuild all the packages in the repositories that need to be rebuilt against the libraries. If the system has locally installed packages (such as AUR packages), users will need to rebuild them when their dependencies receive a soname bump.

This means that partial upgrades are not supported. Do not use pacman -Sy package or any equivalent such as pacman -Sy followed by pacman -S package, always upgrade (with pacman -Syu) before installing a package. Be very careful when using IgnorePkg and IgnoreGroup for the same reason. Summary: always use pacman -Syu instead of pacman -Sy.

If a partial upgrade scenario has been created, and binaries are broken because they cannot find the libraries they are linked against, do not "fix" the problem simply by symlinking. Libraries receive soname bumps when they are not backwards compatible. A simple pacman -Syu to a properly synced mirror will fix the problem as long as pacman is not broken.

The bash script checkupdates, included with the pacman package, provides a safe way to check for upgrades to installed packages without running a system update at the same time.

Configuration files

Before editing any configuration files, create a backup. This way, you can revert to a working version in case of problems. Editors like vim and emacs can do this automatically, as well as tools like etckeeper which keep /etc in a version control system (VCS).

Periodically clean configuration files

Old configuration files may conflict with newer software versions, or corrupt over time. Remove unneeded configurations periodically, particularly in your home folder and ~/.config. For similar reasons, be careful when sharing home folders between installations.

Remove old files in the $HOME directory to simplify finding configuration and other useful files. Look for the following folders:

~/.config/ -- where apps stores their configuration

~/.cache/ -- cache of some programs may grow in size

~/.local/share/ -- old files may be lying there

Note: These paths are defaults for $XDG_CONFIG_HOME, $XDG_CACHE_HOME and $XDG_DATA_HOME environment variables respectively. Check your configuration if you use different paths.

Logfiles

Upgrading the system

It is recommended to perform full system upgrades regularly, to enjoy both the latest bug fixes and security updates, and also to avoid having to deal with too many package upgrades that require manual intervention at once.

If the system has packages from the AUR, carefully upgrade all of them.

Read before upgrading the system

Before upgrading Arch, always read the latest Arch News to find out if there are any major software or configuration changes with the latest packages. Before upgrading fundamental software (such as the kernel, xorg, systemd, or glibc) to a new version, look over the appropriate forum to see if there have been any reported problems.

Act on alerts during an upgrade

When upgrading the system, be sure to pay attention to the alert notices provided by pacman. If any additional actions are required by the user, be sure to take care of them right away. If a pacman alert is confusing, search the forums and the recent news posts for more detailed instructions.

Deal promptly with new configuration files

When pacman is invoked .pacnew, .pacsave, and .pacorig files can be created. Pacman provides notice when this happens and users must deal with these files promptly. Users are referred to the Pacnew and Pacsave files wiki page for detailed instructions.

Also, think about other configuration files you may have copied or created. If a package had an example configuration that you copied to your home directory, check to see if a new one has been created.

Test updates on a non-critical system

If possible, test changes to configuration files, as well as updates to software packages, on a non-critical duplicate system first. Then, if no problems arise, roll out the changes to the production system.

Revert broken updates

If a package update is expected/known to cause problems, packagers will ensure that pacman displays an appropriate message when the package is updated. If experiencing trouble after an update, double-check pacman's output by looking at the log (/var/log/pacman.log).

At this point, only after ensuring there is no information available through pacman, there is no relative news on https://www.archlinux.org/, and there are no forum posts regarding the update, consider seeking help on the forum, over IRC, or downgrading the offending package.

Install the linux-lts package

The linux-lts package is an alternative Arch kernel package, and is available in the core repository. This particular kernel version has long-term support (LTS) from upstream, including security fixes and some feature backports. It can be used by those who want a fallback kernel in case a new kernel version causes problems.

To make it available as a boot option, you will need to update the bootloader's configuration file. For Syslinux, you have to edit /boot/syslinux/syslinux.cfg and duplicate the current entries, except using vmlinuz-linux-lts and initramfs-linux-lts.img. For GRUB, the recommended method is to automatically re-generate the configuration file.

Warning: Do not be tempted to perform partial updates, as they are not supported by Arch Linux and may cause instability: the whole system should be upgraded when upgrading a component. Also note that infrequent system updates can complicate the update process.

Use the package manager to install software

Pacman does a much better job than you at keeping track of files. If you install things manually you will, sooner or later, forget what you did, where you installed to, install conflicting software, install to the wrong locations, etc.

From a stability standpoint you should try to avoid unsupported package and custom software, but if you really need such things making a package is better than manually compiling and installing.

Use proven software packages

Install mature and proven software, while avoiding cutting edge software that is still buggy. Do not deploy newly developed software until it is proven to be reliable. Use software that has a strong and active development community, as well as a high number of competent users.

Avoid any use of the testing repository, or individual packages from testing. These packages are experimental and not suitable for a stable system.

Unless recommended explicitly, do not install any development packages. These are usually found in AUR, occasionally in the community repository, and are packages taken directly from upstream development branches. They usually feature one of the following words appended to the package name: "dev", "devel", "svn", "cvs", "git", "hg", "bzr", or "darcs". In particular, avoid installing development versions of crucial system packages such as the kernel or glibc.

Choose open-source drivers

Wherever possible, choose open source drivers. Try to avoid proprietary drivers. Most of the time, open source drivers are more stable and reliable than proprietary drivers. Open source driver bugs are fixed more easily and quickly. While proprietary drivers can offer more features and capabilities, this can come at the cost of stability. To avoid this dilemma, choose hardware components known to have mature open source driver support with full features. Information about hardware with open source Linux drivers is available at linux-drivers.org.

Be careful with unofficial packages

Use precaution when using packages from the AUR or an unofficial user repository. Most are supplied by regular users and thus may not have the same standards as those in the official repositories. Be careful with AUR helpers which highly simplify installation of AUR packages. Always check PKGBUILDs for sanity and signs of mistake or malicious code before building and/or installing the package.

To simplify maintenance, limit the amount of unofficial packages used. Make periodic checks on which are in actual use, and remove (or replace with their official counterparts) any others. See pacman/Tips and tricks#Maintenance for useful commands.

Update the mirrorlist

This section is being considered for removal.

Reason: Not part of the system cleanup as in other sections. [edit: when this was written, this section was not well separated from tasks in #Clean filesystem] Already recommended at multiple other places. (Discuss in Talk:Pacman#Don.27t_rush_updates)

Update pacman's mirrorlist, as the quality of mirrors can vary over time, and some might go offline or their download rate might degrade.