Now that you've got Linux installed on your system, you're ready to patch and recompile the kernel. This is a necessary step towards a fully functioning system; Chris Beauregard's Slackware MCA Installation Instructions make note of this on the last page. In fact, one of the "many other things that'll contribute to an enjoyable Linux experience" that I found missing from the bootdisk kernel was serial, or at least modem, support. I found myself unable to use my modem to dial up anywhere until I had patched and recompiled the kernel. So, do yourself a favor and take this step as soon as you can.
There are three things you absolutely must have to do this step -- the kernel source, the development tools, and the latest patch from the MCA Linux homepage. I also strongly recommend having the kernel HOWTO, although you can just read and remember it if you like. Depending on how you got your Linux installation packages (CD or download) and what you actually installed, you may already have some or all of these things. The kernel HOWTO, if you have it, will be in the folder /usr/doc/Linux-HOWTOs and is named Kernel-HOWTO; it was put there when you installed the FAQ (f1) packages. Just in case you don't have something, here they all are again:
You don't have to download the kernel HOWTO unless you really want to, since it's usually put on your system when you install the FAQs. Just print it out, read it, and keep it handy. It's full of very useful information that you're going to need, which, just like the installation instructions that I guided you to, I'm not presently reproducing here. Instead, I'll refer to the HOWTO as I try to walk you through what you're going to see as you proceed along the patch/compile process path.
Also note that the patch set has one of those really long filenames. If you're downloading to a DOS/Windows 3.1 system, you'll have to rename it using 8.3 file name conventions. pach2035.gz worked for me, but you can use something else if you like.
Now, you'll have to install the kernel and development packages, (unless you did this when you first installed Linux). The easiest way that I know to do this is with the setup command that you used when you did the installation. So, type
setupat the command prompt and press enter. You'll get the same setup menu that is presented for the Linux installation.
This time, however, you're going to use the PKGTOOL selection. Choose it; you'll be presented with another menu. Unless you happened to run setup from the directory that your packages are in, you'll choose the Other selection. In the "SELECT SOURCE DIRECTORY" box that's presented, type in the full path to the directory where the package is located. Note that you'll have to install the packages one at a time.
I actually had to do this when I did my installation, as part of my download didn't make it to my system intact, so I'll use my experiences (yet again :-) ) as an example. In my system setup, my DOS partition is mounted, under root (/) on a filesystem named c-drive, and all of the packages I downloaded were located in a subdirectory structure there. So, when I installed the kernel source, the path I entered in the "SELECT SOURCE DIRECTORY" box was:
/c-drive/slakware/k1and for the development package was:
/c-drive/slakware/d1Pkgtool will find the diskk1 and diskd1 files, and prompt you through the different packages in the d1 and k1 package sets. Install the entire k1 package set -- you'll need it all. You may want to also install the entire d1 package set to avoid figuring out which packages you need and which ones you don't. If you don't want to install the entire set, make sure you do install anything and everything necessary that has to do with compiling C/C++ programs. This includes the binutils, gcc, gmake, and libc packages at a minimum. You may want to include things like gdb (the gcc debugger), libcinfo (the info files for the C library), and anything else that mentions C/C++, just in case you need them. You can safely skip the three egcs* packages. Of course, if you're into program development, you'll probably wind up installing this whole package set anyway, won't you? :-)
Using the above method to install the kernel source on my system, I found some differences than what was discussed in section 3.2 of the kernel HOWTO. The kernel source was installed into a directory with the name of the kernel version. When I did a cd to /usr/src, I discovered that the directory named "linux" was simply a link to the directory named "linux-2.0.35," which is what the kernel HOWTO recommends changing the "linux" directory to before unpacking the source into a new "linux" directory. What I did, then, was to copy the entire "linux-2.0.35" directory to another directory named "linux." That way I had a backup for the source tree in case something went wrong (it didn't). If this is the first time you've ever done something like this, I recommend you do the same, if only for the peace of mind it gives you. :-) Note that if you install your kernel source this way, you don't have to worry about knowing anything about the 'tar' command used in section 3.2 of the kernel HOWTO. Don't worry -- you'll have plenty of time to learn.
Now you've got the kernel source installed, and the development tools you need as well. You're going to need one more thing -- the README in /usr/src/linux you're told to look at in section 3.2 of the kernel HOWTO. Instead of just reading over it, you may find that you want to print it out. This will be kind of difficult on your new Linux system -- parallel printing support is one of the things that Chris Beauregard told you that would be missing in the kernel you installed from your bootdisk. That's why you're patching and recompiling immediately after installing, remember? It's OK, though. You can get that file printed out without much problem. It's just a plain ASCII text file.
If you left a DOS/Windows partition on your Linux system, and you're mounting that partition (you told setup you wanted to do this, right?), you can just copy the README into a directory there, then boot to that partition and print it out from there. At the Linux command prompt, in the /usr/src/linux directory, type:
cp README /[your DOS partition name]/[some directory(s) there]where [your DOS partition name] is whatever you're mounting your DOS partition as, and [some directory(s) there] is exactly that, some directory off of your DOS root directory, or a subdirectory underneath (my personal favorite for stuff like this is TEMP). So, for example, on my system this would be:
cp README /c-drive/tempThen, you'll boot to your DOS/Windows partition and use whatever you like to use to print ASCII text.
If you don't have a DOS/Windows partition left on your Linux system, you'll have to copy the file onto a floppy disk and take it to a computer that can print. First, you'll have to tell Linux that you want to use the floppy drive. This is called mounting the drive (actually you're mounting the filesystem for the drive). Here's what to do:
mount -t msdos /dev/fd0 /somefoldername
One popular directory name for a mount point is /mnt. Several sets of instructions for using mount use /mnt or a subdirectory under /mnt as a mount point. I personally wanted something familiar, something that I would recognize as the location for mounting my floppies, so I named the directory I created for my floppy mount point /a-drive.
Anyway, once you've mounted your floppy disk, you'll copy the README to it in the same way as above:
cp README /somefoldernameand then take it to another system to print it out.
And remember, you don't have to go through all this (although it does give you some good practice at using your Linux system). You can just look at the file, and try to remember the important points, or take notes. The thing is, the kernel HOWTO refers to it, and I'm referring to the kernel HOWTO, so I want to make sure that you've at least seen all of the information available to you for this procedure.
And you will be using information from the README for the next step. Just as the kernel HOWTO says, you want to use the section entitled "INSTALLING the kernel" for patching the kernel source, setting links, and removing stale dependencies. Just follow the steps listed in the README for doing those things. Type in the commands just as they are given; a few notes on them follow.
First make sure you're in the right directory, if you changed to print the README:
cd ..This changes you to the parent directory. Don't do this unless you changed directories to print the README. Also make sure you include the space between the "cd" and the "..". You should now be in /usr/src. If you just plain lost, just enter
cd /usr/srcand you'll be in the right directory.
You're only going to apply one patch, the one from the MCA Linux homepage you downloaded. Also, if it isn't glaringly obvious with the font you used to view or print the README, notice the following about the patching command(s) (which I've duplicated here):
gzip -cd patchXX.gz | patch -p0 <-- This is a zero!
Actually, all you've done here is use your (now) old friend gzip to unzip the patch file, then feed the output to the patch utility, using a pipe. This may actually be familiar to you, as DOS uses pipes, too. Just make sure that you do include the spaces between the commands and the pipe symbol (|). While you can get away with omitting the spaces in DOS, they are necessary in Linux (Unix).
You can also try the patch-kernel script discussed in the README if you like. And section 5 of the kernel HOWTO gives additional information on applying a patch.
Now, you can just type in the next two sets of commands from the README without really worrying about the details of how they work. The ln command creates symbolic links (that's what "symlinks" means) to the appropriate include files. You'll most likely learn more about this utility as you work with your Linux system -- Unix uses links to do all kinds of things. You can get more information about it from the man pages. You'll have them if you installed the applications package set (ap1). Just type
man lnat the command line, and you'll get several pages of information.
The make command invokes the make utility on Makefile(s) that are installed along with the rest of the kernel source. The Makefile(s) actually contain all of the commands and switches that the compiler needs to do its work. So, when you enter
make mrproperas specified in the README (after changing to the correct directory), you're using certain commands and switches in a certain Makefile to do some preparatory cleanup. If you are interested in programming and/or understand about invoking a compiler from the command line, you can get more information about the make utility from the man pages, too; additional information can come from reading the Makefiles themselves.
Now that you've applied the patch and finished setting everything up, the next step is to configure the kernel. For me, this was probably the most time-consuming part; but then again, I read and reread everything that was presented to me, so you wouldn't have to. ;-) I also had to do this several times, as I made some mistakes the first time through, and my kernel compile failed. So much the better for you. :-)
The alternate configuration commands that the kernel HOWTO and README discuss are most likely meant to be used on a fully functioning system. I know that you won't be able to use "make xconfig" unless you've been able to wave a magic wand and get X Windows running. And, as far as I know, you won't be able to do that until you get finished with this procedure.
On the other hand, you did install ncurses if you installed all of the development packages. You're welcome to try "make menuconfig" if you like; I was somehow under the impression that there was some additional setup needed for ncurses and didn't mess with it.
The kernel HOWTO and README also emphasize "make config" needs bash to work. You may be wondering what "bash" is. bash is your command shell. The shell is the process that supplies your command environment. DOS has a similar concept, one you may recognize if you've ever put a SHELL= line in your config.sys file. That's the idea here, except you have several choices for your shell, and a Linux shell environment is significantly more powerful than the DOS command line.
Anyway, bash is the default shell that you get when you first install Linux, and it's the one that starts up when you start your system. You have to give a command that invokes another shell to be using one, and you would have to make some configuration changes to have another shell start up on system startup. Unless you've played with the base system for a while and figured this out, you don't have to worry about this right now.
The README doesn't refer to the individual kernel configuration options at all; the kernel HOWTO discusses many of them, but not necessarily in the order in which you will encounter them. Since I'm assuming that this is the first time you've ever done something like this, I will try to at least mention each one, except for a few that you are very unlikely to see, in the order in which I saw them. In some cases I'll have something to say about the option, in others I won't; and in yet other instances I'll simply refer to the kernel HOWTO, if that's where the best description of what you're doing is. I'll also note what response I gave for each option, and why, if I think it'll help you.
The responses you'll make for most of the options will be of one of two forms, either
y/n/m/?As noted in the kernel HOWTO, the ? will give you some help in the form of a description of the option; m will cause the option to be compiled as a loadable module; y is for yes and n is for no. The order of the responses varies, I guess according to how strongly recommended a particular response is. And the help descriptions actually were pretty helpful, at least to me, even if I did read some of them more than once. So you may want to look at them, too. Also, several of the options had the word 'NEW" in brackets next to them the first time I did this. I believe these were options that were added during the patch of the kernel source.
So, you're going to type
cd linuxand press enter to be in the /usr/src/linux directory; and then
make configand press enter. Here is approximately what you'll be asked.
Prompt for development and/or incomplete code/driversAsks if you want to compile in support for experimental drivers, protocols, etc. I said no here. You should too. You'll have plenty of time to do this sort of stuff, after you get familiar with Linux. Note that if you do say yes here you'll see some additional options that I don't mention.
Enable loadable module supportCompile in support for loadable modules. I said yes here. You should too. Loadable modules give you the ability to load device drivers and/or protocols (for example) at will. Say you know you won't use your sound card very often at all. You can compile its driver as a loadable module, and then only load the driver when you want to, using insmod and rmmod. (For more information on those commands, see the man pages -- we don't want to go into their details here.) ? will direct you to the modules.txt file in the Documentation directory -- and you may want to take a look at it.
Set version information on all symbols for modulesLets you create modules that don't depend on the version of the kernel under which they run. I originally said yes here, but changed my mind and said no during a later kernel configuration, because I found out that this only really applied to modules that didn't come with the kernel. I didn't have any of those, and didn't anticipate getting any, so the option had no value to me. The ? response was pretty helpful to me here.
Kernel daemon support (e.g. autoload of modules)Compiles in support to load some modules as daemons. I said yes. Daemons are analogous to DOS TSRs, and the kernel will load many of them automatically at system startup.
Now will be some general setup options.
Kernel math emulationLet the kernel emulate a math co-processor. I said no, as I have a DX-2 processor. See section 3.3.1 of the kernel HOWTO for more information.
Networking supportEnable support for networking. I said yes. You should too. Even if you don't have a network adapter. This is how you get to compiling in support for Internet protocols and such, many of which are used for dial-up access. See section 3.3.3 of the kernel HOWTO for more information. The particulars come later.
Limit memory to low 16MBFor certain buggy motherboards. I said no. You'll probably know if you have one of these. See section 3.3.4 of the kernel HOWTO and ? for more information.
PCI bios supportCompile in support for PCI. I said no. You will too, unless you happen to have a PCI/MCA system. Select ? for more information.
Seriously, I can't stress enough how important this option is. You must compile in MCA support here. If you don't, you won't be offered several other MCA specific options later, like support for the MCA SCSI adapters, for example. So, say yes here!
System V IPCSupport for System V Inter Process Communication. Just say yes to this. System V is one of Linux's ancestors, and Inter Process Communication is just that -- processes communicating with each other. Many programs have to have this. See section 3.3.5 of the kernel HOWTO and ? for more information.
Kernel support for a.out binariesSupport for an early format for libraries and executables. You really want to say yes. Many programs still use it. Select ? for more information.
Kernel support for ELF binariesSupport for the newer format for libraries and executables. You'll want to say yes here, too. Many newer programs use this. In fact, this is the format in which you want to compile your kernel (more on this below). Select ? for more information.
Compile kernel as ELF - if your GCC is ELF-GCCJust as the option says -- compile the kernel in ELF format. Say yes here. You're installing kernel version 2.0.35 and GCC (your C/C++ compiler) version 126.96.36.199, so your GCC is ELF-GCC. In fact, I originally said no here and my compile failed. While there were other reasons for that, too, I'm sure this played an important part. Select ? for more information
Processor type (386, 486, Pentium, PPro)Select your processor type. I said 486, since that's what I have, and I don't intend to use this kernel on any other system. Choose what you have. 386 works on all machines. See section 3.3.6 of the kernel HOWTO and ? for more information.
Next are options for various block devices. Block devices are things like floppy drives and hard drives. This group of options covers floppies, IDE, ESDI, etc. SCSI will come later.
Normal floppy disk supportJust what it says. I said yes. You'll probably want to, too, unless you don't plan to use your floppy drive. :-)
Enhanced IDE/MFM/RLL disk/cdrom/tape/floppy supportAgain, just what it says. I said no here. You will too, unless you've got a system with IDE. See the section 3.3.2 of the kernel HOWTO and ? for more information; you may also want to look at the ide.txt file in the Documentation directory. Note that the kernel HOWTO assumes you'll say yes here. That's because it was written with the user of a "standard" system in mind. Don't let it confuse or mislead you.
What you'll see next depends on what you just answered. If you did say yes, you'll see several options for several IDE devices, and other related items, such as SCSI emulation and various chipsets. I'm afraid you're on your own here, as I have SCSI in my system and didn't see any of these. Section 3.3.2 of the kernel HOWTO contains a small amount of information, and a quick look through the Configure.help file (where the information you get when you press ? comes from) suggests that pressing ? will give you some decent guidance here.
If you said no to IDE support, as most will, this will be next.
Old harddisk (MFM/RLL/IDE) driverThis, too, is pretty much what it says -- support for old hard disks of these types. If you said no to the enhanced driver, you can say no here, too. I did.
Continuing with the remaining block devices . . . .
PS/2 ESDI harddisk supportYet again, just what it says. I said no due to the previously mentioned SCSI. What you say depends on what you have, and you should know what you have by now. :-)
Loopback device supportLets you mount a file as a filesystem, or a filesystem with encryption. I compiled this as a module, just in case I wanted to investigate it further sometime. Unless you burn CDs or something, you'll probably say no here. Press ? for more information.
Multiple devices driver supportLets you combine several hard drive partitions into one logical block device. This is most likely related to RAID, because if you say yes here you get some options for different RAID levels (modes). I said no. It's likely you will, too. Press ? for more information. Note that the drivers/block/README.md file referenced there is totally worthless. :-)
RAM disk supportAllows using a part of RAM as a block device. The idea is probably similar to a DOS ramdisk, but it's most commonly used for loading and storing a minimal root filesystem from a floppy during the initial installation. It's not really needed later. I said no. Press ? for more information, and read the Documentation/ramdisk.txt file referenced there if you're really interested in this. Note that if you say yes here, you'll be asked if you want initial RAM disk support as well.
XT harddisk supportAs it says, support for the (very) old XT controller. I said no here, and you probably will too. Press ? for more information
Parallel port IDE device supportSupport for external IDE devices that attach through the parallel port. I actually said module here since I have access to a CD-ROM drive that I may want to use sometime. Press ? for more information; get details from the Documentation/paride.txt file.
If you do say yes or module above, note that you are required to select at least one high-level driver (the kinds of devices) and at least one protocol driver (the individual devices themselves). The options for the high-level devices come first, followed by the options for the protocols. If you are making use of this option, just read the selections and use the ? information to set up support for the device you want to use. Note that this is for IDE and ATAPI parallel port devices only -- support for SCSI and "Ditto" parallel devices, among others, is not included.
Next are options for networking. These are basic options, like protocols, not the actual devices, which come a little later. Many of these will get only a brief mention, as I didn't enable them and there are others which need to be enabled, and therefore discussed. I will try to go into more depth about these options.
Network firewallsNeeded if you intend to use your system as a network firewall. Press ? for more information.
Network aliasingFor enabling the use of multiple IP address by one low-level device driver. Press ? for more information, and read the Documentation/networking/alias.txt file referenced there.
TCP/IP networkingTCP/IP is the core protocol of Unix networking and the Internet. Some of the programs you install will use it too. You'll most definitely want to say yes here. Press ? for more information.
Once you say yes to TCP/IP, you'll be presented with several options related just to it. I won't go into all of the details here. You can press ? to get information on any of them if you're interested, and unless you have special network needs, you'll probably say no to most of them anyway.
The IPX protocolSupport for the Novell networking IPX protocol. Press ? for more information.
Appletalk DDPSupport for the Appletalk protocol. Press ? for more information.
Amateur Radio AX.25 Level 2Support for a protocol that allows computer communication over amateur radio. There are other options if you say yes here. Press ? for more information.
Kernel/User network link driverAllows some sort of specific internal system two-way communication. One thing it's used for is publishing network messages. It also seems to be experimental code. I said yes here, because I wanted to look into it further. Press ? for more information. Note that if you do say yes, there is another option to enable message routing, needed for the above message publishing.
Next is support for SCSI devices. Note that almost all of these options can be compiled as modules.
SCSI supportSpeaks for itself. I said yes! If you have SCSI, you will too. Mentioned briefly in section 3.3.7 of the kernel HOWTO. More information is also available by pressing ?, and there is a SCSI HOWTO as well. Note that you must say yes if you want to use a ZIP drive.
SCSI disk supportAgain self-explanatory. This is also what gets you to support for the ZIP drive. Press ? if you want any more information.
SCSI tape supportAnd again. Press ? for more information.
SCSI CD_ROM supportAnd yet again. Press ? for more information.
SCSI generic supportEnables access to any other SCSI device, like a scanner or CD-R. Those devices will still need their drivers, but this lets you access them. Press ? for more information.
A couple of general options . . . .
Probe all LUNs on each SCSI deviceFor devices that support multiple Logical Unit Numbers, like CD jukeboxes. Press ? for more information.
Verbose SCSI error reporting (kernel size +=12K)Makes any error messages about your SCSI hardware easier to understand.
Next are all of the low-level SCSI drivers -- the drivers for the devices themselves. These devices are actually the available SCSI controllers/host adapters. I won't mention each and every one -- there are way too many -- but will instead focus only on those that I know might be found in a PS/2 -- or attached to it. You can look at the rest more in depth yourself if you like -- you'll have to go through the list of them anyway.
Adaptec AHA1542 supportSay yes or module to this if you have an Adaptec AHA1640 host adapter. Yes, misleading I know, but they use the same driver.
If for some odd reason you don't see the next two options, it's probably because you somehow missed saying yes to "MCA bus support". They aren't even offered if you didn't set it. And you'll have to go back and start "make config" over again. But this didn't happen to you, did it? :-)
IBMMCA SCSI supportThis is what provides support for our beloved IBM SCSI Adapter with cache. If you have a SCSI system, you're almost certain to say yes to this, aren't you? :-) Press ? for more information. Note that it might not be found on some systems on boot, but there are boot parameters you can use to fix that. You can also change the SCSI device scanning order.
Future Domain MCS-600/700 (and IBM OEM) SCSI supportAhh, but maybe you'll be certain to say yes to this instead. In addition to the Future Domain adapter listed, this option also provides support for the IBM Fast SCSI Adapter /A. And it supports the SCSI part of the Reply SB/SCSI Adapter.
IOMEGA Parallel Port ZIP drive SCSI supportHere's the support for the ZIP drive. You'll say yes or module if you have one. Press ? for more information, and maybe look at the drivers/scsi/README.ppa file referenced there. Also note that there is a setting that follows this one for the drives with the buggy chipset.
Now we get to the support for network devices.
Network device supportEarlier you chose to enable network support. That enabled the use of whatever protocols you thought you might need to use. This option gives you access to enabling network devices. You'll probably want to say yes here even if you don't have a network card, because this is where you also specify support for things like PPP. See section 3.3.8 of the kernel HOWTO.
This is another area in which there are lots and lots of options, even more than the SCSI devices. Here again, too, there are some major options and then those options available if you chose a given major option. I'll discuss the major options, for the most part.
Dummy net driver supportUsed to consign some "traffic" to the bit bucket. It's usefulness is primarily with the dial-up protocol SLIP. I said module here. Press ? for more information.
EQL (serial line load balancing) supportUsed with two serial connections (to another computer) consisting of two phone lines and two modems. Press ? for more information.
PLIP (parallel port) supportLets you connect computers using the parallel port. Press ? for more information.
PPP (point-to-point) supportGives you support for the PPP dial-up protocol. You'll have to have the program pppd, too. I compiled this as a module, but it loads automatically at boot-up. Press ? for (lots) more information.
SLIP (serial line) supportGives you support for the SLIP dial-up protocol. This isn't as good as PPP, but you may have to use it if that's what your Internet service provider supports. Press ? for more information. Note that there are a few options for this that makes it work a little better. Press ? for more information about them, too.
Radio network interfacesRemember the amateur radio support? This enables the devices.
Ethernet (10 or 100Mbit)This is where, at long last, you'll enable support for your Ethernet card, if you have one. Say yes or module if you have one (and intend to use it :-) ). You'll go through options for various ISA, EISA, and PCI selections; say no to them until you get to the option to choose "MCA Ethernet cards". Say yes or module, then yes or module for whichever one of the three offered NICs that you have. Then go past the remaining Ethernet options with no's.
Token Ring driver supportJust what it says. The only MCA Token Ring support is for the IBM card with the Tropic chipset.
FDDI driver supportAgain, just what it says. Unfortunately, I couldn't find any help for this option.
ARCnet supportSupport for ARCnet cards. There are two types of packet formats. Press ? for more information.
Next is support for ISDN devices. I don't have ISDN, so I didn't use this option. I can say that there is some PPP support, and that there aren't very many devices supported. If you have ISDN, hopefully pressing ? and the READMEs it references will tell you all you need to know.
After that comes support for non-SCSI/IDE/ATAPI CD-ROM drives. There's only a handful of devices here, too. You'll probably just say no here, but you can always press ? to get more information.
Next you'll configure the filesystems you're going to use. This sets up the filesystem formats that your Linux system will recognize as valid. At the least, you'll be able to read and list files in formats other than the Linux native format, and in some cases you'll be able to write the files (as in moving and copying) to disk. Note that any of these filesystems can be compiled as a module, but in many cases you'll run across restrictions on how you can use them. I recommend you decide what you need and just compile it directly into the kernel.
One way to determine what filesystems you'll need to support is to get a list of those you are currently using. These were probably set up when you installed Linux, and should be an accurate indicator of your needs. So if you type
mountat the command prompt, and press enter, you'll see a list that resembles the one in section 188.8.131.52 of the kernel HOWTO. The listed "types" are the filesystems you need to support in your kernel. The only exceptions would be if you were planning for some future need (i.e. including VFAT support for a planned Windows95 installation on an existing DOS FAT-16 partition); or including support for one of the more obscure filesystems that you know is on another partition, but the installation bootdisk wouldn't recognize.
Section 3.3.9 of the kernel HOWTO describes some of the supported filesystems; pressing ? will get an explanation of each of them. And if you haven't gotten tired of reading so much stuff by this time, I would suggest that you do read those explanations. There are little bits and pieces of interesting information scattered about all over in there.
Quota supportGives you the ability to set quotas on user disk usage. It requires another program, and isn't necessary on a single user system anyway. I said no to this.
Minix fs supportThe smaller, leaner Unix that was the Linux original format. Not used very often, except possibly for rescue floppies. I said no.
Extended fs supportThe current native Linux filesystem's predecessor. It appears to be very unpopular. I said no to this, too.
Second extended fs supportThe current native Linux filesystem. Unless you did a umsdos installation, you'd almost have to say yes.
xiafs filesystem supportAnother old filesystem that also seems to be quite disliked. I said no.
Native language support (Needed for FAT and ISO9660)Just what it says. Even if you don't need support for the DOS-y FAT-based filesystems, you'll have to say yes to be able to read the current standard CD-ROM format. If you do say no here, you won't see several of the options I've listed next.
ISO9660 cdrom filesystem supportJust what it says, too.
DOS FAT fs supportThe basis for the other FAT-based filesystems. You must say yes to this if you want to use them. I did so I could access the DOS partition I left on my system. (I'm still trying to decide what to do with it -- I haven't booted it in a really long time.)
MSDOS fs supportThis the real support for the FAT-16 disk structure. It lets you read and write DOS floppies, and run your DOS programs using the DOS emulator, DOSEMU. You must also say yes to this if you want to use the umsdos filesystem. PC-DOS (aka IBM-DOS) is essentially the same thing, so you'll say yes for it here as well. I'm afraid that I don't know about any of the other DOSs, like Caldera's DR-DOS. Sorry.
umsdos: Unix like fs on top of std MSDOS FAT fsPretty self-explanatory. And if you say yes here, you more than likely installed Linux to run this way anyway. And already know a whole bunch more about it than I do. :-)
VFAT (Windows-95) fs supportAgain, somewhat self-explanatory. Saying yes here lets you work with Windows95-style long filenames, too.
What follows now is a long list of the DOS codepages (the DOS character sets). I'm not listing them -- there are too many. Pressing ? tells you the language(s) a given character set works best with. I live in the United States, so I said yes to codepages 437 and 850, and character set ISO 8859-1.
/proc filesystem supportThis is the option that immediately follows the "Native language support" option above, so if you said no to that, this is the next option you'll see. All of the documents say that there are programs that depend on having this, so you should say yes. And the /proc filesystem really is as cool as the documents say -- you can get all kinds of interesting information from it. And you'll most likely want to make use of it when you get ready to configure X Windows.
Including /proc filesystem support now allows you to include NFS (Network File Sharing) support, if you included network support. NFS support lets you mount files that are actually located on some remote system to which you are connected. You can also choose to mount your entire root filesystem from a remote system; and then add the capability to obtain your IP address from that system using BOOTP or RARP. Remember, you must have the appropriate connections for these options to work. Press ? for more information on them.
SMB filesystem support (to mount WfW shares etc..)This is Microsoft's Server Message Buffer protocol. It lets you mount the filesystems of Windows computers to which you are connected and use them like any other Unix directory. If you do say yes here, you'll also want to say yes to enabling the SMB Win95 bug work-around. Press ? for details.
NCP filesystem support (to mount NetWare volumes)You'll only see this if you enabled IPX support when you selected networking options. Press ? for more information.
OS/2 HPFS filesystem support (read only)Self-explanatory. Press ? for more information.
System V and Coherent filesystem supportWritten for the Intel architecture too, Coherent is a variant of one of the grandaddy Unixes, System V. There are others, to be seen by pressing ? for more information. You'll most likely say say no here, although yes also lets you compile in support for the Amiga.
UFS filesystem support (read only)Saying yes to this option lets you mount partitions, for reading only, containing such operating systems as FreeBSD, SunOS, and NeXTstep, variants of the other grandaddy Unix, BSD. You'll most likely say no here, too.
Next is support for character devices. These are things like the serial and parallel ports, and the mouse. Remember from the MCA Linux yinstallation instructions that parallel printing and mouse support aren't included on the installation bootdisk. And I discovered that serial support wasn't there either -- at least it wasn't for me. So this set of options is just about as important as hard drive and networking support. There's a little information on character devices in section 3.3.10 of the kernel HOWTO.
Other character devices include multiport serial adapters and certain kinds of tape drives. Also included here are miscellaneous devices, Advanced Power Management, a Watchdog timer device (a special file that causes the computer to reboot if it's not written to in a certain amount of time), and the Real Time Clock. There are only a few things that are of any real interest, however.
Standard/generic serial supportThis is your basic COM1, COM2, etc (as they're known to DOS/Windows). I said a resounding yes so I could finally use my modem. You can press ? for more information, but unless you have some kind of special needs, you'll probably say yes too.
Parallel printer supportThe standard parallel printer port(s), known to DOS/Windows as LPT1, etc. I said yes. You will too, unless you want to use PLIP and you only have one port, in which case you'll say module. Or unless you just don't want to be able to print. ;-) Press ? for more information; also look at the documents referenced there.
Mouse support (not serial mice)Just as it says. Of course, I said yes here, and you will too. Enabling this option makes several types of mice available, but there's only one you're interested in. :-)
PS/2 mouse (aka "auxiliary device") supportThe only mouse for a PS/2 user, right? Just say yes. The Busmouse HOWTO referenced when you press ? has some additional information, like it's IRQ and such, about this mouse if you're interested. And if you really do have another kind of pointing device, take a closer look at the other options as needed.
Next is sound card support. I won't go into a great deal of detail here, since I don't have one and can't document this from experience. As near as I can tell, you'll need to have the specifications and configuration of your card readily available. There seem to be a few basic kinds, such as SoundBlaster, that you select from; then you set things like it's IRQ, DMA and I/O address. I did not notice any of the PS/2 sound cards with which I am familiar, so unless they are 100% compatible with the cards in the list, they may not be supported. I just don't know. There's some additional information in section 3.3.11 of the kernel HOWTO.
The final options are the kernel hacking options. These are discussed in section 3.3.13 of the kernel HOWTO. This is also an option to which you'll just want to say no.
You can check the top-level Makefile now if you wish (since a message telling you to appears), but if you don't understand anything you see, you can just skip this part.
There's just a couple of things left to do to be ready for the actual kernel compilation. The first is to set up dependencies correctly so things like include files are in all the right places. The second is to clean out any old file versions. So you'll type
make cleanand let the compiler do it's preparation thing.
Now you're finally ready to compile the kernel itself. Get yourself a book or something, because this could take a while. (Mine took about 45 minutes or so.) Type
make zImagepress enter, and sit back and hang out. You'll want to keep half an eye on your system so you can see if any error messages come up. We don't expect them, but just in case . . . .
You'll know that you were successful if you didn't see any error messages and there is a nice, new kernel image in the directory /usr/src/linux/arch/i386/boot. So type
cd /usr/src/linux/arch/i386/bootto change directories. Then type
ls -lto get a directory listing. There at the bottom of the list should be a file named zImage.
There's no reason to panic if the compile does fail the first time around. There can be lots of fairly simple reasons for it that are easily fixed by running "make config" again, and rethinking the original configuration decisions. For example, on my first pass through the kernel configuration I put in all kinds of stuff that I didn't really need, but thought might be useful. In addition, I didn't support ELF binaries properly, or compile the kernel as an ELF binary. As a result, my first attempt at compiling failed. Horribly.
I tried "make zImage" again, this time watching for the error messages, but alot of what I saw went by too quickly on the screen. Fortunately, there's a way to simultaneously send the output to both the screen and a file. Discussed in section 11.1 of the kernel HOWTO, it's called the tee utility, and I used it with "make zImage" (yet again) like this:
make zImage 2>&1 | tee somefilenamewhere "somefilename" is the name of the file to be sent the output of the "make zImage" command. In my case the file was named "kernelerrs.txt". Since the file is just plain ASCII text, you can name it pretty much anything you want.
Taking advantage of the tee utility as above allows you to read any error messages you got when you "made zImage". You'll use the cat command to do this, and you'll most likely have to pipe that output throught the more utility. This is used like this:
cat [somefilename] | moreYou'd then go through the file line by line using the enter key, or page by page using the space bar. When you're through looking at the file, press q to quit.
Another way to accomplish the same thing is the less utility. You'd call it on the file name, like so:
less [somefilename]and then move through the file the same as above. The nice thing about the less utility is that you can scroll up and down through the file using the up and down arrow keys.
Unfortunately for you, I'll have to leave you on your own here. I can't see your error messages, so I can't tell you what went wrong. :-) You'll just have to read and interpret them on your own. I believe most of them explain themselves in a fairly straightforward manner -- at least the ones I got did. Section 7.3 of the kernel HOWTO discusses some of the reasons a compile may fail.
Once you've compiled the kernel successfully, you're almost finished. First you'll do a "make modules" in the same manner to compile all the options you chose to use as modules. Then you'll do a "make modules_install" (as noted in the kernel README) to install those modules. The "make modules_install" mostly puts them in the right places and does some set up for them, like making insmod and rmmod, among others, available for use. Section 9 of the kernel HOWTO has a discussion of the modules.
And, of course, you'll want to install your new kernel. This basically involves copying it over the old one and rerunning LILO, as discussed in the kernel README and section 4.4 of the kernel HOWTO.
You might want to back the old one first up just to be safe. This really isn't necessary, I suppose, but it sure gave me some peace of mind when I did it. If you want to do this, type
cd /to get to the root filesystem, then copy the "vmlinuz" you find there to a safe place. The location of that safe place is up to you. I created a directory named "bootbak" or something like that and copied it there:
cp vmlinuz ./bootbakThen, I installed the new kernel by changing to the directory (mentioned above) that it was in and copying it over the old kernel.
cd /usr/src/linux/arch/i386/boot cp zImage /vmlinuzAlternatively, you can just leave the new kernel where it is, and just add it to lilo.conf in that location before rerunning lilo. This conditional kernel install is discussed in section 11.2 of the kernel HOWTO.
Once the new kernel is installed in root, you'll need to reconfigure and rerun lilo. You should already be a little familiar with LILO, since you got an introduction to it when you did your Linux install. You can look at /etc/lilo.conf if you want, and you'll have to add the backup kernel image, or the new one if you didn't install it in root, if you want to have them as additional options. Once you've got lilo.conf set up the way you want it, just run the "lilo" command to install the new configuration.
And that's basically it. You can now reboot your system. You might want to have a tested boot floppy on hand just in case, but you should be able to just boot to the new kernel. If you do have trouble, section 7 of the kernel HOWTO lists several things that can cause problems, and how to deal with them.
But hey, you're good at this right? You won't need any of that stuff, now will you? :-)
Back to my main PS/2 page