Arch linux update all

System maintenance

Regular system maintenance is necessary for the proper function of Arch over a period of time. Timely maintenance is a practice many users get accustomed to.

Contents

Check for errors

Failed systemd services

Check if any systemd services have failed:

See systemd#Using units for more information.

Logfiles

The factual accuracy of this article or section is disputed.

Look for errors in the log files located at /var/log , as well as high priority errors in the systemd journal:

See systemd/Journal for more information.

See Xorg#Troubleshooting for information on where and how Xorg logs errors.

Backup

Create backups of important data at regular intervals. See Synchronization and backup programs for many alternative applications that may better suit your case. See Category:System recovery for other articles of interest.

It is encouraged to automate backups, see Autostarting#On time events.

Configuration files

Before editing any configuration files, create a backup so that 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); see dotfiles#Tracking dotfiles directly with Git for more.

List of installed packages

Maintain a list of all installed packages so that if a complete re-installation is inevitable, it is easier to re-create the original environment.

Pacman database

Encryption metadata

System and user data

Upgrading the system

It is recommended to perform full system upgrades regularly via Pacman#Upgrading packages, 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. When requesting support from the community, it will usually be assumed that the system is up to date.

Make sure to have the Arch install media or another Linux «live» CD/USB available so you can easily rescue your system if there is a problem after updating. If you are running Arch in a production environment, or cannot afford downtime for any reason, 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 the system has packages from the AUR, carefully upgrade all of them.

pacman is a powerful package management tool, but it does not attempt to handle all corner cases. Users must be vigilant and take responsibility for maintaining their own system.

Read before upgrading the system

Before upgrading, users are expected to visit the Arch Linux home page to check the latest news, or alternatively subscribe to the RSS feed or the arch-announce mailing list. When updates require out-of-the-ordinary user intervention (more than what can be handled simply by following the instructions given by pacman), an appropriate news post will be made.

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.

Users must equally be aware that upgrading packages can raise unexpected problems that could need immediate intervention; therefore, it is discouraged to upgrade a stable system shortly before it is required for carrying out an important task. Instead, wait to upgrade until there is enough time available to resolve any post-upgrade issues.

Avoid certain pacman commands

Avoid doing partial upgrades. In other words, never run pacman -Sy ; instead, always use pacman -Syu .

Generally avoid using the —overwrite option with pacman. The —overwrite option takes an argument containing a glob. When used pacman will bypass file conflict checks for files that match the glob. In a properly maintained system, it should only be used when explicitly recommended by the Arch developers. See the #Read before upgrading the system section.

Avoid using the -d option with pacman. pacman -Rdd package 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 distribution. That means when new library versions are pushed to the repositories, the developers and Trusted Users rebuild all the packages in the repositories that need to be rebuilt against the libraries. For example, if two packages depend on the same library, upgrading only one package might also upgrade the library (as a dependency), which might then break the other package which depends on an older version of the library.

That is why partial upgrades are not supported. Do not use:

• pacman -Sy package
• pacman -Sy followed by pacman -S package .
• pacman -Syuw (Note that pacman -Syuw does imply the same risks like pacman -Sy , as it will update the pacman sync database without installing the newer packages.)

Always upgrade (with pacman -Syu ) before installing a package. Note that if pacman -Syu does not perform the upgrade because of an error, the end result is the same as running pacman -Sy . Therefore, the error must be resolved and the upgrade operation completed as soon as possible.

Be very careful when using IgnorePkg and IgnoreGroup for the same reason. If the system has locally built packages (such as AUR packages), users will need to rebuild them when their dependencies receive a soname bump.

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-contrib package, provides a safe way to check for upgrades to installed packages without running a system update at the same time.

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 and .pacsave files can be created. Pacman provides notice when this happens and users must deal with these files promptly. Users are referred to the Pacman/Pacnew and Pacsave 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.

Restart or reboot after upgrades

Upgrades are typically not applied to existing processes. You must restart processes to fully apply the upgrade.

The archlinux-contrib package provides a script called checkservices which runs pacdiff to merge .pacnew files then checks for processes running with outdated libraries and prompts the user if they want them to be restarted.

The kernel is particularly difficult to patch without a reboot. A reboot is always the most secure option, but if this is very inconvenient kernel live patching can be used to apply upgrades without a reboot.

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 /var/log/pacman.log .

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

Check for orphans and dropped packages

After upgrading you may now have packages that are no longer needed or that are no longer in the official repositories.

Use pacman -Qtd to check for packages that were installed as a dependency but now, no other packages depend on them. If an orphaned package is still needed, it is recommended to change the installation reason to explicit. Otherwise, if the package is no longer needed, it can be removed.

Additionally, some packages may no longer be in the remote repositories, but they still may be on your local system. To list all foreign packages use pacman -Qm . Note that this list will include packages that have been installed manually (e.g., from the AUR). To exclude packages that are (still) available on the AUR, use the ancient-packages AUR tool.

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, forget where you installed to, install conflicting software, install to the wrong locations, etc.

• Install packages from the official repositories using the method in the Pacman#Installing packages section.
• If the program you desire is not available, check to see if someone has created a package in the AUR. Follow the method in that article for installation.
• Lastly, if the program you want is not in the official repositories or in the AUR, learn how to create a package for it.

Choose open-source drivers

Always try open source drivers before resorting to 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, try to 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. Avoid AUR helpers which automate 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. Following system upgrade, use rebuild-detector to identify any unofficial packages that may need to be rebuilt.

Update the mirrorlist

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

See mirrors for details.

Clean the filesystem

When looking for files to remove, it is important to find the files that take up the most disk space. Programs that help with this are found in:

Package cache

Remove unwanted .pkg files from /var/cache/pacman/pkg/ to free up disk space.

Unused packages (orphans)

Remove unused packages from the system to free up disk space and simplify maintenance.

Old 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.

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

To keep the home directory clean from temporary files created at the wrong place, it is a good idea to manage a list of unwanted files and remove them regularly, for example with rmshit.py.

rmlint can be used to find and optionally remove duplicate files, empty files, recursive empty directories and broken symlinks.

Broken symlinks

Old, broken symbolic links might be sitting around your system; you should remove them. Examples on achieving this can be found here and here. However, you should not blindly delete all broken symbolic links, as some of them serve a purpose [1].

To quickly list all the broken symlinks of your system, use:

Then inspect and remove unnecessary entries from this list.

Tips and tricks

The following tips are generally not required, but certain users may find them useful.

Use proven software packages

Arch’s rolling releases can be a boon for users who want to try the latest features and get upstream updates as soon as possible, but they can also make system maintenance more difficult. To simplify maintenance and improve stability, try to avoid cutting edge software and install only mature and proven software. Such packages are less likely to receive difficult upgrades such as major configuration changes or feature removals. Prefer software that has a strong and active development community, as well as a high number of competent users, in order to simplify support in the event of a problem.

Avoid any use of the testing repository, even individual packages from testing. These packages are experimental and not suitable for a stable system. Similarly, avoid packages which are built directly from upstream development sources. These are usually found in the AUR, with names including things like: «dev», «devel», «svn», «cvs», «git», etc.

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 is useful if you prefer the stability of less-frequent kernel updates or if you want a fallback kernel in case a new kernel version causes problems.

Источник

pacman

The pacman package manager is one of the major distinguishing features of Arch Linux. It combines a simple binary package format with an easy-to-use build system. The goal of pacman is to make it possible to easily manage packages, whether they are from the official repositories or the user’s own builds.

Pacman keeps the system up-to-date by synchronizing package lists with the master server. This server/client model also allows the user to download/install packages with a simple command, complete with all required dependencies.

Pacman is written in the C programming language and uses the bsdtar(1) tar format for packaging.

Contents

Usage

What follows is just a small sample of the operations that pacman can perform. To read more examples, refer to pacman(8) .

Installing packages

A package is an archive containing:

• all of the (compiled) files of an application
• metadata about the application, such as application name, version, dependencies, etc.
• installation files and directives for pacman
• (optionally) extra files to make your life easier, such as a start/stop script

Arch’s package manager pacman can install, update, and remove those packages. Using packages instead of compiling and installing programs yourself has various benefits:

• easily updatable: pacman will update existing packages as soon as updates are available
• dependency checks: pacman handles dependencies for you, you only need to specify the program and pacman installs it together with every other program it needs
• clean removal: pacman has a list of every file in a package; this way, no files are unintentionally left behind when you decide to remove a package.

Installing specific packages

To install a single package or list of packages, including dependencies, issue the following command:

To install a list of packages with regex (see this forum thread):

Sometimes there are multiple versions of a package in different repositories (e.g. extra and testing). To install the version from the extra repository in this example, the repository needs to be defined in front of the package name:

To install a number of packages sharing similar patterns in their names one can use curly brace expansion. For example:

This can be expanded to however many levels needed:

Virtual packages

A virtual package is a special package which does not exist by itself, but is provided by one or more other packages. Virtual packages allow other packages to not name a specific package as a dependency, in case there are several candidates. Virtual packages cannot be installed by their name, instead they become installed in your system when you have install a package providing the virtual package.

Installing package groups

Some packages belong to a group of packages that can all be installed simultaneously. For example, issuing the command:

will prompt you to select the packages from the gnome group that you wish to install.

Sometimes a package group will contain a large amount of packages, and there may be only a few that you do or do not want to install. Instead of having to enter all the numbers except the ones you do not want, it is sometimes more convenient to select or exclude packages or ranges of packages with the following syntax:

which will select packages 1 through 10 and 15 for installation, or:

which will select all packages except 5 through 8 and 2 for installation.

To see what packages belong to the gnome group, run:

Also visit https://archlinux.org/groups/ to see what package groups are available.

Removing packages

To remove a single package, leaving all of its dependencies installed:

To remove a package and its dependencies which are not required by any other installed package:

The above may sometimes refuse to run when removing a group which contains otherwise needed packages. In this case try:

To remove a package, its dependencies and all the packages that depend on the target package:

To remove a package, which is required by another package, without removing the dependent package:

Pacman saves important configuration files when removing certain applications and names them with the extension: .pacsave. To prevent the creation of these backup files use the -n option:

Upgrading packages

Pacman can update all packages on the system with just one command. This could take quite a while depending on how up-to-date the system is. The following command synchronizes the repository databases and updates the system’s packages, excluding «local» packages that are not in the configured repositories:

Querying package databases

Pacman queries the local package database with the -Q flag, the sync database with the -S flag and the files database with the -F flag. See pacman -Q —help , pacman -S —help and pacman -F —help for the respective suboptions of each flag.

Pacman can search for packages in the database, searching both in packages’ names and descriptions:

Sometimes, -s ‘s builtin ERE (Extended Regular Expressions) can cause a lot of unwanted results, so it has to be limited to match the package name only; not the description nor any other field:

To search for already installed packages:

To search for package file names in remote packages:

To display extensive information about a given package:

For locally installed packages:

Passing two -i flags will also display the list of backup files and their modification states:

To retrieve a list of the files installed by a package:

To retrieve a list of the files installed by a remote package:

To verify the presence of the files installed by a package:

Passing the k flag twice will perform a more thorough check.

To query the database to know which package a file in the file system belongs to:

To query the database to know which remote package a file belongs to:

To list all packages no longer required as dependencies (orphans):

To list all packages explicitly installed and not required as dependencies:

Pactree

To view the dependency tree of a package:

To view the dependant tree of a package, pass the reverse flag -r to pactree, or use whoneeds from pkgtools AUR .

Database structure

The pacman databases are normally located at /var/lib/pacman/sync . For each repository specified in /etc/pacman.conf there will be a corresponding database file located there. Database files are gzipped tar archives containing one directory for each package, for example for the which package:

The desc file contains meta data such as the package description, dependencies, file size and MD5 hash.

Cleaning the package cache

Pacman stores its downloaded packages in /var/cache/pacman/pkg/ and does not remove the old or uninstalled versions automatically. This has some advantages:

1. It allows to downgrade a package without the need to retrieve the previous version through other means, such as the Arch Linux Archive.
2. A package that has been uninstalled can easily be reinstalled directly from the cache folder, not requiring a new download from the repository.

However, it is necessary to deliberately clean up the cache periodically to prevent the folder to grow indefinitely in size.

The paccache(8) script, provided within the pacman-contrib package, deletes all cached versions of installed and uninstalled packages, except for the most recent three, by default:

Enable and start paccache.timer to discard unused packages weekly.

You can also define how many recent versions you want to keep. To retain only one past version use:

Add the -u / —uninstalled switch to limit the action of paccache to uninstalled packages. For example to remove all cached versions of uninstalled packages, use the following:

See paccache -h for more options.

Pacman also has some built-in options to clean the cache and the leftover database files from repositories which are no longer listed in the configuration file /etc/pacman.conf . However pacman does not offer the possibility to keep a number of past versions and is therefore more aggressive than paccache default options.

To remove all the cached packages that are not currently installed, and the unused sync database, execute:

To remove all files from the cache, use the clean switch twice, this is the most aggressive approach and will leave nothing in the cache folder:

pkgcacheclean AUR and pacleaner AUR are two further alternatives to clean the cache.

Additional commands

Download a package without installing it:

Install a ‘local’ package that is not from a remote repository (e.g. the package is from the AUR):

To keep a copy of the local package in pacman’s cache, use:

Install a ‘remote’ package (not from a repository stated in pacman’s configuration files):

To inhibit the -S , -U and -R actions, -p can be used.

Pacman always lists packages to be installed or removed and asks for permission before it takes action.

Installation reason

The pacman database distinguishes the installed packages in two groups according to the reason why they were installed:

• explicitly-installed: the packages that were literally passed to a generic pacman -S or -U command;
• dependencies: the packages that, despite never (in general) having been passed to a pacman installation command, were implicitly installed because required by another package that was explicitly installed.

When installing a package, it is possible to force its installation reason to dependency with:

When reinstalling a package, though, the current installation reason is preserved by default.

The list of explicitly-installed packages can be shown with pacman -Qe , while the complementary list of dependencies can be shown with pacman -Qd .

To change the installation reason of an already installed package, execute:

Use —asexplicit to do the opposite operation.

Search for a package that contains a specific file

Sync the files database:

Search for a package containing a file, e.g.:

For advanced functionality install pkgfile, which uses a separate database with all files and their associated packages.

What happens during package install/upgrade/removal

When successful, the workflow of a transaction follows five high-level steps plus pre/post transaction hooks:

1. Initialize the transaction if there is not a database lock
2. Choose which packages will be added or removed in the transaction
3. Prepare the transaction, based on flags, by performing sanity checks on the sync databases, packages, and their dependencies
4. Commit the transaction:
   1. When applicable, download packages ( _alpm_sync_load )
   2. If pre-existing pacman PreTransaction hooks apply, they are executed.
   3. Packages are removed that are to-be-replaced, conflicting, or explicitly targeted to be removed
   4. If there packages to add, then each package is committed
      1. If the package has an install script, its pre_install function is executed (or pre_upgrade or pre_remove in the case of an upgraded or removed package).
      2. Pacman deletes all the files from a pre-existing version of the package (in the case of an upgraded or removed package). However, files that were marked as configuration files in the package are kept (see /Pacnew and Pacsave).
      3. Pacman untars the package and dumps its files into the file system (in the case of an installed or upgraded package). Files that would overwrite kept, and manually modified, configuration files (see previous step), are stored with a new name (.pacnew).
      4. If the package has an install script, its post_install function is executed (or post_upgrade or post_remove in the case of an upgraded or removed package).
   5. If pacman PostTransaction hooks that exist at the end of the transaction apply, they are executed.
5. Release the transaction and transaction resource (i.e. database lock)

Configuration

Pacman’s settings are located in /etc/pacman.conf : this is the place where the user configures the program to work in the desired manner. In-depth information about the configuration file can be found in pacman.conf(5) .

General options

General options are in the [options] section. Read pacman.conf(5) or look in the default pacman.conf for information on what can be done here.

Comparing versions before updating

To see old and new versions of available packages, uncomment the «VerbosePkgLists» line in /etc/pacman.conf . The output of pacman -Syu will be like this:

Enabling parallel downloads

Pacman 6.0 introduced the option to download packages in parallel. ParallelDownloads under [options] needs to be set to a positive integer in /etc/pacman.conf to use this feature (e.g., 5 ). Packages will otherwise be downloaded sequentially if this option is unset.

Skip package from being upgraded

To have a specific package skipped when upgrading the system, add this line in the [options] section:

For multiple packages use a space-separated list, or use additional IgnorePkg lines. Also, glob patterns can be used. If you want to skip packages just once, you can also use the —ignore option on the command-line — this time with a comma-separated list.

It will still be possible to upgrade the ignored packages using pacman -S : in this case pacman will remind you that the packages have been included in an IgnorePkg statement.

Skip package group from being upgraded

As with packages, skipping a whole package group is also possible:

Skip file from being upgraded

All files listed with a NoUpgrade directive will never be touched during a package install/upgrade, and the new files will be installed with a .pacnew extension.

Skip files from being installed to system

To always skip installation of specific directories list them under NoExtract . For example, to avoid installation of systemd units use this:

Later rules override previous ones, and you can negate a rule by prepending ! .

Maintain several configuration files

If you have several configuration files (e.g. main configuration and configuration with testing repository enabled) and would have to share options between configurations you may use Include option declared in the configuration files, e.g.:

where /path/to/common/settings file contains the same options for both configurations.

Hooks

Pacman can run pre- and post-transaction hooks from the /usr/share/libalpm/hooks/ directory; more directories can be specified with the HookDir option in pacman.conf , which defaults to /etc/pacman.d/hooks . Hook file names must be suffixed with .hook. Pacman hooks are not interactive.

Pacman hooks are used, for example, in combination with systemd-sysusers and systemd-tmpfiles to automatically create system users and files during the installation of packages. For example, tomcat8 specifies that it wants a system user called tomcat8 and certain directories owned by this user. The pacman hooks systemd-sysusers.hook and systemd-tmpfiles.hook invoke systemd-sysusers and systemd-tmpfiles when pacman determines that tomcat8 contains files specifying users and tmp files.

For more information on alpm hooks, see alpm-hooks(5) .

Repositories and mirrors

Besides the special [options] section, each other [section] in pacman.conf defines a package repository to be used. A repository is a logical collection of packages, which are physically stored on one or more servers: for this reason each server is called a mirror for the repository.

Repositories are distinguished between official and unofficial. The order of repositories in the configuration file matters; repositories listed first will take precedence over those listed later in the file when packages in two repositories have identical names, regardless of version number. In order to use a repository after adding it, you will need to upgrade the whole system first.

Each repository section allows defining the list of its mirrors directly or in a dedicated external file through the Include directive; for example, the mirrors for the official repositories are included from /etc/pacman.d/mirrorlist . See the Mirrors article for mirror configuration.

Package security

Pacman supports package signatures, which add an extra layer of security to the packages. The default configuration, SigLevel = Required DatabaseOptional , enables signature verification for all the packages on a global level. This can be overridden by per-repository SigLevel lines. For more details on package signing and signature verification, take a look at pacman-key.

Troubleshooting

«Failed to commit transaction (conflicting files)» error

If you see the following error: [1]

This is happening because pacman has detected a file conflict, and by design, will not overwrite files for you. This is by design, not a flaw.

The problem is usually trivial to solve. A safe way is to first check if another package owns the file ( pacman -Qo /path/to/file ). If the file is owned by another package, file a bug report. If the file is not owned by another package, rename the file which ‘exists in filesystem’ and re-issue the update command. If all goes well, the file may then be removed.

If you had installed a program manually without using pacman, for example through make install , you have to remove/uninstall this program with all of its files. See also Pacman tips#Identify files not owned by any package.

Every installed package provides a /var/lib/pacman/local/package-version/files file that contains metadata about this package. If this file gets corrupted, is empty or goes missing, it results in file exists in filesystem errors when trying to update the package. Such an error usually concerns only one package. Instead of manually renaming and later removing all the files that belong to the package in question, you may explicitly run pacman -S —overwrite glob package to force pacman to overwrite files that match glob .

«Failed to commit transaction (invalid or corrupted package)» error

Look for .part files (partially downloaded packages) in /var/cache/pacman/pkg/ and remove them (often caused by usage of a custom XferCommand in pacman.conf ).

«Failed to init transaction (unable to lock database)» error

When pacman is about to alter the package database, for example installing a package, it creates a lock file at /var/lib/pacman/db.lck . This prevents another instance of pacman from trying to alter the package database at the same time.

If pacman is interrupted while changing the database, this stale lock file can remain. If you are certain that no instances of pacman are running then delete the lock file:

Packages cannot be retrieved on installation

This error manifests as Not found in sync db , Target not found or Failed retrieving file .

Firstly, ensure the package actually exists. If certain the package exists, your package list may be out-of-date. Try running pacman -Syu to force a refresh of all package lists and upgrade. Also make sure the selected mirrors are up-to-date and repositories are correctly configured.

It could also be that the repository containing the package is not enabled on your system, e.g. the package could be in the multilib repository, but multilib is not enabled in your pacman.conf .

Pacman crashes during an upgrade

In the case that pacman crashes with a «database write» error while removing packages, and reinstalling or upgrading packages fails thereafter, do the following:

1. Boot using the Arch installation media. Preferably use a recent media so that the pacman version matches/is newer than the system.
2. Mount the system’s root filesystem, e.g., mount /dev/sdaX /mnt as root, and check the mount has sufficient space with df -h
3. Mount the proc, sys and dev filesystems as well: mount -t proc proc /mnt/proc; mount —rbind /sys /mnt/sys; mount —rbind /dev /mnt/dev
4. If the system uses default database and directory locations, you can now update the system’s pacman database and upgrade it via pacman —sysroot /mnt -Syu as root.
   • Alternatively, if you cannot update/upgrade, refer to Pacman/Tips and tricks#Reinstalling all packages.
5. After the upgrade, one way to double-check for not upgraded but still broken packages: find /mnt/usr/lib -size 0
6. Followed by a re-install of any still broken package via pacman —sysroot /mnt -S package .

Manually reinstalling pacman

Using pacman-static

pacman-static AUR is a statically compiled version of pacman, so it will be able to run even when the libraries on the system are not working. This can also come in handy when a partial upgrade was performed and pacman can not run anymore.

The pinned comment and the PKGBUILD provides a way to directly download the binary, which can be used to reinstall pacman or to upgrade the entire system in case of partial upgrades.

Using an external pacman

If even pacman-static does not work, it is possible to recover using an external pacman. One of the easiest methods to do so is by using the archiso and simply using —sysroot or —root to specify the mount point. See Chroot#Using chroot on how to mount the necessary filesystems required by —sysroot .

By manually extracting

Even if pacman is terribly broken, you can fix it manually by downloading the latest packages and extracting them to the correct locations. The rough steps to perform are:

1. Determine the pacman dependencies to install
2. Download each package from a mirror of your choice
3. Extract each package to root
4. Reinstall these packages with pacman -S —overwrite to update the package database accordingly
5. Do a full system upgrade

If you have a healthy Arch system on hand, you can see the full list of dependencies with:

But you may only need to update a few of them depending on your issue. An example of extracting a package is

Note the use of the w flag for interactive mode. Running non-interactively is very risky since you might end up overwriting an important file. Also take care to extract packages in the correct order (i.e. dependencies first). This forum post contains an example of this process where only a couple pacman dependencies are broken.

«Unable to find root device» error after rebooting

Most likely the initramfs became corrupted during a kernel update (improper use of pacman’s —overwrite option can be a cause). There are two options; first, try the Fallback entry.

Once the system starts, run this command (for the stock linux kernel) either from the console or from a terminal to rebuild the initramfs image:

If that does not work, from a current Arch release (CD/DVD or USB stick), mount your root and boot partitions. Then chroot using arch-chroot:

Reinstalling the kernel (the linux package) will automatically re-generate the initramfs image with mkinitcpio -p linux . There is no need to do this separately.

Afterwards, it is recommended that you run exit , umount /mnt/ and reboot .

«Warning: current locale is invalid; using default «C» locale» error

As the error message says, your locale is not correctly configured. See Locale.

Pacman does not honor proxy settings

Make sure that the relevant environment variables ( $http_proxy , $ftp_proxy etc.) are set up. If you use pacman with sudo, you need to configure sudo to pass these environment variables to pacman. Also, ensure the configuration of dirmngr has honor-http-proxy in /etc/pacman.d/gnupg/dirmngr.conf to honor the proxy when refreshing the keys.

How do I reinstall all packages, retaining information on whether something was explicitly installed or as a dependency?

To reinstall all the native packages: pacman -Qnq | pacman -S — or pacman -S $(pacman -Qnq) (the -S option preserves the installation reason by default).

You will then need to reinstall all the foreign packages, which can be listed with pacman -Qmq .

«Cannot open shared object file» error

It looks like previous pacman transaction removed or corrupted shared libraries needed for pacman itself.

To recover from this situation you need to unpack required libraries to your filesystem manually. First find what package contains the missed library and then locate it in the pacman cache ( /var/cache/pacman/pkg/ ). Unpack required shared library to the filesystem. This will allow to run pacman.

Now you need to reinstall the broken package. Note that you need to use —overwrite flag as you just unpacked system files and pacman does not know about it. Pacman will correctly replace our shared library file with one from package.

That’s it. Update the rest of the system.

Freeze of package downloads

Some issues have been reported regarding network problems that prevent pacman from updating/synchronizing repositories. [2] [3] When installing Arch Linux natively, these issues have been resolved by replacing the default pacman file downloader with an alternative (see Improve pacman performance for more details). When installing Arch Linux as a guest OS in VirtualBox, this issue has also been addressed by using Host interface instead of NAT in the machine properties.

Failed retrieving file ‘core.db’ from mirror

If you receive this error message with correct mirrors, try setting a different name server.

error: ‘local-package.pkg.tar’: permission denied

If you want to install a package on an sshfs mount using pacman -U and receive this error, move the package to a local directory and try to install again.

error: could not determine cachedir mount point /var/cache/pacman/pkg

Upon executing, e.g., pacman -Syu inside a chroot environment an error is encountered:

This is frequently caused by the chroot directory not being a mountpoint when the chroot is entered. See the note at Install Arch Linux from existing Linux#Downloading basic tools for a solution, and arch-chroot(8) for an explanation and an example of using bind mounting to make the chroot directory a mountpoint.

Источник