200 lines
8.1 KiB
Plaintext
200 lines
8.1 KiB
Plaintext
|
Anaconda Release Notes
|
||
|
|
----------------------
|
||
|
|
|
||
|
|
Last update: Mar 26 2002
|
||
|
|
|
||
|
|
|
||
|
|
Contents
|
||
|
|
|
||
|
|
- Overview
|
||
|
|
- Install mechanism summary
|
||
|
|
- Patching/updating installer
|
||
|
|
- Invocation options
|
||
|
|
- Troubleshooting
|
||
|
|
- More info
|
||
|
|
|
||
|
|
|
||
|
|
Overview
|
||
|
|
--------
|
||
|
|
|
||
|
|
Anaconda is the name of the install program used by Red Hat Linux.
|
||
|
|
It is python-based with some custom modules written in C. Being
|
||
|
|
written in a scripting language makes development quicker, and it is
|
||
|
|
easier to distribute updates in a non-binary form. The anaconda
|
||
|
|
installer works on a wide variety of Linux-based computing
|
||
|
|
architectures (ia32, Itanium, Alpha, S/390, PowerPC), and is designed to make
|
||
|
|
it easy to add platforms.
|
||
|
|
|
||
|
|
The first stage of the installer is a loader program written in C.
|
||
|
|
This program is responsible for loading all the kernel modules
|
||
|
|
required to mount the second stage of the installer, which has a
|
||
|
|
fairly complete Linux runtime environment. The loader is designed to
|
||
|
|
be small to fit within the constraints of bootable media (floppies are
|
||
|
|
small by modern standards). Once the loader has mounted the second
|
||
|
|
stage image, the python installer is started up, and optionally, a
|
||
|
|
graphical X Windows based environment.
|
||
|
|
|
||
|
|
The loader can install from local media (harddrive or CDROM), or
|
||
|
|
from a network source, via FTP, HTTP, or NFS. The installer can pull
|
||
|
|
updates for bugs or features via several sources as well. Finally, the
|
||
|
|
installer has an auto-install mechanism called kickstart that allows
|
||
|
|
installs to be scripted. The script can even be pulls from an HTTP
|
||
|
|
source that can create kickstart configurations dynamically based on
|
||
|
|
the machine which is requesting the script. This allows endless
|
||
|
|
possibilities in automating large sets of servers.
|
||
|
|
|
||
|
|
This document's purpose is to go over technical details that will
|
||
|
|
make using and customizing the installer, and the distribution, much
|
||
|
|
easier. The anaconda installer arguably is one of the most flexible
|
||
|
|
and powerful installers available, and hopefully this document will
|
||
|
|
allow users to take advantage of this potential.
|
||
|
|
|
||
|
|
Install Mechanism Summary
|
||
|
|
-------------------------
|
||
|
|
|
||
|
|
The document 'install-methods.txt', which is distributed with the
|
||
|
|
anaconda package, goes over the various ways the installer can be
|
||
|
|
used. Essentially, the installer needs to access the contents of the
|
||
|
|
CD images distributed with the product. The installer can either work
|
||
|
|
with the CD images one at a time, or else from a single directory (the
|
||
|
|
install 'tree') which has the contents of all the CD images copied
|
||
|
|
into it. The later is useful if you are customizing the packages in
|
||
|
|
the distribution. The first stage of the installation process (the
|
||
|
|
'loader') is responsible for getting the system to the point it can
|
||
|
|
access the installation source, whether CD image or installation tree based.
|
||
|
|
|
||
|
|
For CDROM-based installs the loader detects the presence of a CD in a
|
||
|
|
drive in the system with a distribution on it and jumps straight to the
|
||
|
|
second stage. For other interactive (non-kickstart) installation methods the
|
||
|
|
user is prompted for the installation source. For kickstart-based installs
|
||
|
|
the installation source is specified in the kickstart file, and the user is
|
||
|
|
not required to be present unless necessary information is missing from the
|
||
|
|
kickstart script.
|
||
|
|
|
||
|
|
For NFS-based installs the installer mounts the directory specified
|
||
|
|
and looks for a set of ISO images, or an installation tree. If
|
||
|
|
present then a filesystem image is loopback-mounted and the second
|
||
|
|
stage installer is run from this image. For FTP and HTTP installs a
|
||
|
|
smaller (no graphical install options) second stage image is
|
||
|
|
downloaded into memory, mounted, and the second stage installer run
|
||
|
|
from this. On harddrive based installs a similar small second stage
|
||
|
|
image is put into memory and the second stage installer run from it.
|
||
|
|
This is necessary because for partitioning to suceed the installer can
|
||
|
|
not have partitions on the harddrive mounted in order for the kernel
|
||
|
|
to be able to acknowledge partition table changes.
|
||
|
|
|
||
|
|
The bootable installation images are as follow:
|
||
|
|
|
||
|
|
boot.img - boot image containing kernel modules for installing
|
||
|
|
on most systems from a CDROM or harddrive.
|
||
|
|
|
||
|
|
bootnet.img - boot iamge containing kernel modules for
|
||
|
|
installing on most systems from a network source.
|
||
|
|
|
||
|
|
pcmcia.img - boot image for installing on PCMCIA based systems
|
||
|
|
from a local or network source.
|
||
|
|
Requires pcmciadd.img driver disk.
|
||
|
|
|
||
|
|
The supplemental driver disk images are:
|
||
|
|
|
||
|
|
drvblock.img - block device drivers (for example, SCSI controllers).
|
||
|
|
|
||
|
|
drvnet.img - extra network device drivers.
|
||
|
|
|
||
|
|
oldcdrom.img - device drivers for non-SCSI, non-ATAPI cdroms.
|
||
|
|
|
||
|
|
|
||
|
|
Patching The Installer
|
||
|
|
----------------------
|
||
|
|
|
||
|
|
At times there are bugfixes or feature enhancements available for
|
||
|
|
the installer. These are typically replacement python source files
|
||
|
|
which override the versions distributed with the release. Python has
|
||
|
|
a mechanism similar to the command line shell search path for
|
||
|
|
executables. The installer can be updated by putting patched files in
|
||
|
|
a location earlier in the search path Python uses to find modules.
|
||
|
|
The 'install-methods.txt' document describes all the various ways the
|
||
|
|
installer can be told where to find the updating source files.
|
||
|
|
Typcially this is done from an 'update disk', which is a floppy with
|
||
|
|
an ext2 filesytem on it. The updated python source files are put in
|
||
|
|
the main directory of the floppy. The installer is invoked with an
|
||
|
|
'updates' option from the boot command line, and the user is prompted
|
||
|
|
to insert the update disk. The files are copied off into a ramdisk
|
||
|
|
location which Python has been instructed to look at first of modules.
|
||
|
|
If one is customizing the distribution and the installer then installing
|
||
|
|
over NFS is the fastest way to work.
|
||
|
|
|
||
|
|
The installer will also use an 'updates.img' file to get patched
|
||
|
|
source files. This is particularly useful for FTP and HTTP based installs.
|
||
|
|
When the second stage image is retrieved from the server, a download of
|
||
|
|
the updates.img is also attempted. This file must be an ext2 filesystem image.
|
||
|
|
It is mounted loopback, then the contents are copied to the ramdisk location
|
||
|
|
that Python is setup to look at for module updates. This update image will
|
||
|
|
also work with all the other installation mechanisms, although the exact
|
||
|
|
location where it is expected does vary. The 'install-methods.txt' file
|
||
|
|
has the details on this.
|
||
|
|
|
||
|
|
Invocation Options
|
||
|
|
------------------
|
||
|
|
The documentation file 'command-line.txt' has a quick summary of all the
|
||
|
|
command line options anaconda accepts.
|
||
|
|
|
||
|
|
Troubleshooting
|
||
|
|
---------------
|
||
|
|
|
||
|
|
- Cannot get graphical installer working
|
||
|
|
|
||
|
|
On some video hardware (laptops in particular) the graphical
|
||
|
|
installer will not work. The installer attempts to run at
|
||
|
|
800x600, and some hardware does not work in this mode, or the
|
||
|
|
output looks poor when scaled to this mode. This can be worked
|
||
|
|
around by specifying the 'vga=xxx' option on the command line when
|
||
|
|
booting the installer. Here 'xxx' is the VESA mode number for the
|
||
|
|
video mode which will work on your hardware, and can be one of the
|
||
|
|
following:
|
||
|
|
|
||
|
|
|
||
|
|
| 640x480 800x600 1024x768 1280x1024 <-Resolution
|
||
|
|
----+-------------------------------------
|
||
|
|
256 | 769 771 773 775
|
||
|
|
32k | 784 787 790 793
|
||
|
|
64k | 785 788 791 794
|
||
|
|
16M | 786 789 792 795
|
||
|
|
^
|
||
|
|
|
|
||
|
|
Number of colors
|
||
|
|
|
||
|
|
Find the row with the number of colors and the column with the resolution
|
||
|
|
and then use the number at the intersection. For example, to run at
|
||
|
|
1024x768 with 64k colors, use 'vga=791'
|
||
|
|
|
||
|
|
Alternately, you can specify "resolution=<mode>", where mode is:
|
||
|
|
|
||
|
|
640x480
|
||
|
|
800x600
|
||
|
|
1024x768
|
||
|
|
1152x864
|
||
|
|
1280x1024
|
||
|
|
1400x1050
|
||
|
|
1600x1200
|
||
|
|
|
||
|
|
and the installer will start up in graphical mode in the resolution
|
||
|
|
specified.
|
||
|
|
|
||
|
|
|
||
|
|
|
||
|
|
More Info
|
||
|
|
---------
|
||
|
|
|
||
|
|
For more info, goto the kickstart-list and anaconda-devel mailing lists
|
||
|
|
hosted by Red Hat. You can find these at:
|
||
|
|
|
||
|
|
|
||
|
|
anaconda-devel-list -
|
||
|
|
https://listman.redhat.com/mailman/listinfo/anaconda-devel-list
|
||
|
|
|
||
|
|
kickstart-list -
|
||
|
|
https://listman.redhat.com/mailman/listinfo/kickstart-list
|
||
|
|
|
||
|
|
<end of document>
|