From aab240d844dbcd56c45bcaccd011175f480bb928 Mon Sep 17 00:00:00 2001 From: Will Woods Date: Fri, 10 Feb 2012 14:47:40 -0500 Subject: remove ancient anaconda-release-notes.txt Seriously, this thing is old and full of lies. It's good for some laffs: "The loader is designed to be small to fit within the constraints of bootable media (floppies are small by modern standards)." "pcmcia.img - boot image for installing on PCMCIA based systems" But really, "Last update: Mar 26 2002" is all you need to know. It'll always be in the git history if you want to read it again. --- anaconda.spec.in | 1 - docs/Makefile.am | 2 +- docs/anaconda-release-notes.txt | 199 ---------------------------------------- 3 files changed, 1 insertion(+), 201 deletions(-) delete mode 100644 docs/anaconda-release-notes.txt diff --git a/anaconda.spec.in b/anaconda.spec.in index d1ac56227..26022de6a 100644 --- a/anaconda.spec.in +++ b/anaconda.spec.in @@ -208,7 +208,6 @@ update-desktop-database &> /dev/null || : %doc docs/command-line.txt %doc docs/install-methods.txt %doc docs/mediacheck.txt -%doc docs/anaconda-release-notes.txt /lib/systemd/system/* /lib/udev/rules.d/70-anaconda.rules %{_bindir}/instperf diff --git a/docs/Makefile.am b/docs/Makefile.am index e60d95046..aef2d5dea 100644 --- a/docs/Makefile.am +++ b/docs/Makefile.am @@ -17,7 +17,7 @@ # # Author: David Cantrell -EXTRA_DIST = install-methods.txt mediacheck.txt anaconda-release-notes.txt \ +EXTRA_DIST = install-methods.txt mediacheck.txt \ lvm_sanity_checks.txt rescue-mode api.cfg making-screenshots \ threads.txt command-line.txt gettext.txt transifex.txt diff --git a/docs/anaconda-release-notes.txt b/docs/anaconda-release-notes.txt deleted file mode 100644 index 167411cb1..000000000 --- a/docs/anaconda-release-notes.txt +++ /dev/null @@ -1,199 +0,0 @@ -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 - - -- cgit