System resurrection

Although it is always possible to resurrect a machine back to life by reinstalling it, it is not always suitable to reinstall from scratch and sometimes the best is to try to fix a broken system even with as a last resort option before a full system reinstallation. Here are some ideas on how to resurrect a dead Funtoo system without reinstalling everything from scratch.

Core package removal

Several packages at the heart of your Funtoo system, these mainly are:

Component	Package	Functional role
GNU Binutils	sys-devel/binutils	Binutils are a set a tools (linker, assembler...) used behind the scene by the GNU Compiler Collection to produce executable files.
GNU Compiler collection (GCC)	sys-devel/gcc	GCC is a collection of compilers or several languages (FORTRAN, Java, C and C++, plus some libraries like the Standard Template Library or STL). A wide spectrum of software in a Funtoo system is written in C/C++.
C Library	sys-libs/glibc	The C library contains an implementation of a wide range of commonly needed functionalities like memory allocation, strings manipulation, I/O operations and so on. It is maybe of one most critical system components as nearly everything on a Funtoo system depends on this component (including the Python interpreter which executes the vairous Python scripts at the heart of the Funtoo core utilities and package management system).
Z library	sys-libs/zlib	This library contain several lossless compression/decompression routines.It is used by many other components on a Funtoo system like the bzip2/bunzip2 commands (app-arch/bzip2) for example (xz archive utilities depends on another standalone set of libraries).

Building binary packages

The best approach for critical system repair is to boot on a SystemRescueCD or other similar LiveCD, and use this as working platform to resurrect your system.

For creating binary packages, you can use any of the following options for a source environment:

• Use the most recent Funtoo stage3 for your architecture.
• If available, a recent system backup (e.g. snapshot if you use a BTRFS or ZFS filesystem or LVM volume, or a tar or cpio backup of your hard drive)

On a working Linux system, which can be either your broken system booted with a LiveCD, or another system on your network, you will want to build a chroot environment using the "source environment" you selected above, and use this as a platform for building binary packages to restore your system. Once these packages are created, they can be copied to your broken system and installed to restore the system packages.

The binary package creation environment would typically be set up as follows:

# install -d /mnt/rescue
# tar xpvf backup.tar.bz2 -C /mnt/rescue
# cp /etc/resolv.conf /mnt/rescue/etc
# mount --bind /proc /mnt/rescue/proc
# mount --bind /sys /mnt/rescue/sys
# mount --bind /dev /mnt/rescue/dev
# mount --bind /dev/pts /mnt/rescue/dev/pts
# chroot /mnt/rescue
# source /etc/profile
# env-update

No matter of the way you jump in a functional Funtoo/Gentoo environment, the magic command to create a binary package archive once inside is quickpkg. quickpkg will capture the package in the exact form it is actually deployed on the environment and create an archive of it placed in /usr/portage/packages/<package-category>/<package-name>-<package-version>.tbz2.

In the following example capture everything deployed by sys-devel/gcc(4.4.5 is present on the system) and put the captured files in a single archive named gcc-4.4.5.tbz2 located in /usr/portage/packages/sys-devel.

# quickpkg sys-devel/gcc

If you need to recompile a package instead of archiving an already deployed version (and of course without installing it on your "life boat"), just do:

# emerge --buildpkgonly  sys-devel/gcc

Restoring the binary packages on the broken system

Now copy the archives created in the step above in the exact same location on your broken system (e.g. in /usr/portage/packages/sys-devel in the case of sys-devel/gcc) and emerge them with -k:

# emerge -k  sys-devel/gcc

In the case of a non-functional Portage is always possible to directly extract the tar archive in your filesystem:

# tar xjpvf gcc-4.4.5.tbz2 -C /mnt/rescue

If you have chrooted inside your broken Funtoo system, you would want to use "-C /" as the last argument to tar rather than "-C /mnt/rescue".

You will see a note about the trailing garbage at the end of the file being ignored. This is normal -- tar is ignoring the Portage .tbz2 metadata that is tacked on to the end of the file.

Various weird issues

P1: I have a local distfiles mirror and wget complains about not being able to resolve 'localhost'.
S1: libnss (which handles name resolution) is probably damaged or suffers of inconsistencies, in your /etc/make.conf, change 'localhost' in GENTOO_MIRRORS for 127.0.0.1 (IPv4) or ::1 (IPv6)

P2: Same problem as described in P1 but I use another machine on my network or a public mirror on the Internet
S2: See the solution given in S1 but with providing the IP of the machine you are downloading for.