[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

[PATCH 3/9] 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 insertions(+), 201 deletions(-)
 delete mode 100644 docs/anaconda-release-notes.txt

diff --git a/anaconda.spec.in b/anaconda.spec.in
index 07557e9..a2d07e8 100644
--- a/anaconda.spec.in
+++ b/anaconda.spec.in
@@ -204,7 +204,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
diff --git a/docs/Makefile.am b/docs/Makefile.am
index e60d950..aef2d5d 100644
--- a/docs/Makefile.am
+++ b/docs/Makefile.am
@@ -17,7 +17,7 @@
 # Author: David Cantrell <dcantrell redhat com>
-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 167411c..0000000
--- a/docs/anaconda-release-notes.txt
+++ /dev/null
@@ -1,199 +0,0 @@
-Anaconda Release Notes 
-Last update: Mar 26 2002
- - Overview
- - Install mechanism summary
- - Patching/updating installer
- - Invocation options
- - Troubleshooting
- - More info
-   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.
-- 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>

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]