Upgrading Gentoo

This document Article description::explains how to upgrade Gentoo.

This article is undergoing a much-overdue modernization. Any instructions that only affect ten or more year old systems will not be retained. See page history for previous versions.

Philosophy
Here in Gentoo land, the concept of upgrading is quite different compared to the rest of the Linux world. It is a well-known fact that Gentoo never got in touch with the "classic" way of upgrading software: waiting for a new release, downloading it, creating the installation media (optical disk/USB drive, etc.), attaching the installation media to the system to be upgraded, and then following the upgrade instructions.

Gentoo users know however that this process is extremely frustrating for power users that want to live on the bleeding edge. Even power users from other distributions probably share the same feelings, given the popularity and spread of tools like or  which make it possible to have quick and frequent updates. However, no distribution is more suited than Gentoo to satisfy these kind of demanding users. From the beginning, Gentoo was designed around the concept of fast, incremental updates.

Here, users install software once and never bother with releases: just follow the instructions in A Portage introduction in the Gentoo handbook that explain how to keep the system up to date. Only in very rare cases changes are made to the core system which require updates to be done manually. This typically involves switching to a new profile.

Profiles
A profile is a set of configuration files, stored in a subdirectory of, that describe things such as the ebuilds that are considered system packages, the default USE flags, and the architecture on which the system is running.

The profile in use is determined by the symbolic link, which points to a subdirectory of which holds the profile files. For instance, the default 17.1 profile can be found at. The files in the parent directories are part of the profile as well (and are therefore shared by different subprofiles). This is why we call these cascaded profiles.

Profiles obsoleted by new ones are kept in along with the current ones, but they are marked as deprecated. When that happens a file named is put in the profile directory. The content of this file is the name of the profile that should be "upgraded to"; Portage uses this information to automatically warn administrators when they should update to a new profile.

There are various reasons that a new profile may be created: the release of new versions of core packages (such as, , or ) that are incompatible with previous versions, a change in the default USE flags or in the virtual mappings, or maybe a change in system-wide settings.

Profile changes
If a new profile (such as 17.1 for ) is introduced, then there is the choice to migrate to the new profile.

Generally, such migrations are not mandatory, and systems can continue to use the old profile - just update the packages as explained in the Gentoo Handbook.

However, Gentoo strongly recommends updating the profile if it becomes deprecated. When this happens, it means that Gentoo developers no longer plan on supporting it.

When a profile migration is apparent, then the upgrade has to be executed manually. The way to update may vary significantly from profile to profile; it depends on how deep the modifications introduced in the new profile are.

In the simplest case users only have to change the symlink, in the worst case they may have to recompile the entire system from scratch while doing a neat voodoo dance. Migration is usually covered in news items. The necessary instructions are explained further in this guide.

Supported profiles
To view the list of supported profiles, call as follows:

Updating packages
The Handbook has detailed information on updating the Gentoo repository and on updating the system. See for detailed information.

To update all installed packages to the latest available versions, first update the Gentoo repository with Project:Portage/Sync:

This may output messages that should be read and followed.

Run emerge to update the whole system, with dependencies (including build-time dependencies):

Pay attention to any information provided by Portage at the end of the update.

If Portage reports dependency issues, sometimes using the  (or an even higher number) can help : by default, Portage has a relatively low limit on how far it tries to resolve dependencies - for performance reasons - though occasionally it is not enough.

After the update, any dependencies that are no longer required should be removed, this is important as stray packages can sometimes cause issues:

If would remove packages that should not be removed, they can be added to the world set:

Any configuration file changes can be managed by dispatch-conf:

Profile updating instructions
When a new profile is available, Portage will inform the user with a news item. Recent news items are listed on the website.

If a system is too old, it may be non trivial to get the system up to date, it may even be easier to start from scratch.

General instructions
This is a generic outline of what is done to update a profile. As stated previously, specific instructions will be provided in a news item, for each new profile. A profile update often requires manual intervention, beyond just switching the profile version.

Switch profiles with
Make sure warnings in parent section have been read.

To switch profiles with the automatic tool, must be installed. The utility makes viewing and selecting profiles easy, without needing to create or remove symlinks by hand:

Switch profiles manually
Make sure warnings in parent section have been read.

Changing profiles manually is still supported:

Updating to 17.1
See the appropriate news item. At this point all installations should already be using the 17.1 profile, and migration could be difficult.

Updating to 17.0
See the appropriate news item. At this point all installations should be using the 17.1 profile, and migration could be difficult.

Updating old systems
Sometimes, systems are too old to easily upgrade. It may be possible to manually update a very old system, but it may be better to start from scratch and copy system configuration an files from the old system to the new one.

Here is a rough guide to updating an old system. Another method can be found here.

Synopsis
The idea with this upgrade approach is that we create an intermediate build chroot in which a recent stage3 is extracted. Then, using the tools available in the stage3 chroot we upgrade the packages on the live system.

Preparing the intermediate build chroot
Let's first create the intermediate build chroot location, say, and extract a recent stage3 archive into it.

Next, we create a mount point inside this chroot environment, on which we then bind-mount the live (old) environment.

So now the live (old) system is also reachable within. This will allow us to reach the live (old) system and update the packages even when chrooted inside the intermediate build chroot.

Network, chroot, and update
The new install needs to access the network, so copy over the network related information:

Now chroot into the intermediate build location, and start updating vital packages on the live system, until the live system can be updated from within the live system (rather than through the intermediate build chroot):

It may be a good idea to check that the profile and Portage configuration are compatible between the (old) live system and the chroot.

Now start building packages into the (old) live system. If Portage is old or missing, it is a good idea to start with that:

Keep this chrooted session open and try to update the (old) live system. When failures occur, use this chrooted session to update packages using the build tools available in the intermediate build chroot (which includes recent, , etc.). Tools can be added as needed to the build chroot.

For some installations it may be necessary to update configuration files in order to install new software. Make the changes in the chroot environment.

To get the system fully up-to-date before exiting the root, build the  set (all packages) into the (old) live system:

Once finished the system should now be up to date!