1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
|
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.
For NFS installes, any files in the directory 'RHupdates' under the
directory mounted in the loader will also be used before the source
files shipped in the release. 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>
|
