Upgrading Gentoo

From Gentoo Wiki
Jump to:navigation Jump to:search
This page contains changes which are not marked for translation.
Other languages:
Deutsch • ‎English • ‎español • ‎français • ‎italiano • ‎português do Brasil • ‎русский • ‎中文(中国大陆)‎ • ‎日本語 • ‎한국어

This document explains how to upgrade Gentoo. It is at the moment undergoing a much-overdue modernization. At this point, instructions that affect only systems with an installation >10 years in the past will be removed. If you are still interested in the old text, please look at the page history.

This page is a work in progress by dilfridge (talk | contribs). Treat its contents with caution.



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 apt or yast 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.


A profile is a set of configuration files, stored in a subdirectory of /var/db/repos/gentoo/profiles, 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 /etc/portage/make.profile, which points to a subdirectory of /var/db/repos/gentoo/profiles which holds the profile files. For instance, the default amd64 17.1 profile can be found at /var/db/repos/gentoo/profiles/default/linux/amd64/17.1. 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 /var/db/repos/gentoo/profiles along with the current ones, but they are marked as deprecated. When that happens a file named deprecated 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 sys-apps/baselayout, sys-devel/gcc, or sys-libs/glibc) 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.

Keeping up with new profiles

Profile changes

If a new profile (such as 17.1 for amd64) 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 /etc/portage/make.profile 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 eselect as follows:

root #eselect profile list

Upgrading from older systems

Some systems are too old to just switch the profile. Newer profiles might need more recent Portage versions or other software that cannot be installed anymore because the package definitions (ebuilds) for those older software versions are not available anymore.

If this is the case, the system should first receive older Portage tree snapshots and upgrade at least Portage (but preferably all packages in the system set), gradually increasing the Portage tree snapshot date until it is recent enough to follow the profile switching instructions again:

root #mv /usr/portage /usr/portage.latest
root #tar xjpf /path/to/portage-20090720.tar.bz2 -C /usr
root #emerge --update --oneshot portage

Typically one should this way increase the date of the Portage tree by 6-12 months per step.

Older snapshots are often still available on some mirrors on the Internet or on specific locations dedicated for this purpose. It is recommended to verify the integrity of those files to make sure they are not tampered with:

root #gpg --verify portage-20090720.tar.bz2.gpgsig portage-20090720.tar.bz2

Although the release signing keys might be expired, the signature should still be OK.

The main difficulty with this strategy is that source files of the packages you need in intermediate steps may have been removed from Gentoo mirrors and even may have been removed from the upstream download location in the meantime.

Upgrading from (too) old systems

Sometimes, systems are too old to easily upgrade. The upgrade path might need intermediate versions of software (such as portage) that does not exist any more, requiring to update the portage tree in steps (for instance incremental tree updates with steps of 3 to 4 months).

To upgrade such systems, a recent stage3 can be used to update the system. Instructions for that are given in the Updating old systems section.

Profile updating instructions

General instructions

Make sure the main Gentoo repository (the Portage tree) has been synced before performing any profile changes.

First, run emerge eselect. The eselect utility makes viewing and selecting profiles easy, without needing to create or remove symlinks by hand.

root #eselect profile list
root #eselect profile set <number>

Changing profiles manually is still supported though:

root #rm /etc/portage/make.profile
root #cd /etc/portage
root #ln -s ../../var/db/repos/gentoo/profiles/<selected profile> make.profile
There are desktop subprofiles for most architectures. Examine these profiles carefully, as they may serve the requirements better than the extremely minimal default profiles.
The developer subprofile is specifically for Gentoo Linux development tasks. It is not meant to help set up general development environments.

Updating to 17.1

Updating to 17.0

Updating to 13.0

Updating to 10.0

Updating old systems

Idea of the upgrade

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.

The commands below might be incomplete and serve more as a guidance rather than work instructions. Unless the approach is clear, it might be faster to just backup the important files and re-install Gentoo.

Preparing the intermediate build chroot

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

root #mkdir -p /mnt/build
root #tar -xf /path/to/stage3-somearch-somedate.tar.bz2 -C /mnt/build
root #mount --rbind /dev /mnt/build/dev
root #mount --rbind /proc /mnt/build/proc
root #mount --rbind /sys /mnt/build/sys

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

root #mkdir -p /mnt/build/mnt/host
root #mount --rbind / /mnt/build/mnt/host

So now the live (old) system is also reachable within /mnt/build/mnt/host. 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:

root #cp -L /etc/resolv.conf /mnt/build/etc/

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):

root #chroot /mnt/build
root #source /etc/profile
root #export PS1="(chroot) ${PS1}"
(chroot) root #emerge --sync

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

(chroot) root #emerge --root=/mnt/host --config-root=/mnt/host --verbose --oneshot sys-apps/portage

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 sys-libs/glibc, sys-devel/gcc, etc.). Tools can be added as needed to the build chroot.

Do not forget to add --root=/mnt/host --config-root=/mnt/host to all emerge commands executed within the chroot! Otherwise the chroot itself is updated rather than the (old) live system.

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 @world set (all packages) into the (old) live system:

(chroot) root #emerge --root=/mnt/host --config-root=/mnt/host --update --newuse --deep --ask @world

Once finished the system should now be up to date!

This page is based on a document formerly found on our main website gentoo.org.
The following people contributed to the original document: Gregorio Guidi, Chris Gianelloni, Joshua Saddler
They are listed here because wiki history does not allow for any external attribution. If you edit the wiki article, please do not add yourself here; your contributions are recorded on each article's associated history page.