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
/lib/systemd/system/*
/lib/udev/rules.d/70-anaconda.rules
%{_bindir}/instperf
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@xxxxxxxxxx>
-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
-
-
-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>
--
1.7.7.6
_______________________________________________
Anaconda-devel-list mailing list
Anaconda-devel-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/anaconda-devel-list
