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=", 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