Linux Gazette July, 1995

A Publication of the Linux HomeBoy WebPage Series

Copyright (c) 1995 John M. Fisk fiskjm@ctrvax.vanderbilt.edu

The LINUX GAZETTE is now a member of the LINUX DOCUMENTATION PROJECT.
For information regarding copying and distribution of this material see the
COPYING document.
Linux Home Boy Pages logo created using David Koblas' excellent
program XPAINT 2.1.1

About a year ago, after getting my first glimpse of the internet via a dial-up
2400 baud VAX account (ouch!...), I started reading about a freely available
UN*X-like operating system that would let you run a unix operating system on an i386
or better PC. Sounded good to me...

So... after spending days tying up the dial-up line into the wee hours
of the morning, AND after spending 45 bucks in floppies, I finally managed to get
a copy of Slackware 2.0.0. I spent an entire afternoon thereafter shoveling
disks in and out of my PC and watching dialog after dialog describe what was happening.
Eventually, I managed to get it all loaded up, rebooted, and presto!...

LINUX!

I got hooked! This thing was awesome, huge, and bewildering. At times it was
so frustrating that I was sure it was either a 120MB virus in disguise... or possessed.
Eventually, I started making some headway and things worked! Now, I was really
hooked. What had happened was that by reading everything I could find --

and several general books on UNIX such as A Student's Guide to UNIX by
Harley Hahn, Essential System Administration by Aeleen Frisch, and
Shell Programming by Kamran Husain.

and then playing around with things until they either worked or broke (fortunately,
mostly the former :-), Linux finally began to make sense to me.

If you're in the same boat... keep paddling! The result is definitely worth it!
Running Linux means having to do your homework. It's a matter of reading and learning
until things make sense. There are LOTS of folks out there who are more than willing
to help and have invested a LOT of time into writing the documentation that makes
Linux knowable.

Great software without the knowledge to run it is pretty useless.

Sermon over. What I've tried to do with the Linux Gazette is pass along
some of the ideas that I've tried, liked, and have worked for me. Just one caveat:

This ain't technical wizardry and it won't advance you to gurudom...

Hopefully, what it will do is make running Linux a bit more fun, enjoyable, or
easier. This is a compilation of ideas I've shamelessly plagerized from so many
sources that, quite frankly, I'm not sure where some of them came from, let alone
being able to give due credit to the originator. And so... to the great nameless,
faceless, unknown but all-knowing Linux gurus (ooh, kinda spooky, eh?)...

What I'll try to do is make this as pleasant, or at least as painless, as possible.
It's admittedly a bit loose and rambly and probably best purused when you've got a
bit of time to browse...

eh?... what?! Your student account at rigid.frigid.toxic-megahosers.edu times
you out at 2 minutes of inactivity?! Hosers.

Try this. If you're running a PPP account set up a small shell script:

#!/bin/sh
#program: hose-em
#purpose: keeps a dial-up line from timing out while you're
# reading Web stuff or doing your laundry (OK... let's be
# responsible)
#
# We'll use the gateway server as your host.
HOST=000.00.00.000 # the dotted-quad address of your gateway which
# you can get by typing "ifconfig"
SLEEP=8m # how long we'll wait between pings
###############################################################################
#
# Set up a while loop that pings the host as long as the PID file exists.
# But first, make sure that the connection is still up.
#
if [ -e "/var/run/ppp0.pid" ]; then
echo "
* * * PPP-UP is running * * *
"
else
echo "
* * * PPP0 interface is not up! * * *
"
exit 1
fi
while [ -e "/var/run/ppp0.pid" ] # Now, set up the while loop.
do # As long as the PID file exists
ping -c 1 $HOST > /dev/null # we'll ping the host once every 8 min.
sleep $SLEEP
done
exit 0

you'll notice we use the ping -c 1 designation -- that keeps ping from
endlessly pinging. Set the variable SLEEP= to whatever interval you
need. And that's it! Don't forget to chmod 711 hose-em when you're
done.

Now, you can browse in peace. When you terminate the link, the while-loop ends
and ping goes back to sleep.

...and you finally discover /etc/issue and /etc/motd. And after
hacking away on them until they finally say anything besides the usual
brain-dead information about what kernel this is... you reboot.. and there it
is AGAIN!!. Arggghhh!

So what happened? There's a line of code in your /etc startup files that
resets the /etc/issue and /etc/motd files back to their original. BTW... /etc/issue
is the first message that is displayed immediately before the login prompt, while
/etc/motd (Message Of The Day) is displayed once a user has successfully logged in.

To fix this you'll need to edit one of those obscure config files in your
/etc/rc.d directory. You'll need to edit /etc/rc.d/rc.S and look for:

# Setup the /etc/issue and /etc/motd to reflect the current kernel level:
# THESE WIPE ANY CHANGES YOU MAKE TO /ETC/ISSUE AND /ETC/MOTD WITH EACH
# BOOT. COMMENT THEM OUT IF YOU WANT TO MAKE CUSTOM VERSIONS.
echo > /etc/issue
echo Welcome to Linux `/bin/uname -a | /bin/cut -d\ -f3`. >> /etc/issue
echo >> /etc/issue
echo "`/bin/uname -a | /bin/cut -d\ -f1,3`. (POSIX)." > /etc/motd

If you look closely at what this does, it echo's several lines into your
/etc/issue file, thereby wasting whatever you'd previously written, and it does
the same with your /etc/motd file. Now, thing to do is comment these out by
simply putting a &quot # &quot in the beginning of each of these lines. Now,
you can go ahead and edit your issue and motd files and know that
when you boot up again... they'll be there!

While we're talking about fixing up boot up stuff... if you're using bash (which
most folks running Linux probably are since it's often installed by default) then
there's a great little config file you need to get aquainted with:

Your ~/.bash_profile

Two cent tip: the squiggly-thingy (&quot tilde &quot) just
indicates your home directory. It should point to the same directory that
the environment variable $HOME points to.

If you browse the manpage for bash you'll discover that there are several
configuration files that can be read at the time of initialization

You'll notice that this speed things up a lot. Instead of constantly typing out
ls -lF for a directory listing you simply enter &quot d &quot . Also, if you're
running X Window and you're tired of looking at all the startup information
cluttering your screen when you shut it down then adding an alias to send
the usual stdout into the /dev/null bitbucket clears up your screen. Nice and
tidy.

Notice one other thing -- a safety point. As long as you're not running as
root all the time you're probably safe from the standpoint of not fatally and
irretrievably zapping some critical system file. But you can still effortlessly
do away with hours/days/weeks of work on a file if you inadvertently &quot rm &quot
something you hadn't intended. UN*X can be kinda harsh, and Linux is no different.
Once somethings gone... it's gone. Now there are programs that handle safe deletes,
but the plain vanilla Linux will still uncaringly discard anything you tell it to.

By adding an alias for &quot rm &quot -- so that it is always invoked with the
-i option, it will always ask you for permission to delete something. Yup, it's can
be a bit of an annoyance, but if it saves your butt once, you'll be happy that you
did. Also, you can override this by issuing &quot rm -f delete_me.text &quot
and Linux will happily delete it without another thought.

Well, now that we've added some helpful aliases, let's make life even more fun
and efficient...

Adding functions to the ~/.bash_profile.

Yup, you remember the idea of functions -- the short bits of little-black-box
code that takes in input and spits back some kind of output. Well, you can set the
same basic thing up, only in a more modest fashion.

Under bash you can define functions that work in your shell script programs
by defining them like:

Say_hello()
{
echo "Hello world"
}

Now, if you invoke the function Say_hello, you'll get a profound sense of accomplishment
as it issues a &quot Hello world &quot back. Pretty lame, eh? Well, not so fast.
You can use this bit of wizardry in your ~/.bash_profile to set up commonly used
functions. Like what? Well, if you use tar frequently, then it's helpful
to add something like:

to your ~/.bash_profile initialization file. Now, instead of having to type out
tar -xvzf some_very_long_filename-3.1415926535-bin-Motif-static.tar.gz
you can just type in tarx some_ver (and then hit TAB to do a filename
completion... just because UN*X allows 256-character file names doesn't
mean that you actually have to USE all 256 characters). The function call
will do the rest. An even handier situation is if you've got an excruciatingly long
command line to enter, such as for the program popclient.

For short functions you can just as easily set up an alias. Someone with more
UN*X wizardry than me might be able to say whether one is more efficient/desirable
than the other. Fact is, they both work, and they'll both let you save a LOT of
time if your spending much time at the keyboard.

One final point... you can use this basic idea to save yourself some harddrive
space. How?

If you gzip -9 your documentation files (you probably don't want to do
this with your /etc/inittab file) then it's easy to view them by setting up a
function or alias such as &quot z &quot , which is listed above. This will zcat
the compressed file and pipe it to less (or more if you like that)
for viewing. On my machine this action is nearly instantaneous for all but the most
gigantic files.

For any of you that have a sound card and have had the unfortunate pleasure of
firing up Windoze you'll recall the scratchy, irritating .wav noise
that eminates from your speakers. This fingernails-on-the-chalkboard greeting reminds
you of what you have in store...

Fortunately, you can do a lot better than the cheesy ding.wav
thing. Linux is here to rescue you. First, you'll need to get your hands on some
half-way decent .au files -- try the multimedia subdirectory at
sunsite.unc.edu
for a veritable smorgasbord of great .au sound files.

(In case you need some hints, there are great trekky clips, some wonderful stuff
by Monty Python -- try out spam.au and the lumberjack.au files -- as well as the
classics from the Three Stooges in the
/series/three_stooges subdirectory)

Once you've gotten a few good .au files, you can make logging in a much more
rewarding and eventful experience by adding something like this to your /etc/rc.d/rc.local
file:

cat /usr/local/sound/spam.au > /dev/audio &

If you put this at the end of the file, after all the other housekeeping chores are
done, then you'll be greeted with a rousing rendition of "Spam, Spam, Wonderful Spam"
in four part harmony (...honest!) as the login prompt is displayed. One minor point --
don't forget to add the &quot &amp &quot at the end of the command line or else
you'll find yourself having to sit throught the ENTIRE rendition before it gives up
control to the login prompt.

Ok, we're on a roll here... While we're messing around with all the initialization
stuff it's time to hack away on something else.

The /etc/fstab file.

Here are just a couple suggestions to make life easier.

First, for all of you who've upgraded to kernel 1.2.x and have suddenly found
yourself getting the same annoying error message at bootup... you know, something
about your /etc/fstab lacking a passno field entry... well, here's how to make
things right.

The problem is that mount is now looking for two additional field in the
/etc/fstab file -- the fifth (fs freq) and the sixth (fs passno) fields -- which
are not, at least as yet, included by default in the stock Slackware distribution
of Linux. So, after you've installed everything correctly, you still
end up getting an error message. Time to fix it.

The manpage for fstab is actually quite intelligible when it comes to
the entries. What's important, at least to rid yourself of the annoying error
message, is to know that two additional fields have been set up for each file
system entry. The fifth field (fs freq)has to do with information regarding the
dump (?) program -- it specifies which filesystems need to be dumped.
(?) ... I'm not sure either, but I've read that it's safe to simply put in a
&quot 0 &quot and let it go at that.

The sixth field (fs passno) is the one of interest. It contains a numerical value
used by the fsck program at boot time to determine the order in which filesystems
are checked. The rules are

The root filesystem is given a value of 1Other filesystems are given a value of 2File systems that do not need checking -- such as the /proc or /cdrom -- are
given a value of 0

When you boot your system, there's a line in your /etc/rc.d/rc.S file that
looks like:

/sbin/mount -avt nonfs

at least this is what's in the plain vanilla Slackware distribution, your's may
vary. The mount command with the -a option results in the automatic
mounting of all the filesystems in your /etc/fstab file execept those that
have the noauto option .

So, if you look at what's going on, you'll see that in the above example, there
are several filesystems automatically mounted at boot time and include a Linux
native (/dev/hda6), a Linux swap (/dev/hdb7), a couple DOS partitions (/dev/hda2 and
/dev/hdb6), an OS/2 (FAT partition, hence the &quot msdos &quot fs-type) (/dev/hdb5)
and the /proc filesystem.

What you'll also notice is that, in the lower section of the fstab file, there
are several stanza's with the &quot noauto &quot option indicated.

Here's where life get's easier

Adding the &quot noauto &quot option keeps mount from trying to mount
my cdrom or floppies at boot time -- since it's likely that there's nothing there.
However, when I'm ready to mount one of these, instead of having to type the usual

mount -r -t iso9660 /dev/sbpcd /cdrom

I can simply type in:

mount /cdrom

Mount will look in the fstab file and if it finds an entry for /cdrom it'll go
ahead and mount it with the options specified. Two other quick points:
By setting up /a and /fd0 entries for /dev/fd0, and /b and /fd1 entries for /dev/fd1
I can easily mount floppies that are either in DOS or ext2 format by entering:

mount /a for DOS floppies ormount /fd0 for ext2 floppies

And adding the &quot user &quot option allows me to mount the filesystem as a
non-root user.

I suspect that most people who are running Linux have found themselves,
for better or for worse, the de facto sysadmin of their workstation. Yeah,
it's cool to be root but it can also be a major league pain-in-the-butt .

Here's another two cent tip to make life easier.

If you've run Linux for any length of time you've probably ended up making a
boatload of changes to the system. If you haven't done so already, you
should probably made a subdirectory off your /root directory and put copies of
ALL the system configuration files that were installed by your distribution.

So, you create a /config_dist subdirectory and start to collect some files:

/etc/inittab

/etc/profile

/etc/rc.d/rc.*

/etc/passwd

/usr/X11R6/lib/X11/XF86Config

then if the system crashes because you screwed something up, you've
got a backup copy to restore it to its original state.

The prepared mind.

One more suggestion...

After you've created a subdirectory to save all the original config files, create
another subdirectory called /links. Now, for all of your widely scattered
configuration files, create symlinks for them in your /links directory.

So, if you're messing around with trying to get your PPP setup going, make a link
to /etc/ppp/options or /usr/lib/ppp/pppon:

Now, when you cd to your /links directory, you'll find symlinks to your various
config files. Then, if you need to make any further changes in them, you can easily
do so from anywhere in your system by entering vi ~/links/ppp_options. Having
all the system configuration files symlinked to one directory makes housekeeping a bit
easier. Some further ideas about what to include:

/etc/printcap -- if you've had to set up your printcap file

/var/spool/lpd/filter_myprinter -- if you've had to create an input filter

/etc/rc.d/rc.* -- pretty much all the stuff here

/usr/lib/ppp/ppp* -- ibid.

/usr/X11R6/lib/X11/fvwm/system.fvwmrc -- for all the groovy stuff you've done to FVWM

and so forth. You get the idea. Every time you have to make an adjustment you go
throught this simple process:

make a copy of the original file and call it original_filename.dist

copy that original_filename.dist to your /config_dist directory

make whatever alterations and customizations you want

make a symlink to your new-and-improved config file in your ~/links directory

now enjoy the fruits of your labors, or fix what you've just broken

Thing is... why go through all the bother of doing this by hand when
you can create a simple shell script that makes life MUCH easier.

Two cent tip: if you have a long, repetitive task then think seriously
about writing a shell script to automate the process. Remember: you're not running
MSDOG, this is Linux. Try something like:

Don't forget to &quot chmod 700 hack &quot when you're done. Then, every time
you need to alter a system configuration file, you simply enter in:

hack important_sys_file.cfg

Hack creates a backup copy in your /config_dist directory with the
&quot .dist &quot suffix; then it creates a symlink to the file in your /links
directory; and finally, it fires up vi (or whatever other editor you like)
and let's you make your changes. This is a pretty barebones example, and you could
easily spiff it up by, for instance, testing for the existance of the file in your
/config_dist directory and not copying over it if it already exists, or asking for
permission to copy over it.

Face it, a lot of folks who use Linux are actually converts from other OS's such
as DOS or Windoze. And in reality, a lot of folks are actually in the multiple-OS
catagory. There's a lot of software that we've spent good money on or just simply
like that either can't be run, or doesn't run well, under a non-native OS. The
simple fact is, no one OS is perfect enough to run everything you'd like to run
(and that goes double for Bill Gate$ and Co.)

Fortunately, Linux comes with filesystem support for accessing your DOS FAT
partitions. It'll read from and write to your DOS filesystem. There's also work
that's ongoing to provide both DOS emulation (DOSEMU) and Windows 3.1 emulation
(WINE) that would allow you to run your DOS and Win 3.1 programs directly from
Linux. If you're interested in this kind of thing check out the
Linux Documentation Project
web page for HOWTO's and other information.

At present, there's a handy little program called
ext2tool.zip written by Claus Tondering
that'll allow you to access your Linux files from DOS. It's a
bit shy in the looks department, but it seems reasonably sturdy and functional.
It supports the ls, cd, cp, and cat operations and includes a small
utility that helps identify your Linux partition number -- you'll need it to
set up the E2CWD variable.

To set it up simply unzip it into a directory, I put it in its own \ext2tool directory for
the sake of tidiness, and then follow the guidelines in the README file. About the
only thing you'll need to do is set up the E2CWD variable:

[from the README]
Before you use the ext2 tools, you must set the environment variable
E2CWD using a statement similar to the following:
SET E2CWD=129:5
or
SET E2CWD=129:5:234
The three numbers after the equals sign are interpreted thus:
The first number (129 in the above example) identifies the physical
disk on which the ext2 file system is located. The number is used as
the second parameter to the DOS biosdisk() routine. Typical values
are:
0 for A: disk
1 for B: disk
128 for first hard disk
129 for second hard disk
(Your BIOS may use different values, especially if you have an SCSI
drive.)
The second number (5 in the above example) is the number of the disk
partition on which the ext2 file system is located. This number is
typically part of the Linux file name for the disk device. If, for
example, you are used to referring to the disk as /dev/hdb5 under
Linux, the partition number is 5. The E2PART program can help you
identify the partitions.
The third number is the inode number of the directory that is to be
your current working directory. If this number is omitted, 2 (the root
inode number) is used. If you don't know what an inode is, don't worry.
Just omit the final number from E2CWD.

Since my Linux partition is on the first harddrive and on the /dev/hda6
partition I just entered:

SET E2CWD=128:6

in my c:\autoexec.bat file and everything worked fine.

It's actually easier than it looks and, once you've set things up, it works
pretty well. As mentioned before, to get things back into Linux you'll
need to reboot and then copy it from from DOS since ext2tool
doesn't support writes. But then again, who'd want to spend much time in DOS
anyway... ;-)

For some people, the idea of compiling their own kernel gives them the willies and
wads their shorts in a knot.

The good news is... it really ain't that tough.

The reason is simple: the guys who spend their time hacking away on the kernel
have done a pretty good job of making everything work right. The actual task of
rolling your own kernel is technically quite simple. There is, however, one
small

Caveat: you have to know what you're doing.

That said, let's see what you'll need to do in order to know what you're doing.
The heart of the matter is the step involving the &quot make config &quot procedure.
It's during this step that a script is run that asks you a series of questions about
what you want compiled into your kernel. Options include

math coprocessor emulation

various harddrive drivers

filesystem support

networking support

support for cdroms, bus mice, sound cards

and so forth. The script is intelligent enough to give you fairly reasonable
generic defaults. The thing is, the reason to roll your own kernel is to
provide it with only what YOU need for YOUR system.

If you have a Logitech bus mouse, a GUS sound card, and run a PPP dial-up
connection, then you really don't need support for NFS, Ethernet cards, or
cdrom drives. If you answer one of the configuration questions incorrectly, it's
not that the kernel won't work... it will either have drivers included that you
can't use (kernel too large and takes up more memory), or it will lack some
option that you really need -- such as support for your bus mouse.

So where do you go to learn?

An excellent place to start is by reading Brian Ward's very helpful
Kernel-HOWTO which can be found, with an entire reference shelf of other
HOWTO's, on the
Linux Documentation Project's HOWTO section. Brian takes you through the
process step by step and explains what each of the options entails. Another helpful
place to find information and advice is in the
Linux sunsite kernel
directory. Several authors have written programs specifically to assist with
compiling your own kernel.

And don't forget printed material. Matt Welsh and Lar Kaufman
have written an excellent book that needs to be on everyone's bookshelf
called Running Linux (Published by the folks at O'Reilly). At
$24.95 this is an absolute steal for over 500 pages of instruction, tips, tricks,
and step-by-step howto's. If you don't have it, get it.

Once you've done your homework, the technical part is quite straight forward:

That's it. You'll see miles of script go whizzing by your screen and then a
series of questions will begin, asking you how you want your kernel configured --
you're in make config. Answer the questions and when it's done it will
set about compiling your new kernel.

How long will it take?

pentium/133 -- go to the bathroom but don't take too long.

pentium/66 -- run down and get a coke.

486DX2/66 -- run down and get a coke and flip through a magazine.

486SX/25 -- run down and get a coke, flip through a magazine, watch Cheers
reruns on the tube.

386DX40 -- run down and get a coke, flip through a magazine, watch Cheers
reruns on the tube, do a couple loads of wash.

386SX-16 -- run down and get a coke, flip through a magazine, watch Cheers
reruns on the tube, do a couple loads of wash, fly home to see your mom.

286 -- Uugh uugh, this dog don't hunt...

Once the compile is done and you're through doing what you need to do, you can go
and pick up your shiny new kernel in:

/usr/src/linux/arch/i386/boot

It'll be called zImage and is usually at the bottom of your directory
listing. There you go! you've done it!

Now I'll bet you want to try it out, eh? First, a couple caveats!

Caveat #1: make absolutely sure you have a working boot disk before
you do anything else.

Caveat #2: make sure the boot disk actually works!

Caveat #3: make a backup copy of your current working kernel image (usually,
/vmlinuz) and put it in a safe place.

You may need to chmod 400 vmlinuz to set the proper permissions and
then don't forget to rerun LILO! -- e.g., /sbin/lilo. Once you've done all
this, you're ready to reboot.

Ok, go ahead... you can do the old shutdown -r now and keep your
fingers crossed!

It didn't work??!!! Arrgghhh...!! But don't fret, it's fixable. If your
system yurks up on your new kernel for some reason simply reboot using your boot
floppy and then copy your old kernel image, which you put in a safe place, back
into the root directory and rerun LILO -- e.g., /sbin/lilo.

You should now have your old kernel image safely in place and can reboot your
system off the harddrive once again. But keep reading... we'll look at some ideas
for safely and easily test driving a new kernel in the next section.

Now that you've had a run at compiling your own kernel, it's time to try it out
and see whether it actually works. Simply copying over your trusty old kernel is...
well, maybe just a bit brash, unless you really know what you're doing, or
you really are a thrill-seeker. If you're either of the above you can probably
stop reading here.

For the rest of you, keep reading.

There are two rather easy ways to try out your new kernel:

making a boot disk from it

setting it up as a LILO boot option

There are, to be sure, more sophisticated ways of testing out your new kernel...
but this ain't gurudom, it's simply what works. And either of these two methods
should give you the chance to try booting a new kernel without incurring too much
trouble in the process.

To create a useable boot disk simply copy the zImage file that's in
your /usr/src/linux/arch/i386/boot/ directory to a floppy:

cp zImage /dev/fd0

to install it onto a disk in your first floppy drive. Keep in mind that this is
a bit of a kludge as it will wipe out any filesystem that exists on the
disk. It also goes without saying that you'll want to do this on a floppy that
doesn't have any important stuff on it. Copying this to the floppy that had your
327 page doctoral dissertation in LaTeX2e format on it is probably not a good
idea.

Then, to try it out just reboot with the usual shutdown -r now and sit
back and enjoy. Keep an eye out for any error messages that may crop up during
the boot process. There is a utility you should be aware of if you're messing
around with kernels -- rdev, which allows you to set certain boot time
options for the kernel. These include such things as which partition to set up
as the root partition and as the swap partition, the root flags (read/write or
read only), the bootup videomode, the ramdisk size, and the byte offset to use.
You'll probably not need to adjust your kernel as it will likely point to
the correct root partition. If it doesn't, then you can enter:

rdev /dev/fd0 /dev/hda6

for example, if your root partition is, in fact, the /dev/hda6 partition.
You might, however, want to issue the command:

rdev -R /dev/fd0 1

This sets the root partition as read-only at boot time so that the
filesystem can be checked prior to being mounted. If you forget the exact
syntax of the command entering rdev -h will pop up a short
help screen to jog your memory.

Now, once you know for sure that your new kernel works -- it actually let's you
mount your new CDROM, or dial up your PPP link -- you can go ahead and make a
back up copy of your trusty old kernel, put it in a safe place, and copy your
zImage file into your root directory. And don't forget to run LILO -- i.e.,
enter /sbin/lilo at the command prompt. If you don't, and you're
using LILO as your boot manager, you probably will not be able to boot your new
kernel, even if it works correctly.

The other method is to simply add a stanza to your lilo.conf file that will
let you choose to boot either your usual kernel (often, /vmlinuz in your root
directory) or a new kernel you've just compiled.

Suffice it to say that configuring LILO, and actually getting it to work, can be
a bit hairy at times. This is one file you definitely want to have a boot
disk and a backup copy of before you blithely wander in where angels fear to tread.
Having done that, however, you should only have to make minor additions to your
/etc/lilo.conf file to get things working.

What you'll need to add are primarily in the last 5 lines of the example above.
You'll need to add a stanza for the new test kernel. The image entry
indicates where the kernel image is located. In this case, it points to the
directory where the new kernel is found after you've compiled a kernel with the make zImage command.
Kinda tidy, eh?

The only other required entry is the label, which is what LILO will
use when it asks you what you want to boot. The remainder of the entries, such
as root or vga can be left out and the options included at
compile time or set using rdev will be used. If you're a bit on the timid
side and don't want to hack away too much, you can safely enter just the
image and the label entries and things should work all right.
Last, but not least, don't forget to rerun LILO -- i.e., simply enter
/sbin/lilo at the command prompt and you should see something like:

Adding Linux *
Adding zImage

Now, after you reboot, simply hold down the Shift key as LILO starts up
and it'll prompt you for which kernel you'd like to boot. Hitting the Tab
key will present you with a list of options. So... go ahead and enter zImage
and, if everything went as planned, voila! a new kernel. Using either of
these methods allows you to try booting a new kernel without disturbing your present
setup. If things don't work you can either remove your test boot floppy or tell
LILO to boot from your previous kernel.

Hope you enjoyed this premier issue of the Linux Gazette. I've tried to
make every effort to ensure that the information presented here is up to date and
correct. Please let me know if there are any glaring oversights or errors in this.
Also, if you have suggestions, comments, or critisms let me know.

If there's any interest in this, I'd be happy to keep writing new editions.