|
|
loading source code UNIX on the PC
By Bob Gray Bob Gray is co-founder of Boulder Labs, a digital video company. Designing architectures for performance has been his focus since he built an image processing system on UNIX in the late 1970s. He has a PhD in computer science from the University of Colorado.
References: Thanks to Tom Poindexter and Mike Durian for reviewing this article. My first article provided motivation for running source code UNIX (SCU) on your system (April 1998). The second article (June 1998) was devoted to evaluating and choosing hardware. (Both are online at <http://www.usenix.org/publications/login> and <http://www.boulderlabs.com>). By now, you have some equipment ready for a system and you have chosen your software. This article walks you through some of the issues you will face when loading the software. You are expected to be familiar with PC hardware and general UNIX system administration. Of course, the process varies between loading Linux, FreeBSD, NetBSD, OpenBSD, and BSDI. All CD-ROM distribution sets come with instructions; this article gives general guidelines. You'll need to consult the specific references but overall the required steps for each are similar. Where are you going to load your source code UNIX? You'll want a few hundred megabytes for a basic X11 development system and a gigabyte or more if you install lots of applications (also known as "ports" or "packages") and their source code. Are you going to share a disk among multiple operating systems, or can you dedicate your disk to one OS? My system provides an example of these issues. I have a 2GB disk that is capable of booting either Windows 95 (for Word and Excel) or FreeBSD. I only occasionally need a Win95 environment, so I gave it 500MB of the disk. The FreeBSD system got 1,500MB. When I power on the system, I get a boot screen that gives me two seconds to explicitly choose an OS; otherwise it boots UNIX by default. Many of the SCU systems understand the DOS filesystem. I "mount" the 500MB partition and therefore have an easy mechanism to move files between operating systems. (I also use FTP to transfer files between another networked workstation.) Although it is possible to load the system from the Internet, this article works with a CD-ROM distribution set. CDs are cheap. A set has tons of other useful software. If you have problems, it is easy to start over if you have the media. Most of the distributions come with some instructions; FreeBSD has a booklet, OpenLinux provides a manual, etc. Generally, the CDs themselves contain documentation sometimes as text files and sometimes as html files. You can use a running system to look at these files. Each system's home Web site also provides instructions, FAQs (frequently asked questions), manual pages, and search engines to look up issues. There are also many books published to give you guidance, including The Linux Bible, The Complete FreeBSD, and one I recommend for all systems, UNIX System Administration Handbook by Nemeth et al. It would be wise to become familiar with these resources before you begin. It is also handy to have these references available while loading the system. This means another working system with Web access. The basic process for all SCU systems on PCs is:
Step 1. Finding Disk Space If you have a new disk that you are going to dedicate to SCU, jump to step 2. If you have important stuff on your disk, back it up and verify your backups. If you have an existing Win95 system spanning the whole disk, you can coalesce the files using the DOS 6.xx DEFRAG utility or Norton Disk tools. This will bring all the used blocks to the front of the disk. Then the FIPS utility (provided by many SCUs on the CD) can be used to split the disk into more than one partition. Thereafter, Win95 will have to live within its new bounds, and the new partition(s) will be available for SCU. Another possibility is having two disks and an operating system on each. The boot manager allows you to switch between them. Step 2. Booting an Installer Program Now it's time to boot your SCU's installer program. There are several possible ways: 1. With the right CDROM controller (supports "El Torrito") and the right SCU (FreeBSD for one), you can boot the CD directly. 2. On some SCUs, the installer program can be booted from the CD under DOS. 3. Most versions allow you to boot the installer from floppy. Either the floppy is provided or you can copy an image from CD to floppy using a program (rawrite.exe) under DOS or using dd under UNIX. Your installer program can be quite impressive. On a little 1.44MB floppy, you have a kernel capable of dealing with tons of hardware combinations. It also contains a user interface that must support the spectrum from novice installers to expert power users. Most installer programs are capable of loading from CD-ROM, a hard disk, or a TCP connection. Some programs include significant online documentation to help with the loading process. Some SCU systems use a second floppy as a /root disk during the install process. One crucial issue for your installer program is that it recognize the relevant hardware pieces of your system. For example, you may have the brand-new Intel DK440XL motherboard that has the new Adaptec AIC7895 SCSI chip and 10/100 Ethernet chip onboard. If your disk and CD-ROM drive are attached to this built-in bus, most existing installer programs (through June 1998) will not recognize the hardware. There are several ways around this. You could use IDE drives to load the system, then build a kernel that can handle the new hardware. You could buy or borrow a SCSI PCI board that is recognized. Or you could have someone build an installer program that knows about the new hardware. Step 3. Partitioning Your Disk Under control of the installer program, you'll have to make decisions about the disk layout. Unfortunately, the word "partition" is heavily overloaded. When talking about DOS and BIOS, there can be up to four primary partitions on the disk. One is marked as the "active" partition from which the boot will be attempted. FreeBSD calls a DOS partition a "slice." A FreeBSD partition is most like the historic UNIX partitions, where each disk drive had a label indicating how the disk was laid out. For many UNIX systems including FreeBSD, partition a is conventionally the root, partition b is swap, partition c is the whole disk, and partitions d-h are optionally used for filesystems such as /usr, /var, or /tmp. The c partition overlaps all other partitions. The disklabel command establishes the mapping between partitions and disk blocks within a slice (/etc/fstab and the mount command control the mapping between filesystems and disk partitions). Under FreeBSD, each slice can contain a full set of partitions. A scheme for naming each partition on SCSI drive 0 therefore is: /dev/sd0s{slice-number}{partition} where slice-number is 1-4 and partition is a-h (e.g., /dev/rsd0s4a , for drive 0, slice 4, partition a) If you don't need to run multiple operating systems on a single disk, you can ignore most of this slice stuff with FreeBSD. See fdisk for details. Linux uses a different scheme. If you don't need any more than four DOS partitions, you use these directly. For example, /dev/hda1, /dev/hda2, /dev/hda3, /dev/hda4 for the disk called Hard Drive A. As an example, you might have
/dev/hda1: Windows 95 In cases where more partitions are needed, Linux uses DOS "extended" sub-partitions. For an example of four operating systems on a single disk, see: <http://www.linuxresources.com/LDP/HOWTO/mini/Linux+DOS+Win95+OS2-1.html> ; <http://www.freebsd.org/FAQ/FAQ105.html#105> Step 4. Installing a Boot Manager The job of the boot manager is to load the operating system and begin its execution. This simple task is complicated by different kinds and geometries of disks, multiple IDE and SCSI controllers, various BIOSs, and the possibility of multiple operating systems on a disk. When booting, BIOS loads the first block of the disk (called the Master Boot Record or MBR) and, if it has the correct magic numbers, jumps into it. The MBR code looks at the partition table that is embedded within it to determine which partition to boot from. Then that code is loaded and executed. Soon a boot manager is running (i.e., it is capable of choosing and loading the operating system). Here is what the FreeBSD default boot manager looks like. You can see the large matrix of possibilities.
Usage: bios_drive:interface(unit,partition)kernel_name options
Examples:
1:sd(0,a)mykernel boot `mykernel' on the first SCSI drive when
one Other boot managers include LILO and OS-BS. LILO or LInux LOader is a limited boot manager that is often installed by default on Linux systems. OS-BS gives you more control over the booting process than the default boot manager, with the ability to set the default partition to boot and the booting timeout. Here is a procedure for having FreeBSD and Windows on a disk. Windows 95 is picky about where and how it is placed on the hard disk it need to be on the first primary partition on the first hard disk. You need to install Windows 95 first, then FreeBSD. FreeBSD's boot manager will then manage to boot either Win95 or FreeBSD. If you install Windows 95 second, the process will overwrite your boot manager without even asking. Then only Windows will boot. Warning: depending on how your BIOS is configured, you may not be able to boot operating systems that are in partitions more than 528MB from the start of the disk. A simple workaround is to boot the boot manager from floppy. It doesn't have the 528MB limit and can load an operating system from anywhere on the disk. For more information on boot managers, a discussion of this limitation, and some other solutions, see the following Web reference: <http://www.freebsd.org/tutorials/multios/multios.html>. (P.S. It's a good idea to have a boot floppy around anyway for disasters.) Step 5. Choosing Software to Install The installer program will give you choices as to what software will be loaded onto your disk from the CD. Some systems will allow you to select from broad categories. For example, you might be asked to choose one of the following:
Later, with a package manager, you will be able to adjust what is on your disk by adding or deleting packages. Other installer programs present you with a list where you can toggle on or off the desired subsystems. For example, with Red Hat Linux, you set * for the pieces you want installed:
[ ] Printer Support Step 6. Installing from CD At this point, you will have specified that the distribution is on CD-ROM and you are ready to have the installer copy material onto your disk. This step takes from a few minutes with a fast CD-ROM and minimal system to more than an hour. Most installers provide some kind of progress monitoring and logging. Step 7. Performing Postinstall Configuration It should be possible now to boot your system and configure it. However, it may be more convenient to let the installer program ask you a bunch of questions and then configure the system. If you will be running X11, you should know what kind of graphics card you have, the capabilities of your monitor, and your type of mouse. If your graphics card is not listed in the options, you may be able to get by with a generic SVGA X11 server. My previous article gave some references on finding software for the latest graphics cards. Be warned, configuring X11 can be tricky. There are a lot of parameters that have to be right for it to work. You'll probably have some kind of network connectivity, so you'll need a hostname, an IP number and mask, a default gateway, a domain name, and a DNS server. Hope that there were no IRQ conflicts and your installer program just cleanly found your network interface card. If not, the various systems have ways of giving the software probing hints. Often you can set the time zone and the root password from the installer program. You may also have the options of selecting what daemons get started at boot time, for example, cron, nfs, network, sendmail, syslog, etc. Step 8. Booting, Configuring, and Administering Your New System You've made it. Boot the system. Now it's just a matter of bringing in your personal environment and loading more ports or packages. You may want to add new users. You will have to configure your servers. You will want to configure and build a custom kernel and run it instead of the "generic" kernel. Not only does this make the kernel smaller, but it allows you to add nonstandard hardware drivers and other kernel features. Your boot time will be shorter if your kernel doesn't waste time probing for nonexistent hardware. You'll want to size your kernel and select various options such as NFS, DOS, and/or shared memory capability. Then you will describe your exact hardware, only these drivers will be built into the kernel. Make the kernel, install it in the root, and reboot. In Case of Trouble Sometimes just going through the procedure more than once will "fix" a problem. Because you know what to expect during the install, you are better prepared to have the "right" answers ready. I once got stuck in a partitioning menu and couldn't get what I needed. Something I had done earlier was inappropriate. I came back later after a fresh reboot, and everything worked fine. I guess the installer program was not bulletproof. If you need to revert the MBR back to Win 95, you can boot a DOS floppy and type: fdisk /mbr Find a knowledgeable friend or colleague to help you with installation problems. Go to the Web sites and use their search engines to look up questions. Try posting well thought-out, detailed questions on USENET. Be sure to include relevant details so that those folks have enough information to help you. Sometimes the way to get over a hump is to switch to a different SCU. I had problems with one distribution of Linux recognizing some hardware, but the InfoMagic Red Hat version worked fine. Find the experts for your hardware. Their SCUs usually have the best driver support. So if you are running a multiprocessor system, read the newsgroups to find the developers. If you need great fast Ethernet support, you'll find the best driver/harware combinations. It's common for one person to write code for new hardware under his or her SCU then the others import and incorporate this driver some time later. The next article will be dedicated to application packages and how to manage them.
|
 Need help? Use our Contacts page.
First posted: 17th September 1998 efc Last changed: 17th September 1998 efc |
|
Issue index