Difference between revisions of "System resurrection"
(reorg) |
(→Restoring the binary packages on the broken system) |
||
| Line 70: | Line 70: | ||
== Restoring the binary packages on the broken system == | == 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 <tt>/usr/portage/packages/'''sys-devel'''</tt> in the case of <tt>'''sys-devel'''/gcc</tt>) and emerge | + | Now copy the archives created in the step above in the exact same location on your broken system (e.g. in <tt>/usr/portage/packages/'''sys-devel'''</tt> in the case of <tt>'''sys-devel'''/gcc</tt>), use <tt>chroot</tt> to enter the system and emerge the package(s) with -k: |
<pre> | <pre> | ||
| Line 76: | Line 76: | ||
</pre> | </pre> | ||
| − | + | If you are unable to <tt>chroot</tt> or have a non-functional Portage on your broken system, it is always possible to directly extract the tar archive to your broken filesystem that you mounted at <tt>/mnt/broken</tt>: | |
<pre> | <pre> | ||
| − | # tar xjpvf gcc-4.4.5.tbz2 -C /mnt/ | + | # tar xjpvf gcc-4.4.5.tbz2 -C /mnt/broken |
</pre> | </pre> | ||
| − | If you have chrooted inside your broken Funtoo system, you would want to use "<tt>-C /</tt>" as the last argument to <tt>tar</tt> rather than "<tt>-C /mnt/ | + | If you have chrooted inside your broken Funtoo system, you would want to use "<tt>-C /</tt>" as the last argument to <tt>tar</tt> rather than "<tt>-C /mnt/broken</tt>". |
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. | 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. | ||
Revision as of 16:58, 23 March 2011
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.
Contents |
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), use chroot to enter the system and emerge the package(s) with -k:
# emerge -k sys-devel/gcc
If you are unable to chroot or have a non-functional Portage on your broken system, it is always possible to directly extract the tar archive to your broken filesystem that you mounted at /mnt/broken:
# tar xjpvf gcc-4.4.5.tbz2 -C /mnt/broken
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/broken".
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.
