Fix my Gentoo

This guide is something I've posted on the forums several times in response to users posting that "nothing works". If gcc is broken after a, this guide is not for you. You almost certainly need. Be more careful in future.

This guide is for rescuing an installation when a chroot is not possible. Almost nothing seems to work but you have determined that you need some binary packages to fix the system.

It is actually very difficult to break Gentoo so badly, it can't be fixed.

Prerequsites
Some binary packages may be necessary to fix the system.

Binary packages may be found on a binhost or tinderbox on the web but they are unlikely to be built for your system, with your USE flags and your CFLAGS.

This guide provides instructions on building one's own binary packages to use to fix a system. You will not need another system, a spare partition or even another install.


 * A working internet connection.
 * A way to boot the broken box with some recovery media, e.g. System Rescue CD, if it won't boot
 * About 20 GiB of free space on in the broken installation. 5 GiB may do, depending on what needs to be built.

Summary
As the bootable install is not working and we need a working install to build binary packages, we need another install (just an extracted stage3 somewhere). This install need not be bootable.

It is sufficient to be able to into it and run. This rescue install will share some elements with the broken install which saves space and makes things easier in the final steps.

Terminology

 * : Mount the broken installation here.
 * : The new rescue install, it can be anywhere but it needs to be on a hard disk.

The rescue install

 * Mount the broken install at so we can use its hard drive space and its.
 * Make a directory at or somewhere with free space:


 * Follow the handbook to fetch a stage3 tarball and untar it to.
 * Do not get a Portage snapshot, the one in the main install will be utilized.
 * Follow the Handbook for all the odds and ends, like copying

Mounts

 * Mount and friends in  just as if you were doing a new install but do not chroot yet.


 * Bind mount the main ebuild repository to the rescue system:


 * Bind mount the distfiles directory:


 * Bind mount the binary package directory:


 * Copy over to

Now the rescue install has all the settings from the broken installation.

Chroot in to rescue install
Follow the chroot instructions from the handbook but into the directory instead.

Edit /etc/portage/make.conf
Inside of the new working rescue chroot, we need to tell Portage to create and save binary packages of everything we build.

Edit by adding   to FEATURES.

This causes Portage to save binary tarballs of every package built to.

Building packages
Two choices:



Quick package (quickpkg)
If the package needed is part of the stage3, use the tool to make a binary package.

Emerge
will just work. Build something small as a test like then check that the package has appeared in.

More packages
whatever is needed. will stay around until deleted and it is only a chroot away. Upon return, don't forget to redo the bind mounts.

Installing binary packages
After creating binary packages using any of the methods described above, they must be installed somehow to the broken system.

The best method to install binary packages depends on what is broken. The options below are presented in increasing order of risk (least risky first):


 * 1) Install "properly" using  where it works.
 * 2) Raw extract with  the binpkgs (tarballs) onto the broken system until you can do the safer option.

Using emerge
This requires chrooting into the install to be rescued. If you have managed to remove a part of your toolchain, this should work for you.

This will either install the binary tarball and its dependencies or fail if the binaries cannot be found.

Using tar
So you can't chroot in, is not an option. Maybe you removed and you don't have a statically linked ?

Each binary package is like a single package stage3. It has some extra information on the end that Portage uses, which will provoke a warning from that can be safely ignored.

Extracting tar step-by-step method
For safety's sake, unmount the rescue install at.

It may be necessary to unmount all the things mounted inside first.

Sanity checks
Before you issue the command, verify:


 * The install is mounted at
 * Understand the  and   options to . Review the man page if unsure:

Understanding the tar command
This tells to extract, preserving permissions, the file  and Change directory to  before it does anything else.

In fact, the input file name above is not correct. The full path to the tarball is required. Tab completion helps a lot.

Nervous users can add the  option to.

Extract
As described above, unpack the tarball (binary package) into the broken system.

The package is now effectively installed to the broken install. Repeat as necessary for all packages until can be used (see above) instead.

Tidying up
Once the damage is fixed, delete, or keep it around for next time.

With adequate space, it may be desirable to add  to the FEATURES variable as a regular thing. Then, the tarballs needed for rescuing the system will already exist.

Both and  will grow without limit. Run occasionally to prune them.