you get food and beer :-) end of comment. yours a.r.b. -----Original Message----- From: kickstart-list-admin@xxxxxxxxxx [mailto:kickstart-list-admin@xxxxxxxxxx]On Behalf Of rpjday Sent: 28 November 2001 22:47 To: kickstart list Subject: the first part of my installation writeup for anyone interested, here's the first part of my writeup on the red hat installation process -- more later after i get back from supper and a beer or two. comments? (by the way, the weird format is because i'm writing it in emacs using outline mode. live with it.) rday * Overview This mini-doc explains, in perhaps excruciating detail, the steps of the installation process for Red Hat 7.2. Once you understand what happens in a typical installation, it's that much easier to deal with more complicated tasks like configuring kickstart and building your own installation CDs. While Red Hat supports a number of installation "methods", such as local CD-ROM or hard drive, and network-based installs like NFS, FTP and HTTP, I'm going to restrict this document to local CD-ROM installs without any fancy side trips. Once you see how this works, it should be easy to see how the other methods work. In terms of pre-requisites, you should be able to mount floppies, CD-ROMs and filesystem images, and copy directory structures from one place to another. If you're really ambitious, it wouldn't hurt to be able to read bash shell and python scripts as well. If you have any comments, suggestions or corrections for this document, feel free to email me at rpjday@xxxxxxxxxxxxxxx * Getting prepared -- the necessary parts The entire installation process involves poking around in: 1) boot.img, the CD-ROM-based boot floppy 2) both Red Hat install CDs 1 and 2, particularly the installation files and directories in RedHat/base on CD 1 3) the "anaconda" loader RPM (actually, the src rpm so you can read the source C files and scripts as I explain them) I'm assuming you know how to mount the boot.img boot floppy in the RedHat/images directory of CD 1 and make your own copy of the contents. While you're at it, make your own copies of at least install CD 1, just so you don't have to keep mounting it. Finally, get the anaconda-7.2-7.src.rpm off of one of the source CDs, and: # rpm -ivh anaconda-7.2-7.src.rpm This installs the components of this RPM under the directory /usr/src/redhat/{SPECS,SOURCES}. Then: # cd /usr/src/redhat/SPECS # rpm -bp anaconda.spec This last step does a "prep" of the source RPM, so you can see all of the source files with: # cd ../BUILD/anaconda-7.2 # ls Note that "rpm -bp" doesn't do an actual build, but just unloads the tarball and applies the patches, which is fine since all you want to do is look at the source -- you have no need to actually build the executables. Now you have all the parts. * The big picture (to be written, covering the install process at a high level: boot floppy kernel initrd "init" program "loader" program Redhat/base/{stage files} python programs RPMs installation * The SYSLINUX boot floppy The boot floppy boot.img (and bootnet.img as well, for that matter) is a SYSLINUX-style floppy, where SYSLINUX is a boot loader that operates off of an MS-DOS FAT filesystem, and I'm assuming you've made a copy of it so you can poke around. (For more on SYSLINUX than you see here, see /usr/share/doc/syslinux-???/syslinux.doc). The top-level contents: ldlinux.sys part of the SYSLINUX boot process syslinux.cfg the SYSLINUX config file vmlinuz the compressed Linux kernel initrd.img the initial ram disk *.msg message help files, if you press F<n> The syslinux.cfg file controls the boot process, and pretty closely resembles a LILO configuration file. Here's the contents of that file as it appears on the boot.img boot floppy (most of it being self- explanatory): default linux prompt 1 timeout 600 display boot.msg F1 boot.msg F2 general.msg F3 expert.msg F4 param.msg F5 rescue.msg label linux kernel vmlinuz append initrd=initrd.img lang= devfs=nomount ramdisk_size=7168 vga=788 label text kernel vmlinuz append initrd=initrd.img lang= text devfs=nomount ramdisk_size=7168 label expert kernel vmlinuz append expert initrd=initrd.img lang= devfs=nomount ramdisk_size=7168 label ks kernel vmlinuz append ks initrd=initrd.img lang= devfs=nomount ramdisk_size=7168 label nofb kernel vmlinuz append initrd=initrd.img lang= devfs=nomount nofb ramdisk_size=7168 label lowres kernel vmlinuz append initrd=initrd.img lang= lowres devfs=nomount ramdisk_size=7168 As you can probably tell from the above, if you just let the boot: prompt timeout, or hit ENTER, you'll be loading the vmlinuz kernel, which will load and mount the initrd.img ramdisk to start the installation process. So what's in the initrd.img ramdisk? * The "initrd" ram disk The "initrd.img" file represents an initial root file system that will be mounted by the kernel as the next step in the installation process. This file is (like a number of .img files) a gzipped ext2 filesystem, so you can extract its contents into a separate directory with commands like the following (you may need root privilege for some of them): $ gunzip -c initrd.img > initrd.tmp (extract gunzip'ed filesystem) $ mkdir m (create a temporary mount point) $ mount -o loop initrd.tmp m (mount the filesystem) $ cp -av m initrd.d (copy to, say, "initrd.d") $ umount m (finished, so umount it) $ rm initrd.tmp (no need for initrd.tmp anymore) $ rmdir m (no need for mount point either) The initrd.d directory now contains what is a minimal root-lookalike filesystem, with contents: bin/ dev/ etc/ linuxrc lost+found/ modules/ proc/ sbin/ tmp/ var/ (Side note 1: This isn't the *entire* contents of the initrd.img ramdisk file. All of the special device files in the /dev directory could not be duplicated using a simple copy so, if you want to see the actual contents of /dev, you'll have to do it while you have the filesystem image mounted.) (Side note 2: You might want to poke around the ram disk image, just to see what the kernel has mounted early in the install process. In particular, it might be worth seeing the modules that are available. If you cd into the "modules" directory, there is a "modules.cgz" file, a gzipped cpio archive, that you can examine with: $ gunzip -c modules.cgz | cpio -itv Note that the modules in this boot floppy image are appropriate for a CD-ROM install. If you were to do this exercise with the bootnet.img floppy, you'd notice modules for network card support instead, just as you'd expect.) So what happens now? When using an initrd ramdisk, the boot process is: 1) the boot loader loads the kernel and the initial RAM disk 2) the kernel converts initrd into a "normal" RAM disk and frees the memory used by initrd 3) initrd is mounted read-write as root 4) the /linuxrc program is executed (this can be any valid executable, including shell scripts; it is run with uid 0 and can do basically everything init can do) Since /linuxrc -> /sbin/init, we now move on to discussing what that "init" program does as the next stage in the install process. (For more about the steps in loading and processing the initial ram disk, see the kernel doc file /usr/src/linux-??/Documentation/initrd.txt.) * The "init" program The /sbin/init program that is invoked now is *not* the same /sbin/init you're familiar with in a typical Red Hat installation. Rather, it's the first stage of the anaconda installation program, and you can examine its source back in the BUILD directory, along with the next stage of anaconda, loader.c: /usr/src/redhat/BUILD/anaconda-7.2/loader/ init.c loader.c If you're watching carefully during the early stages of an install, once the kernel messages are printed, you'll see the output from "init" (feel free to match this up with the source in init.c if you're feeling ambitious): Greetings. Red Hat install init version <whetever> starting mounting /proc filesystem... done mounting /dev/pts (unix98 pty) filesystem... done checking for NFS foor filesystem...no trying to remount root filesystem read write... done checking for writeable /tmp... yes running install... running /sbin/loader In addition to the obvious work that init has done based on the above output, it also: 1) opens a file descriptor for the first virtual console, and dup2()s all of 0, 1 and 2 to that file descriptor 2) sethostname("localhost.localdomain") 3) setdomainname("") and, as its final task, does a fork() and execve() to invoke "loader", the next installation stage and also a part of the anaconda loader. * The "loader" program ... in progress ... _______________________________________________ Kickstart-list mailing list Kickstart-list@xxxxxxxxxx https://listman.redhat.com/mailman/listinfo/kickstart-list
